A Vulnerability Scanner That Proves Its Findings Instead of Just Listing Them
Most vulnerability scanners produce a list of findings ranked by a generic severity score and leave security teams to figure out which ones actually matter in their specific environment. AWS Continuum, generally available since October 22 in US East (N. Virginia) and US West (Oregon), takes a different approach. It builds a context graph of an organization's business critical systems, owners, and dependencies, then reproduces reproducible findings as live exploits inside an isolated sandbox, attaching proof of concept code and reproduction steps to each one.
That validation step is the actual product. Instead of a risk score alone, Continuum delivers an attack path, a blast radius assessment, and an evidence level such as static proven for each finding, along with an assessment of whether a customer's existing defenses would even catch the exploit as it moves toward systems like customer data stores, payment pipelines, and authentication services. For security teams drowning in scanner output that can run into thousands of findings a day, that is the difference between a report nobody reads and a prioritized queue someone can actually work. The console itself reflects that reorganization, with separate tabs for overview, issues, findings, scans, and configuration rather than a single undifferentiated results list.
Fixes Arrive as Pull Requests, Not Automatic Changes
Continuum proposes remediations as code patches, dependency upgrades, or configuration changes, and every one of them opens as a pull request titled Continuum fix rather than applying automatically to production. AWS's own documentation is explicit on this point: every fix requires human approval. In an industry increasingly comfortable letting AI agents write and ship code with minimal review, that constraint is a notable design choice from the vendor with the largest footprint of production workloads to protect.
AWS has already signaled this will not stay fully manual forever. The roadmap includes letting Continuum apply certain classes of fixes automatically once confidence gates around test coverage, scope bounds, and historical success rate are met. That is the right long term direction for a tool handling thousands of findings at scale, but it also means security leaders adopting Continuum now are making an early decision about how much autonomy they are comfortable granting later, and should set that policy deliberately rather than let default settings decide it for them.
The Timing Is Not a Coincidence
Continuum's general availability landed in the same week AWS disclosed that its honeypot network caught a PHP2Shell exploitation attempt on October 17, a full four days before the two related CVEs it targeted were publicly disclosed. AWS also noted that proof of concept exploits for the flaws were circulating roughly 12 hours before the coordinated disclosure embargo was due to lift. Taken together, that means attackers had functional exploit code in hand before defenders had an official advisory to work from.
That sequence is the strongest practical argument for a tool like Continuum that any vendor could offer this year. A security program built around patching known CVEs after public disclosure is structurally behind an adversary ecosystem that now sometimes moves before disclosure happens at all. Validated, prioritized, pre-built remediation is the only realistic answer to a timeline that short, and AWS timed Continuum's launch to make exactly that case, pairing a product announcement with a concrete, dated example of the threat it is designed to answer rather than leaving the pitch abstract.
Where Continuum Fits Against the Existing Security Stack
AWS is not entering an empty market. Static analysis, software composition analysis, and cloud security posture tools from established vendors already compete for budget in most enterprise security stacks, and several have added AI assisted triage or fix suggestions of their own over the past year. Continuum's differentiation is not the AI layer itself but the depth of the context graph: mapping findings against named systems like payment pipelines and authentication services, rather than generic asset tags, and tying remediation directly into the AWS environment the workload already runs in.
That tight coupling to AWS infrastructure is both the product's strength and a lock-in consideration security leaders should weigh honestly. A tool that understands AWS Config resources and network reachability natively will likely out-triage a third party scanner bolted on from outside, but it also deepens a customer's dependency on AWS's own tooling for a function, security remediation, that most enterprises have historically kept vendor agnostic on principle. That tradeoff deserves an explicit conversation in procurement, not a default assumption that deeper integration is strictly better.
What This Means for Security and Engineering Leadership
CISOs and CTOs evaluating Continuum should treat the human approval requirement as the current floor, not the ceiling, and start building the governance process now for the automatic remediation tier AWS has already signaled is coming. Deciding in advance which fix classes, environments, and risk levels qualify for autonomous patching is a far better position than scrambling to write that policy after the feature ships and an engineering team asks why it is not turned on.
The broader lesson for enterprises sitting on AWS, regardless of whether they adopt Continuum specifically, is that the gap between disclosure and exploitation is shrinking toward zero. Patch management processes built around a comfortable window between a CVE's publication and the first real world exploit attempt need to be re-tested against a world where that window can already be negative. That is a governance conversation for the board, not just a tooling decision for the security team, and it is a conversation worth having before the next honeypot catch makes headlines rather than after.
