Pilot AWS Continuum's new code-vulnerability workflow in Learn mode with bounded access, isolated validation, human patch review and rollback evidence.

What became generally available

AWS announced general availability of AWS Continuum for code vulnerabilities on October 22, 2026. AWS says the service builds a context graph from AWS resources, identity relationships and network reachability; ingests vulnerability findings; scans code; validates exploitability in an isolated sandbox; prioritizes business impact; and proposes remediation pull requests with exploitability proof and blast-radius assessment.

AWS describes Learn mode for proposing fixes that people approve and Enforce mode for autonomous action inside configured guardrails. The announcement says Continuum works with GuardDuty and Security Hub, but it does not publish pricing, trial terms or detailed setup on that page. Confirm current console availability, region, cost and source-control support before a pilot.

Firecrawl returned AWS's October 22 announcement prominently and The New Stack's October 24 analysis first for a focused feature query. The independent article challenged how headline benchmark percentages should be interpreted. Search placement shows fresh attention, not product effectiveness or market adoption.

A safe pilot starts with an ingested finding, sandbox validation, proposed patch, human review and a separate merge.
Recommended Learn-mode flow. Do not combine proposal, approval and merge authority.

1. Choose a low-consequence repository and define success

Select one maintained nonproduction service with tests, an accountable owner and a disposable environment. Exclude secrets, regulated data, customer repositories and critical deployment credentials. Record languages, build commands, protected branches, current findings and rollback method.

Define success before connecting the service: findings arrive with reproducible evidence, proposed patches are understandable, tests remain green, reviewers can reject safely, audit events identify the actor and the original branch is recoverable. Do not use a vendor benchmark percentage as your acceptance threshold.

The expected pilot artifact is a signed scope with repository, AWS account, permitted data, roles, regions, budget, duration, reviewers and stop owner. If pricing is not clear in the console or contract, set a spending alert and obtain a quote before running sustained work.

Pilot guardrails require a synthetic repository, no production secrets, read-only context, isolated validation and fail-closed behavior.
Keep the first evaluation small enough to inspect every decision.

2. Connect with minimum identity and source-control authority

Use a dedicated pilot account or isolated environment and a dedicated source-control integration. Grant only the repository and actions required to read code, create a branch and open a pull request. Do not grant direct writes to protected branches, production deployment or broad organization administration.

Review the context graph inputs and AWS resources exposed to the service. Remove unrelated accounts, identities and networks from scope. Keep secrets in approved stores and scan proposed branches before a reviewer opens them locally.

Test revocation before the first full run: disable the integration, revoke the role and confirm new jobs cannot read or write. Preserve audit logs outside the workspace so the service cannot be the only narrator of its actions.

A developer and security engineer define a narrow repository, identity and validation scope for an AI vulnerability agent.
AI-generated conceptual illustration: constrain repository, environment and identity before execution.

3. Review exploitability proof and blast radius separately

For each finding, capture source location, vulnerability class, reachable path, validation environment, exploitability evidence, affected AWS resources, proposed change and confidence. Reproduce the behavior in the isolated environment with an approved test; do not target production or internet systems.

Suggested reviewer prompt for a separate approved assistant: ‘Compare this sanitized finding, patch diff and test output. List supported claims with exact evidence IDs, identify behavior changes and missing tests, and mark reproduction failures unresolved. Do not approve the patch or infer production exploitability.’

The New Stack reported that AWS's headline CyberGym-E2E result reflected 819 of 920 completed tasks, while only 37.8% addressed the benchmark's selected historical vulnerability. The article also noted the agent was not told which historical bug to fix. Treat benchmark findings as context, not a promise about your repository.

A finding review separates exploitability, blast radius, patch diff, tests and independent reproduction.
Evaluate the evidence chain instead of a single severity or benchmark score.

4. Validate the patch like any untrusted contribution

Require code-owner review, static analysis, dependency checks, unit and integration tests, negative security tests and a deployment preview. Inspect for broadened permissions, disabled validation, suppressed errors, new network access, logging changes and tests rewritten merely to pass.

Run the original reproduction and a non-regression suite on the proposed branch. Confirm the patch addresses the intended finding rather than a different flaw or only a crash symptom. Measure in your environment: accepted findings, unsupported claims, reviewer corrections, reopened issues and rollback events.

Keep deployment and merge credentials outside Continuum during the pilot. A human reviewer should merge through the existing protected workflow after evidence is complete.

Engineers compare an AI vulnerability finding with source code, logs and independent reproduction before reviewing a patch.
AI-generated conceptual illustration: evidence and code review remain human-accountable.

5. Test failure and rollback before Enforce mode

Simulate an unavailable sandbox, source-control denial, stale branch, failed test, conflicting change, false positive and cost limit. Decide whether the workflow fails closed and who can resume it. No security gate should silently pass because its validation infrastructure failed.

Revoke the integration, close proposed branches and restore the baseline. Verify that audit events, finding evidence and reviewer decisions remain available. Reconnect only through the documented approval path.

Do not enable autonomous enforcement simply because several patches were accepted. Require a representative sample, stable precision, bounded change classes, proven rollback and explicit business approval. Some repositories or vulnerability classes may remain permanently in Learn mode.

Promotion requires sampled precision, false-positive review, tested rollback, assigned owners and slow scope expansion.
Trust should be earned by observed pilot evidence, not inherited from a vendor benchmark.

A practical decision record

End the pilot with an inventory of supported repositories and regions, access granted, findings reviewed, patches accepted or rejected, costs observed, failures, unresolved limitations and the precise mode approved. State that AWS reported the service's capabilities and benchmark results; your evidence covers only the tested repository and period.

  • Start in Learn mode with one nonproduction repository.
  • Keep protected-branch merge and production deployment authority separate.
  • Reproduce findings and validate patches through the existing secure-development workflow.

Put the insight into practice.

Deep Security helps organizations assess risk, validate controls, and build a practical plan to strengthen their defenses.

Talk with Deep Security