AWS Continuum for code vulnerabilities is now generally available: what it does and what to know
AWS says Continuum now validates exploitability in a sandbox and opens fix pull requests, with human approval required, in two US regions.
· 7 min read
Written by AI from the sources linked below. How we use AI
On this page
Amazon Web Services made AWS Continuum for code vulnerabilities generally available on 22 October 2026, four months after it was announced in gated preview. The service takes the findings your scanners already produce, checks which ones an attacker could really reach in your AWS environment, tries to reproduce them in a sandbox, and opens a pull request with a fix. AWS says every fix needs a person's approval for now. For teams buried in scanner output, the pitch is fewer, better-evidenced tickets; the open question is how much of that evidence you can trust without redoing it.
Key points
- AWS announced general availability of Continuum for code vulnerabilities on 22 October 2026; it was announced on 17 June 2026 at the AWS Summit in New York and was in gated preview until now.
- It is available in two regions at launch: US East (N. Virginia) and US West (Oregon).
- It ingests existing scanner findings and its own scans, ranks issues by business impact, and, for findings it can reproduce, runs the exploit in an isolated sandbox and attaches proof-of-concept code.
- Fixes (a code patch, dependency upgrade or configuration change) arrive as pull requests in a connected repository; AWS says every fix needs human approval.
- Code can come from GitHub or an Amazon S3 bucket, and an optional collector in your AWS account adds infrastructure context.
What happened
AWS published the general-availability announcement on its News Blog on 22 October (written by Esra Kayabali) and a shorter What's New entry the same day. The company describes Continuum as a security service that "finds and validates code vulnerabilities, then delivers fixes as patches you can automate or as pull requests". In AWS's words it discovers, validates, prioritises and remediates code vulnerabilities "at machine speed".
The mechanics, as AWS describes them:
- Connect code. You link a GitHub integration or an S3 bucket (the bucket must be in the same account and Region where you enable Continuum, and access goes through an IAM role it assumes), then create an environment that scans on a schedule you choose.
- Add context (optional). You can deploy a Continuum collector in the account and Region where the code runs. It gathers resource details such as AWS Config resources and network configuration, so Continuum can judge whether a vulnerability is reachable over the network and what an attacker could reach from it.
- Build the graph. From the code and the AWS data, Continuum builds a context graph: which systems matter to the business, who owns them, how services depend on each other and what data each touches. It uses this to find the highest-value systems, such as customer data stores, payment pipelines and authentication services, and ranks each issue by how close its attack path runs to them.
- Validate. Each finding gets an evidence level, for example 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 with reproduction steps, plus the attack path and a blast-radius assessment. It also checks whether your existing defences would detect and stop the validated path.
- Fix. For each confirmed issue it opens a pull request titled "Continuum fix" containing the patch, the risk assessment and the proof. In the example in AWS's post, the fix changed four files with 50 lines added and 24 removed. The console notes that a generated patch does not mean the issue is fixed until your team reviews and merges it.
AWS states the problem plainly. Threat actors using frontier AI models can turn a vulnerability disclosure into working exploit code in minutes, while scanners produce thousands of findings a day, many of which need no action. Previously, AWS says, confirming whether one finding was exploitable took hours, and shipping a fix took days of coordination across teams.
Background
AWS first unveiled Continuum on 17 June 2026 at the AWS Summit in New York. SiliconANGLE and Help Net Security both reported it as a platform that uses frontier AI models to discover, validate and remediate vulnerabilities, with code vulnerabilities as its first capability, available in gated preview. AWS said the system is model-agnostic and picks a model for each task.
At that launch AWS folded two earlier tools into the brand: the penetration-testing and code-scanning functions of AWS Security Agent, which had been previewed at re:Invent in December 2025, became Continuum pen testing and Continuum code scanning (both in preview), and AWS added Continuum threat modeling in preview, which turns design documents or source code into STRIDE-format threat models. We have not seen a GA announcement for those three in this release, so assume they are unchanged.
At the June launch, AWS's Chet Kapoor said frontier models "like Claude Mythos can now find software vulnerabilities and reason through complex attack paths at machine-speed", and that this was producing an "exponentially increasing backlog". That backlog problem is the one Continuum is aimed at. It is also visible in the news: this week alone the Chrome 156 release fixed 353 security bugs, and we covered Anthropic using Claude to shrink OpenSSH's pre-login attack surface. More bugs found faster means more triage work for the people who own the code.
BankInfoSecurity, covering the June launch, placed Continuum alongside Google's CodeMender and Microsoft's MDASH, noting that CodeMender focuses on discovery and patching and that Microsoft had not made MDASH generally available at the time. That comparison is the publication's, from June, and the competitive picture may have moved since.
How it works: learn mode and enforce mode
The part of Continuum that matters most for risk is the trust model. AWS calls it "graduated". The product starts in Learn mode: it proposes, a person approves, and each recommendation comes with its reasoning. Later, teams can move to Enforce mode, where remediation becomes increasingly automated for categories and risk profiles the customer defines.
The two GA announcements are not perfectly aligned on how far that goes today. The News Blog says that "in the future" you will be able to decide which actions Continuum can take on its own, within guardrails such as test coverage, scope bounds and historical success rate. The shorter What's New entry says that once Continuum has built trust you "switch to the Enforce mode". We take the longer blog post, which is more specific, to mean that autonomous remediation is not yet available, and every fix at launch waits for human approval. If you plan around Enforce mode, ask AWS what is live today.
Matt Wood, AWS's chief AI and technology officer, described the end state in June as a point where the human in the loop becomes "an obstacle rather than a safeguard", according to BankInfoSecurity. BankInfoSecurity's own comment was that the platform "asks enterprises to trust AWS systems implicitly". The sceptic's reading and AWS's reading of the same design differ mainly on how quickly the human can be removed.
What it means
For security and platform teams: the value proposition is prioritisation with evidence. A critical score on a development-only utility and a medium score one hop from a payments database look the same to a generic scanner; Continuum's graph is meant to separate them. If it works, the queue shrinks and each remaining item arrives with a reproduction and a proposed patch.
For developers: the output lands as pull requests in your normal review flow, with the evidence attached. The review burden moves from "is this finding real?" to "is this patch correct and safe to merge?" A patch generated by a model still needs a human who understands the service, and AWS itself says so.
For AWS customers with data-residency or scope concerns: the optional collector reads AWS Config resources and network configuration from your account, and exploits are run in an isolated sandbox. Before enabling it, check what access the IAM role and collector are granted and where processing happens. At launch, only two Regions are supported.
For the market: a hyperscaler productising "find, prove, fix" confirms where the vulnerability-management category is heading, and puts pressure on stand-alone scanner and remediation vendors.
What we don't know yet
- Pricing. The announcements point to a pricing page; we did not find a price in the announcement text, so we cannot say what it costs.
- Accuracy. AWS has not published false-positive or fix-acceptance rates in the pages we read. The claim that Continuum "confirms which findings are exploitable" is AWS's own.
- Independent testing. We have not seen third-party evaluations of the GA product.
- Language and framework coverage. The announcement does not list supported languages in the text we read.
- When Enforce mode is available, and which fix classes it will cover first.
What to watch next
Watch for the pricing details, for third-party measurements of how often the validated issues and patches are right, for the arrival of Enforce mode, and for the GA status of Continuum pen testing, code scanning and threat modeling. AWS's re:Invent 2026 conference, whose session catalog is already live, is a natural venue for updates, though AWS has not said so.
Sources
- AWS News Blog: AWS Continuum for code vulnerabilities is now generally available, 22 October 2026 (primary)
- AWS What's New: AWS Continuum for code vulnerabilities is now generally available
- AWS Security Blog: Introducing AWS Continuum, 17 June 2026
- SiliconANGLE: AWS launches Continuum to find and fix code vulnerabilities at machine speed
- Help Net Security: AWS Continuum brings AI models to code vulnerability management
- BankInfoSecurity: AWS Unveils Continuum to Fight Vulnerability Backlog
Written by
The official account of the people who run audiotale.net: announcements, conversation starters and the newsroom's drafts. Posts written with AI say so. Every other account here is a real person.
Read next
Microsoft blames China-linked Storm-0940 for ConnectWise Cloud Backup breach, says attackers used ARTEX AI framework
Microsoft says Storm-0940 used the open-source ARTEX framework against hundreds of organisations after stealing ConnectWise app credentials; what to check in your Microsoft 365 tenant.
audiotale.net team8 min read
LiteLLM 1.107.0 on PyPI was a credential stealer and backdoor: what to check and rotate
A malicious LiteLLM release and Docker images went out on 21 October 2026; here is what the malware does, what researchers disagree on, and how to clean up.
audiotale.net team9 min read
Anthropic used Claude to cut OpenSSH's pre-login attack surface and report 493 issues in 25 open-source projects
Anthropic says Claude mapped what 25 open-source projects expose by default; in OpenSSH, about a fifth of the code reachable before authentication was removed.
audiotale.net team7 min read