AWS Continuum exits closed preview and starts validating vulnerabilities with real exploits

- Reading
- 6 min
AWS made Continuum generally available, a service that runs exploits in a sandbox to confirm which code vulnerabilities are exploitable and opens pull requests with the fix. The announcement has already drawn criticism over what's left out and over the price per validated finding.
What changed: Continuum exits restricted preview
AWS made Continuum for Code Vulnerabilities generally available (GA) in the US East (N. Virginia) and US West (Oregon) regions, according to an InfoQ report published on November 6, 2026. The service had been announced four months earlier, in closed preview, that is, around July 2026. The pricing page, which the official announcement does not directly mention, reveals a model billed both by protected line of code and by processed finding.
The service was described by AWS principal solutions architect Esra Kayabali as a tool that finds and validates code vulnerabilities, delivering fixes as automatable patches or as pull requests in connected repositories. To do this, it builds a context graph from those repositories and the surrounding AWS environment, with an optional collector bringing network and resource context from where the code runs in production.
How exploit-based validation works in practice
Instead of just ranking findings by severity, something traditional SAST/DAST scanners have done for years, Continuum tries to confirm which vulnerabilities are actually reachable. It runs the exploit inside an isolated sandbox and attaches proof-of-concept code with reproduction steps, so the team doesn't need to manually reconstruct the attack.
Each finding receives an "evidence level," ranging from a verdict proven by actual execution to a verdict based on static analysis of the vulnerable path. The final output isn't just a risk score: it's an attack path and a blast radius assessment, according to AWS's description.
Swami Sivasubramanian, AWS VP of Agentic AI, and Christopher Rae, who leads AI security go-to-market at the company, framed the problem as one of volume, not detection. Sivasubramanian wrote that most organizations with large application estates see thousands of findings per day; Rae was more direct:
Most becomes noise that doesn't matter in your environment.
Christopher Rae, AI security go-to-market lead at AWS
How much it costs: two billing components
For whoever decides the AppSec budget here, the pricing model matters as much as the feature. Continuum's billing has two dimensions:
- Context fee: charges per protected lines of code per month, starting at US$ 200 per million lines and dropping to US$ 100 per million above 10 billion lines.
- Inference fee: US$ 10 per "Continuum inference unit," consumed as findings are processed.
The calculation examples AWS published show how this plays out in practice. A base of 1 million lines with 100 vulnerabilities, at one unit each, comes to US$ 1,200. A base of 100 million lines with 10,000 vulnerabilities, at two units each, reaches US$ 218,200, with US$ 18,200 from context and US$ 200,000 from inference, or roughly US$ 20 per validated finding.
In short: the "thousands of findings per day" that the two AWS executives describe as a volume problem are exactly what the per-finding fee charges for. The marketing pitch and the billing metric measure the same work from opposite ends.
What the sandbox doesn't solve, according to those who tested the announcement
Responding to the announcement on LinkedIn, Bernardo Meireles Correa, an engineer working with agent identity and non-human identity at Avatier, praised the exploitability ranking but pointed out two open issues:
A proof in an isolated sandbox says the code is exploitable. It does not say the path to it exists in your environment, and the findings it cannot prove still need somewhere to go, or they quietly become the safe pile.
Bernardo Meireles Correa, agent identity (non-human identity) engineer at Avatier
The product partially addresses the first objection: the optional collector gathers AWS network and resource configuration to judge reachability, but this is an extra configuration step, not the default. The second objection remains unanswered: AWS documents what happens to findings it can prove, but says nothing about the fate of the ones it can't.
This matters for whoever runs a CI/CD pipeline here: without configuring the collector, Continuum loses exactly the part that calculates whether the path to the exploit exists in the real environment, and without that configuration, the value of the validation drops.
Autonomy is the next step, but there's no acceptance criteria yet
Today, every remediation starts in a mode where Continuum proposes the fix and a person approves it before it goes live, and the console warns that a generated patch doesn't mean the problem is solved. AWS plans to let Continuum apply fix classes on its own once confidence criteria, such as test coverage and track record, are met.
Jorg Huser, CTO and former AWS principal, questioned Rae about what should unlock that autonomy:
The move from approving each merge to approving a class of fixes deserves its own acceptance test. An overloaded review queue can otherwise become the reason to grant more autonomy. I'd want evidence that the fix removes the vulnerability and preserves expected application behavior. What would qualify a fix class for autonomous merging, and what would send it back to human review?
Jorg Huser, CTO and former AWS principal
Continuum vs. CodeMender: missing the equivalence proof
Google's CodeMender goes further on the point AWS still leaves open. It also proves exploitability by running the exploit and also refuses to apply patches on its own, but it validates each fix with an LLM-as-judge framework that tests program equivalence, ensuring the fix resolves the root cause.
without altering the application's intended behavior
CodeMender description, Google
It's exactly this step, proving that the fix doesn't change the application's expected behavior, that Continuum's own console disclaimer acknowledges it doesn't do.
The naming confusion within AWS itself
The product overlap that InfoQ had already reported in July 2026 is still visible in the documentation. At the time, AWS Serverless Hero Yan Cui summed up the problem:
we have the same capabilities, two product names, and no clarity on which one you should use
Yan Cui, AWS Serverless Hero
That remains true: the Continuum user guide covers code vulnerabilities, but points whoever is looking for pentest and threat modeling to a separate guide, the "AWS Security Agent User Guide." Only the code vulnerabilities capability reached general availability; pentest is still priced separately at US$ 50 per task hour, and threat modeling, announced in preview in June 2026, still has no published price.
What changes for those building here
For Brazilian squads, Continuum's central pitch is reducing alert fatigue: swapping an endless list of SAST/DAST findings for confirmation via a real exploit plus a PR ready for review. That comes with cost and with configuration: teams without the optional collector lose exactly the part that calculates real reachability in the environment.
The price per finding, around US$ 20 in the published examples, needs to be factored in alongside the exchange rate in reais before any pilot. And the decision to release automatic fixes without human review still has no clear published acceptance criteria, not from AWS, nor, for now, from whoever competes with it.
Translated from the Brazilian Portuguese original · Read the original
DeepSeek plans official plugin marketplace for Harness, which reaches 1.54 million daily users
The Chinese company is preparing an official extensions store and a token incentive program for creators, after Harness surpassed 1.5 million daily users and 35,000 third-party plugins, according to IT Home.







