AWS Continuum Validates and Ranks Code Vulnerabilities

TL;DR

• AWS Continuum is a security service from Amazon Web Services that validates code vulnerabilities, ranks them by business impact and proposes a fix for each one.
• General availability was announced on October 22, 2026 in US East (N. Virginia) and US West (Oregon), with every remediation starting in a mode where Continuum proposes the fix and a person approves it.
• The service builds a context graph from your repositories and your AWS environment, then ranks each validated issue by how close its attack path runs to a customer data store, a payment pipeline or an authentication service.
• The evidence package for one issue includes an evidence level, an exploit reproduced in an isolated sandbox with proof-of-concept code, the attack path, a blast radius and a check of whether existing defences would stop it.
• The fix arrives as a pull request in the connected repository — a code patch, a dependency upgrade or a configuration change — and a reviewer merges it, so the decision stays with the team.
• The two pricing dimensions are a monthly context fee per million lines of code, tiered from $200 down to $100, and $10 per Continuum inference unit, which AWS illustrates with a $1,200 month at one million lines and 100 findings and $218,200 at a hundred million lines and 10,000 findings.
• What the console walkthrough leaves open is everything outside the demonstrated tenant: no independent benchmark, no remediation accuracy figure, and no statement about how it treats findings in code it cannot build.

AWS Continuum's launch turns vulnerability triage into a metered service with a monthly context charge and a variable inference charge. A scanner on a large estate emits thousands of findings a day, and the ones that matter hide among the ones that describe code nobody can reach. AWS's framing of the service it made generally available on October 22, 2026 names the cost directly: "Previously, confirming whether a finding was exploitable took hours of manual investigation, and shipping a fix with confidence took days of coordination across security, infrastructure, and application teams."

Continuum validates a finding before it ranks it

For a buyer, the service packages discovery, validation, prioritisation and remediation into one AWS-managed workflow. It finds and validates code vulnerabilities, it ranks the validated set by business impact, and it proposes a fix for each confirmed issue. This scope matters to the bill because AWS meters the security work through Continuum inference units while charging separately for the context graph.

AWS puts the failure of severity scores plainly in the post: "Generic severity scores don't tell you which resources a threat actor can actually reach," and the consequence it draws is the one every reviewer of a noisy dashboard has felt — a critical score on a dev-only utility looks the same as a medium score on a service one step away from a payments database.

A context graph built from repositories and one AWS account

Two sources feed the graph: your code repositories and your AWS environment. In an AWS account and Region where the code runs, you set up a collector that gathers resource details such as AWS Config resources and network configuration. The collector is what lets the service answer a reachability question, since a network path to a database is the difference between a theoretical flaw and an exploitable one.

The graph is also how the service learns which systems carry business weight: who owns a service, how services depend on one another, and which data each one touches. The ranking then follows the context graph. The context fee pays for building and maintaining this graph, so a buyer is funding an ongoing model of the codebase, cloud configuration and business context alongside the inference work.

The evidence package: a proof, an attack path, a blast radius

For a finding it can reproduce, the service runs the exploit in an isolated sandbox and attaches proof-of-concept code with reproduction steps. It also reports the attack path, the source analysis behind the verdict, a blast radius assessment and an evaluation of whether the existing defences would detect and stop that path.

This is the part of the product a security team can audit, and the part a finance-adjacent reader should read closely. The evidence package combines a reproduced exploit with a model assessment of existing controls based on the configuration inventory. A team that reads the proof and skips the second paragraph gets the vulnerability and misses the assumption.

In the worked example in the post, one issue is rated High severity, exploitability Exploitable with an evidence level of Static proven, likelihood High because the service is reachable with no authentication and no user interaction, impact Moderate, and a blast radius reaching other users in the same tenant. Those labels are a compact language for a security conversation, and they will only be as good as the inventory behind them.

The fix arrives as a pull request that a person merges

Each confirmed issue gets a fix: a code patch, a dependency upgrade or a configuration change, opened as a pull request in the connected repository. In the demonstration the pull request changes four files in the cart service, with 50 lines added and 24 removed, and its description carries the same risk assessment, remediation summary and proof that the console shows.

Every remediation starts in a mode where a person approves it before it ships. AWS states the future direction in the same paragraph: teams will eventually decide which remediation classes Continuum may apply on its own, once confidence gates such as test coverage, scope bounds and historical success rate pass. For an adoption decision, that roadmap makes approval policy, test coverage and historical success rate part of the operating model a buyer must evaluate.

The console states that every generated patch still requires review and a merge before the issue is fixed. A patch that compiles and passes tests can still change behaviour, and the review of a machine-authored change deserves the attention of any other change to production code.

What the two pricing dimensions charge for

The pricing page describes two dimensions and no upfront cost. A monthly context fee tracks the lines of code the service protects, starting at $200 per million lines and declining through $180, $160 and $130 to $100 per million in the largest tier. The variable charge is $10 per Continuum inference unit, and AWS says the units required for each vulnerability vary with the work involved.

The page's own worked examples make the shape clear. One million lines with 100 vulnerabilities at one unit each comes to $1,200 a month. Ten million lines with 1,000 vulnerabilities comes to $12,000. A hundred million lines with 10,000 vulnerabilities at two units each reaches $218,200, of which $18,200 is context and $200,000 is inference.

The enterprise example makes the purchasing issue visible: $200,000 of its $218,200 monthly estimate comes from inference work, while $18,200 comes from context. At scale the findings drive the bill, and the findings are what the validation is meant to reduce. AWS does not publish a fixed number of units per vulnerability, so a budget needs an observed workload mix and cannot be derived from repository size alone.

What the console walkthrough leaves open

The post demonstrates one tenant, one cart service and one High-severity issue. It reports no measured reduction in mean time to remediate, no false-positive rate on validation, and no accuracy figure for the generated patches. Those numbers would be the ones a buyer would want, and their absence is normal for a launch post.

Two operational questions stay open as well. The service needs a buildable view of your code and a collector in the account where it runs, which makes the first day of adoption an inventory project. The business case also depends on reviewer capacity because every generated pull request initially requires human approval, leaving buyer-side review time outside the AWS fee examples.

A backlog that shrinks with the decision still inside the team

The decision for a buyer is whether the combined context fee, variable inference usage and internal review time produce a defensible cost per resolved vulnerability. A team that adopts validation without the last step automates deployment of machine-authored code, and a team that adopts the proposal without validation automates noise.

None of this removes the need to know your own estate. Validated findings sharpen a security audit and hardening programme, and they sharpen it most where the inventory is current, the owners are named and the critical services are written down before the first scan runs.

For a small company, a limited pilot can establish protected lines of code, inference units per vulnerability and reviewer time before a wider commitment. Record those three inputs during the pilot and compare the resulting monthly cost with AWS's $1,200 and $12,000 worked examples. The rest of the estate can wait for the second month.

Sources

Source: "AWS Continuum for code vulnerabilities is now generally available" — AWS News Blog, 2026-10-22. https://aws.amazon.com/blogs/aws/aws-continuum-for-code-vulnerabilities-is-now-generally-available/

Source: "AWS Continuum for code vulnerabilities pricing" — aws.amazon.com, retrieved 2026-11-08. https://aws.amazon.com/continuum/pricing/

Screenshots: four console images published in the AWS News Blog post above, retrieved 2026-11-08, plus one capture of the official pricing page taken the same day.

Source: AWS News Blog and the official AWS Continuum pricing page, retrieved 2026-11-08; individual URLs are listed in the Sources section above.