AWS Continuum's Two-Part Pricing Turns Exploit Validation Into a Procurement Problem

AWS has made Continuum for code vulnerabilities generally available in two regions, with pricing based on findings processed and lines of code. ¹ For security and engineering leaders, the decision isn't just whether exploit validation and proposed fixes improve the vulnerability workflow. It's whether either billing unit behaves predictably against their own codebase.

Continuum runs real exploits in a sandbox to prove whether a reported vulnerability can be exploited, then opens a fix as a pull request. ¹ That links validation to remediation in a way a scanner that stops at a finding does not. It also makes sandbox boundaries, fix review, and the definition of each pricing unit relevant to the buying decision.

What AWS Continuum Adds to a Code Vulnerability Scanner Report

A reporting scanner hands a team findings to triage. Continuum adds an exploitability check, running real exploits in a sandbox against a reported vulnerability, and then opens a pull request with a fix. ¹

This could help teams prioritize findings shown to be exploitable and route a proposed change into developer review. It does not establish that every validated finding is urgent, that unvalidated findings are safe to ignore, or that false positives disappear. Those are outcomes a buyer has to test, not assumptions to adopt.

Track these separately during an evaluation:

• Findings reported
• Findings validated as exploitable
• Proposed fixes accepted after review

The source describes the validation and pull-request steps but reports no rates for these measures. ¹ Without measuring them in a pilot, there's no way to know whether the workflow cuts triage effort or moves work into exploit review and code review.

AWS Continuum Pricing: Reading the Two-Part Model

AWS's published pricing has two units, findings processed and lines of code, but the source does not state prices or counting rules. ¹ Repository count alone won't produce a budget number.

As a planning placeholder, not AWS's actual invoice formula, a team might model:

Expected cost = findings processed × per-finding price + lines of code × per-line price

Both prices and counting rules have to come from AWS before this is useful for procurement. ¹

The two units create different potential exposure. A large codebase with few findings may be more sensitive to a per-line charge; a smaller codebase generating many processed findings may be more sensitive to a per-finding charge. Run both scenarios against your own repositories. Don't assume repo size or finding volume alone predicts the bill.

Before signing anything, ask AWS: What counts as a "finding processed," and how are repeat scans and recurring findings handled? How are lines of code counted, and does unchanged code get billed again on every scan? How do the two units apply when a scan covers only part of a repository? The source does not answer these questions. ¹ Until it does, treat any cost model as provisional.

When Exploitability Validation Tools Earn Their Keep

Exploit validation may be useful when a security team has a large queue and needs stronger evidence to triage it. Continuum's stated sequence, run the exploit and then open a pull request, only pays off if it improves on the team's existing process in time or effort. ¹ That depends on the triage baseline, the quality of the validation signal, and the review each proposed fix requires.

A pilot should compare the current workflow with the Continuum workflow using measures the organization already tracks: time from finding to developer review, analyst hours spent on triage, pull-request acceptance rate, and findings left unresolved. The source reports no results for these measures. ¹ Treat them as tests, not conclusions. Weighing vendor security claims against the evidence they actually provide is a recurring theme; OpenAI's Security Plan Has Two Tracks. Security Leaders Need Two Evidence Standards. takes up a similar question in a different context.

A scanner-only workflow can still be the right choice for teams that want broad detection without running exploits against their code or receiving automatically proposed fixes. That's a difference in operating model, not evidence that Continuum fails a security process.

Exploitability shouldn't become the sole prioritization filter. A finding may still demand action for policy reasons, exposure, or potential impact, even if the sandbox hasn't proven it exploitable. Decide how to handle those cases before using validation results to reshuffle remediation priorities.

What the Sandbox Needs to Prove

The source confirms that Continuum runs real exploits in a sandbox but says nothing about its isolation model. ¹ Before enabling it, security teams should establish what an exploit can reach during validation: network paths, credentials, source code, build systems, test data, and external services. The same logic applies to any automated system that acts on your environment; AI Agent Security Needs a Tool Boundary, Not Just Better Prompts argues for defining that boundary explicitly.

Ask whether outbound access is restricted, how secrets are handled, whether validation runs against production-like dependencies, and what evidence remains after an exploit run. These are open implementation questions in the available source, not assumptions about how AWS built the service. ¹

Regional availability deserves the same scrutiny. Continuum is generally available in two regions, but the source does not name them or say whether more are planned. ¹ Confirm which regions apply to your organization and whether they meet your deployment requirements before using the service in a production workflow.

Make the security review a gate, not a follow-up. Document the regions in play and the sandbox boundaries AWS confirms in writing. If the review can't establish what an exploit can reach, limit or delay the pilot.

Reviewing Automated Vulnerability Fixes

Continuum opens fixes as pull requests after running exploits in a sandbox. ¹ A pull request is a proposal, not proof of correctness; the source doesn't say what tests Continuum runs before opening one. ¹

Repository owners should review affected code and any dependency or configuration changes, run regression and security tests, and confirm intended behavior holds. Apply the same gates used for any other security-sensitive change until there's evidence a different process is warranted. For a parallel on gating automated output before it is trusted, see Can Validation Gates Make Agentic AutoML Dependable?

Confirm which languages, repositories, and vulnerability types Continuum supports; the source doesn't specify its coverage. ¹ A clean pilot on one repository or vulnerability class says nothing about the rest of the estate.

The source describes pull-request creation but does not document automatic merging. ¹ It reports that practitioners are asking what would justify letting Continuum merge fixes on its own. ¹ Don't build a process around automatic merging until AWS specifies the capability and the organization has defined approvals, tests, rollback, and exception handling.

Who Owns the Decision

Security should own the policy for enabling exploit validation; repository owners should keep final say on accepting code changes. That split is a suggested ownership model based on the stated sequence of validation followed by a proposed fix; the source documents no specific ownership model. ¹

For a pilot, name who can enable validation, which repositories are in scope, who reviews generated pull requests, and what counts as evidence a finding is closed. Log rejected fixes and the reasons. That record can help determine whether the remediation step reduces work or moves it into code review.

Before Procurement Signs Off

Get current prices and counting rules for findings processed and lines of code; the source confirms those two pricing units but gives no prices or counting rules. ¹ Model your own history across scenarios such as low finding volume on a large codebase, high finding volume on a smaller one, and repeated scans of a changing codebase. Treat every output as an internal estimate until AWS confirms its billing logic.

Run a controlled pilot on representative repositories. Compare triage time, validated findings, pull-request acceptance, and review effort against the current workflow; the source provides no pilot data. ¹ In parallel, close out the security review: regional availability, sandbox boundaries, supported languages and vulnerability types, and how fixes are tested before a human reviewer sees them. ¹

Next step: request pricing definitions and sandbox details from AWS in writing, then scope a pilot with named repository owners, explicit approval gates, and measures for security value and engineering effort.