AWS Continuum for Penetration Testing Automates Exploitable Vulnerability Checks in CI/CD Pipelines

AWS has published new guidance on integrating AWS Continuum for penetration testing into continuous integration and delivery pipelines. The service, formerly known as AWS Security Agent, uses artificial intelligence agents to find and confirm exploitable vulnerabilities in deployed applications. This approach shifts security confirmation from periodic engagements to an automated gate that runs on every deployment.

According to the AWS Security Blog, traditional security tools like static analysis, software composition analysis, and dynamic scanners flag potential issues based on patterns and signatures. These tools indicate where to look, but penetration testing confirms actual exploitability. Historically, this confirmation occurred during out-of-band engagements scheduled separately from deployments, leaving gaps where code reached production without verified security clearance.

Context and Background

AWS Continuum for penetration testing addresses this gap by acting as a post-deployment gate in the pipeline. The gate automatically scopes the penetration test to the specific change being deployed. It can block promotion to production if a finding meets or exceeds a severity threshold chosen by the organization. This scoping mechanism tests only the changes since the last passing gate, rather than the entire application.

This targeted approach makes per-deployment penetration testing fast and economical enough to integrate directly into the software development lifecycle. The service determines the commit range, using the current commit as the head and the previously cleared commit as the base. Testing only the delta keeps the process efficient, allowing it to run on every deploy instead of on a quarterly calendar.

Who Is Affected

Developers and security teams using major CI/CD platforms can implement this pattern. The AWS Security Blog provides high-level overviews for integration with GitHub Actions, GitLab CI/CD, Bitbucket Pipelines, and Azure DevOps Pipelines. A specific worked example is provided for GitHub Actions. The pipeline deploys a change to a staging environment, runs the scoped test, and promotes to production only if the gate passes.

The gate authenticates to the AWS account through OpenID Connect and calls Continuum for penetration testing. All testing logic runs server-side within the AWS account, ensuring no penetration testing code executes on the CI/CD runner. Each run returns one of three scope decisions: in scope, scoped out, or scope conflict. These decisions are recorded in the console for audit and debugging purposes.

What should you do?

Security professionals should evaluate whether their current pipeline relies solely on pattern-based scanning. Integrating a tool that confirms exploitability can reduce false positives and provide clearer risk signals. Teams should review their severity thresholds to ensure they align with organizational risk tolerance before automating production blocks.

What to do and how to stay safe: AWS

• Review your current CI/CD pipeline to identify where static and dynamic analysis tools are currently integrated.
• Determine if your organization has defined severity thresholds for blocking production deployments based on exploitable vulnerabilities.
• Evaluate the feasibility of integrating AWS Continuum for penetration testing into your staging environment workflows.
• Monitor the scope decisions returned by the tool to understand how code changes impact your attack surface.

Step-by-step guide: Cloud Misconfiguration Response: Containment, Recovery and Prevention Steps

General security guidance from the Threat Times newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Does AWS Continuum test the entire application on every deployment?

No, the service scopes each test to the specific code changes since the last passing gate to keep the process fast and economical.

Which CI/CD platforms are supported by this integration?

The AWS Security Blog outlines integration patterns for GitHub Actions, GitLab CI/CD, Bitbucket Pipelines, and Azure DevOps Pipelines.

How does this differ from traditional SAST or DAST tools?

Traditional tools flag potential issues based on patterns and signatures, while AWS Continuum confirms whether those issues are actually exploitable.