AWS Continuum GA: Validated Code Fixes, With a Human in the Loop

On October 22, AWS made AWS Continuum for code vulnerabilities generally available. AWS describes it as "a security service that finds and validates code vulnerabilities," and the design choice that matters most is in the word validates. Instead of handing your developers another list of scanner findings, Continuum tries to prove which ones are exploitable in your environment, ranks them by business impact, and opens a pull request with a proposed fix.

The timing is not accidental. In its user guide, AWS says frontier AI models let attackers generate complex exploits from vulnerability disclosures "in minutes rather than hours," while security teams "already cannot keep up with the volume of findings." Whether or not you use AWS's tool, that framing is worth taking seriously: the gap between disclosure and exploit is shrinking, and backlogs sorted by generic severity scores do not shrink with it. Here is what launched, how it works, what it costs, and how to evaluate it without handing your release process to a new system on day one.

What AWS actually shipped

AWS Continuum is a family of security capabilities. The GA announcement covers the code vulnerabilities piece, which the user guide says "focuses on finding, validating, and remediating first-party code vulnerabilities" and "integrates with GitHub and Amazon S3 for code and context." The Continuum product page also lists Continuum for penetration testing, which it notes was formerly AWS Security Agent, and the user guide lists threat modeling as a third feature.

Key facts from the launch post:

• Availability: US East (N. Virginia) and US West (Oregon) at launch.
• Code sources: a GitHub integration or an Amazon S3 bucket. An S3 bucket must be in the same account and Region where Continuum is enabled, and Continuum reads it through an IAM role it assumes.
• Environment context: an optional collector you deploy in the account and Region where your code runs. It gathers resource details such as AWS Config resources and network configuration.
• Scanning: environments scan on a schedule you choose, and you can queue a scan on demand.

The product page says the code vulnerabilities service is model agnostic and uses multiple frontier models, picking the one suited to each task.

How validation changes triage

Most AppSec programs have the same bottleneck: a scanner flags something, and an engineer spends hours working out whether it can actually be reached before anyone decides who should fix it. Continuum aims at that step in three ways.

A context graph instead of a severity score

Continuum builds a context graph from your repositories and, if you deploy the collector, your AWS environment. From that graph it infers which systems are business-critical, who owns them, how services depend on each other, and what data they touch. Issues are ranked by how close their attack path gets to those critical systems. The launch post argues that generic severity scores don't show which resources an attacker can actually reach, and this graph is AWS's answer.

Evidence attached to each finding

Each finding gets an evidence level, such as a verdict proven by static analysis. For findings it can reproduce, Continuum runs the exploit in an isolated sandbox and attaches proof-of-concept code and reproduction steps. It also assesses whether your existing defenses would detect and stop the validated path. In the console, raw scanner output sits on a Findings tab, while validated, prioritized results appear separately under Issues.

Fixes delivered as pull requests

For confirmed issues, Continuum generates a code patch, dependency upgrade or configuration change and opens a pull request. The example in AWS's post is a High-severity, network-reachable issue that needs no authentication, fixed by a pull request touching four files in a cart service.

Human approval first, autonomy later

Automatic remediation is not available at GA. AWS says it plans to let customers automate specific classes of fixes once confidence gates pass, citing test coverage, scope bounds and historical success rate as examples. The product page describes trust as "graduated" and set by the customer: Continuum starts by proposing actions, people approve them, and customers choose which actions it may later take on its own.

That sequence is the right one, and it is worth adopting as your own policy regardless of the tool. Before you let any system merge security fixes unattended, you need your own answers to the questions AWS's gates imply. Is test coverage on the affected service good enough to catch a regression? Is the change confined to one service, or does it touch shared libraries? How often have this tool's past fixes of this type been merged unchanged? If you can't measure those today, the human-approval mode is where you should stay.

What it costs

According to the Continuum pricing page, the code vulnerabilities service has two charges and no upfront costs or minimum fees:

Charge	Rate
Monthly context fee, first 10 million protected lines of code	$200 per 1 million lines
Next 90 million lines	$180 per 1 million lines
Above 100 million through 1 billion lines	$160 per 1 million lines
Above 1 billion through 10 billion lines	$130 per 1 million lines
Above 10 billion lines	$100 per 1 million lines
Inference fee	$10 per Continuum inference unit (CIU)

At those rates, the context fee for 5 million protected lines works out to $1,000 a month before any inference charges. The inference side is harder to forecast because the pricing page doesn't tell you how many CIUs a typical scan or fix consumes, so plan a time-boxed pilot on a representative repository and measure it. The pricing page lists a free trial for the penetration testing service, but not for code vulnerabilities.

Where it fits in your SDLC

Continuum does not replace a secure development program; it plugs into one. NIST's Secure Software Development Framework, which NIST describes as "a core set of high-level secure software development practices" that can be added to any development life cycle, is final at version 1.1 (SP 800-218), and NIST released a draft version 1.2 (SP 800-218 Rev. 1) on December 17, 2025. A tool that finds, validates and proposes fixes can generate useful evidence for that kind of program, but the practices, ownership and review still have to be yours.

A few practical considerations before connecting repositories:

• Data and access. You are granting a service read access to source code and, through the collector, details of your environment. Review the IAM role and GitHub integration scopes with the same care as any third-party code access.
• Region constraints. At launch the service runs in two US commercial Regions. If your code or data has residency or authorization requirements, including federal workloads, confirm the service fits them before connecting anything.
• Pull request hygiene. Generated pull requests should go through the same branch protections, required reviews and CI checks as human ones. Don't create bypass rules for a bot.
• Overlap with existing scanners. Decide whether Continuum's issue list becomes the source of truth for prioritization or a second opinion, so engineers aren't triaging the same flaw in two places.

A 30-day evaluation checklist

1. Pick one service with decent test coverage, a clear owner and a known backlog of findings. Avoid shared libraries for the first round.
2. Connect the code source with least privilege (a scoped GitHub integration or a dedicated S3 bucket) and document exactly what access was granted.
3. Deploy the collector in a non-production or well-understood account first, so the context graph reflects a real environment without broad exposure.
4. Compare against your current triage. For the top issues Continuum validates, check whether your existing tools ranked them the same way and how long your team would have taken to confirm them manually.
5. Review every generated pull request through normal code review. Track how many merge unchanged, need edits or are rejected, and why.
6. Measure cost: the context fee for the lines you connected plus actual CIU consumption over the period.
7. Write down your autonomy criteria before you need them: which fix classes, what test coverage, what merge history would justify less human review.

Validated, prioritized findings with a proposed fix attached are a real improvement over raw scanner output, and AWS's insistence on human approval at GA is a sensible default. The work that decides whether it pays off is the surrounding plumbing: repository access, CI gates, ownership, and the policies for when a machine may act on its own. Baygramm's DevOps team helps organizations build that pipeline and evaluate tools like Continuum against their existing stack, and our cybersecurity practice can help set the governance around automated remediation. If you're weighing a pilot, talk to us.