AWS explains Continuum deployment gates, with baseline and fail-open cautions
AWS published an October 14 guide to using Continuum for penetration testing as a post-deployment gate. The pattern deploys a change to staging, runs a test scoped to that change, and can block promotion to production when a validated exploitable finding reaches a selected severity threshold.
The integration compares the commit being gated with the previous commit cleared by the gate. An in-scope result evaluates findings against the chosen threshold. A scoped-out result passes when nothing security-relevant changed within the configured scope. A scope conflict means the change fell outside the configured scope and was not tested; teams choose whether that blocks promotion.
Three independent settings control failure: the findings severity threshold, the handling of scope conflicts, and the handling of infrastructure errors. AWS says fail-on-infrastructure-error defaults to false, which is fail-open. Its guide recommends setting that option to true when promotion requires security sign-off. A passing pipeline is therefore not evidence that every error would have stopped a release.
Report-only mode also needs care. A passing run advances the baseline even when the threshold is NONE. Tightening the threshold later does not automatically retest commits that an earlier report-only run cleared. AWS describes overriding the base and head commit identifiers when a stricter check needs to reassess an earlier range.
The guide covers a pattern for GitHub Actions, GitLab CI/CD, Bitbucket Pipelines and Azure DevOps Pipelines, with a worked GitHub Actions example. Authentication uses short-lived OIDC federation and an IAM role rather than stored AWS access keys. Teams must still verify the target domain, configure the test scope and repository connection, and limit which pipelines can assume the role.
For buyers and security teams, the useful question is what a successful gate actually covered. Review scope decisions, baseline changes, error handling and permissions before relying on it for release approval. AWS also warns that GitLab pipeline variables can override job defaults, so committed configuration alone does not guarantee the intended enforcement. These controls do not establish that an entire application is free of vulnerabilities.