Today, we’re announcing the general availability of AWS Continuum for code vulnerabilities. AWS Continuum is a security service that finds and validates code vulnerabilities, then delivers fixes as patches you can automate or as pull requests in your repositories. AWS Continuum for code vulnerabilities confirms which findings are exploitable in your environment, ranks the resulting issues by business impact, and proposes a fix for each one. Every remediation starts in a mode where Continuum proposes the fix and a person approves it before it ships. In the future, you will be able to decide which actions Continuum can take on its own, within the guardrails you define.

Using frontier artificial intelligence (AI) models, threat actors can turn a vulnerability disclosure into working exploit code in minutes, and the same tools that speed up development also increase the volume of findings your teams must process. If your organization runs a large application estate, your scanners likely produce thousands of findings a day, and many of them need no action. A finding can be unreachable, unexploitable, or already mitigated by a runtime control. Generic severity scores don’t tell you which resources a threat actor can actually reach, so 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. 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, because the blast radius of a change is hard to assess without business context. To close that gap, Continuum proves which findings are exploitable and bounds the risk of each fix it proposes.

Continuum builds a context graph from two primary sources: your code repositories and your AWS environment. For AWS, you set up a collector in the account and Region where your code runs. The collector 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 a threat actor could reach from it. From this graph, Continuum learns which systems are business-critical, who owns them, how services depend on one another, and which data each one touches. It uses that picture to identify your highest-value systems, such as customer data stores, payment pipelines, and authentication services, and then ranks each resulting issue by how close its attack path runs to those systems.

Continuum analyzes each finding against your code and its environment context and assigns an evidence level, such as a verdict proven by static analysis of the vulnerable code path. For findings it can reproduce, Continuum runs the exploit in an isolated sandbox and attaches proof-of-concept code with the reproduction steps. It produces the attack path, the supporting source analysis, and a blast radius assessment instead of a risk score alone. It also evaluates whether your existing defenses would detect and stop the validated path.

For each confirmed issue, Continuum generates a fix (a code patch, a dependency upgrade, or a configuration change) and opens it as a pull request in your connected repository, ready to review. Every fix requires human approval: you review and merge the pull request, so the final decision stays with your team. In the future, you will be able to build confidence in specific remediation classes and let Continuum apply those fixes automatically once its confidence gates pass, such as test coverage, scope bounds, and historical success rate.

AWS Continuum for code vulnerabilities in action
To show how this works, I open AWS Continuum in the console and go to Code vulnerabilities. Before I can review issues, I set up an environment. I connect a code source, either a GitHub integration or an Amazon S3 bucket, and then create an environment that scans it on a schedule I choose. An Amazon S3 source has a couple of prerequisites: the bucket sits in the same account and AWS Region where I turn on AWS Continuum, and I grant access through an AWS Identity and Access Management (IAM) role that AWS Continuum assumes. I can optionally add AWS infrastructure context by setting up an AWS Continuum collector in the account and Region where my code runs and authorizing my environment to use it. For the full requirements and steps, see the AWS Continuum User Guide.

The Overview page brings these pieces together in one place, showing my Code integrations, the Environments built on them, and the status of any AWS collector that supplies AWS resource context.

I open one of my environments. The Issues tab lists validated, prioritized issues rather than raw scanner output, each with a severity, a status, and the time it was created. I choose one of the issues.

The Overview rates it High severity, with the status Completed and the remediation already Delivered to GitHub. The Risk assessment explains why. Continuum rates its Exploitability as Exploitable, with an evidence level of Static proven and a validation run status of Completed. Likelihood is High, since the service is reachable from an attacker, requires no authentication, and needs no user interaction. Impact is Moderate, which means an attacker gains the ability to modify business data, with a blast radius reaching other users in the same tenant. A Proof section includes the source analysis behind the verdict.

The Remediation section shows a fix already delivered as a pull request in GitHub, changing four files, with 50 lines added and 24 removed across the cart service. Continuum opens the fix as a pull request titled Continuum fix, and I choose View pull request to open it in GitHub. The console is explicit that a generated patch does not mean the issue is fixed. I still review and merge it, which keeps the final decision with my team. A Contributing findings section lists the specific scanner finding this issue was built from.

The pull request description carries the same risk assessment, remediation summary, and proof from the console, so whoever reviews it in GitHub sees the evidence without leaving their workflow.

The Findings tab lists the raw scanner findings across the environment, the evidence that issues are built from.

The Scans tab shows the history of each scan with its status, origin, and request and completion times, and I use Configure scan frequency to change the cadence or Queue scan to run one on demand. The Configuration tab is where I manage the environment: the code and context sources it reads from, its code integrations, environment settings such as whether Continuum creates remediation patches, and the AWS collectors it uses for AWS context.

In a single workflow, I work through the validated issues in priority order with each scan, reviewing the evidence and scope behind each one before I approve and merge the fixes I trust. Every fix waits for my approval, so the backlog keeps shrinking while my team keeps control of what ships.

Now available
AWS Continuum for code vulnerabilities is available today in US East (N. Virginia) and US West (Oregon) Regions. For pricing, visit the pricing page.

To learn more, visit the AWS Continuum for code vulnerabilities product page and the User Guide. Give it a try in the AWS Continuum console today, and send us feedback through your usual AWS Support contacts.

— Esra