AWS Launches Continuum With Human Approval for Vulnerability Fixes

AWS announced the general availability of Continuum for code vulnerabilities, a security service it says finds and validates code vulnerabilities and delivers fixes as patches or pull requests. According to AWS, the service confirms which findings are exploitable, ranks issues by business impact and proposes a fix for each. AWS states that every remediation begins in a mode where Continuum proposes a fix and a person approves it before it ships. Amazon AWS report.

What AWS Says the Service Does

AWS says Continuum identifies exploitable findings, ranks issues by business impact and proposes fixes. The announcement positions contextual validation, rather than a generic severity score alone, as the basis for deciding which issues to address first.

The company says some scanner findings need no action because they are unreachable, unexploitable or already mitigated by a runtime control. It argues that generic severity scores do not capture which resources an attacker can reach. These are AWS’s explanations of the service’s purpose, not independent measurements of its performance.

Related coverage: security operations coverage.

Evidence Levels and Sandbox Reproduction

Continuum builds a context graph from two primary sources, AWS says: customer code repositories and the AWS environment. For AWS, a customer sets up a collector in the account and Region where code runs; AWS says the collector gathers resource details such as AWS Config resources and network configuration so Continuum can judge reachability and what a threat actor could reach.

AWS says Continuum assigns an evidence level, including verdicts supported by static analysis. For findings it can reproduce, the company says the service runs an exploit in an isolated sandbox and attaches proof-of-concept code and reproduction steps. AWS explicitly distinguishes a generated patch from a fixed issue.

Related coverage: AI security reporting.

Human Approval Is Mandatory Today

Every remediation starts in a mode where Continuum proposes the fix and a person approves it before it ships, AWS states. In the described workflow, Continuum generates a fix as a code patch, dependency upgrade or configuration change and opens it as a pull request in a connected repository for review. AWS says the customer reviews and merges the pull request, so the final decision stays with the team.

AWS describes autonomous remediation as future functionality, with customers eventually choosing permitted actions within defined guardrails. Proposed confidence gates include test coverage, scope bounds and historical success rate. For current procurement, our recommendation is to evaluate the approval-based workflow rather than assume those planned automated actions are available.

Related coverage: enterprise cybersecurity analysis.

Availability and Setup Inputs

AWS says Continuum for code vulnerabilities is available in US East (N. Virginia) and US West (Oregon). Customers connect a code source, either a GitHub integration or an Amazon S3 bucket, and create an environment that scans on a chosen schedule, according to AWS. AWS says an S3 source must sit in the same account and Region where Continuum is enabled, with access granted through an IAM role that Continuum assumes.

Adding AWS infrastructure context through a collector is optional in the described setup. AWS directs readers to its User Guide for full requirements and to a separate pricing page for charges. Our recommendation is to confirm both against the intended configuration before deployment.

Related coverage: cloud security coverage.

What This Means for Practitioners

Our recommendation is to evaluate Continuum as an approval-based security workflow rather than an autonomous fixer. Check service-region availability, source-access requirements and IAM permissions before a pilot. Decide whether to configure infrastructure context, and require reviewers to inspect the supporting evidence and proposed changes. Test each accepted fix in the intended environment rather than equating a generated patch with a resolved vulnerability. Define who can approve and merge changes, how failed fixes are escalated and what evidence must be retained. Keep any future automated-remediation option outside the pilot assumptions until its availability and controls are verified.