Pipeline & Scanning exit conditions
Candidate exit conditions for the Pipeline & Scanning type. See the catalog overview for how to adopt these.
CI/CD gates and status checks
| Exit condition | What it checks |
|---|---|
|
Every commit on the branch produces a passing CI pipeline run with no failed jobs. |
|
All branch-protection required status checks are configured and reported as passing. |
|
Merge is blocked whenever any required pipeline job reports a failure. |
|
No required CI job is skipped, cancelled, or marked neutral to satisfy the gate. |
|
The full pipeline is triggered on every pull request against a protected branch. |
|
The most recent pipeline run on the default branch is in a passing state. |
|
Status checks are re-run against the merge result rather than a stale head commit. |
|
No required check was dismissed or force-passed by an administrator override. |
|
Every leg of a build matrix completes successfully before the check is green. |
Static analysis and code quality
| Exit condition | What it checks |
|---|---|
|
Static application security testing reports no open findings above the configured threshold. |
|
No high or critical severity SAST findings remain unresolved on the scanned revision. |
|
SAST is executed as a required stage on every pipeline run, not on a schedule only. |
|
The configured quality gate (e.g. SonarQube) returns a passing status for the analysis. |
|
Code coverage meets or exceeds the enforced minimum threshold in CI. |
|
Coverage on changed lines does not drop below the project baseline. |
|
The build does not disable or downgrade warnings-as-errors to pass compilation. |
|
Configured linters report zero errors on the scanned source tree. |
|
Measured code duplication stays under the configured maximum percentage. |
|
No new maintainability issues are introduced above the accepted debt ratio. |
Dependency and supply-chain scanning
| Exit condition | What it checks |
|---|---|
|
Software composition analysis reports no dependencies with known vulnerabilities above threshold. |
|
No dependency carries an unresolved critical-severity CVE at build time. |
|
A committed lockfile fully pins the resolved dependency graph. |
|
No resolved dependency version has been yanked or withdrawn upstream. |
|
Transitive dependencies, not only direct ones, are included in the vulnerability scan. |
|
The license compliance scan passes against the approved-license policy. |
|
No dependency ships under a denylisted or copyleft-incompatible license. |
|
No dependency is older or more stale than the maximum allowed by policy. |
|
The vulnerability database used by the scan is within the allowed freshness window. |
Secret and credential scanning
| Exit condition | What it checks |
|---|---|
|
Secret scanning reports no detected secrets in the scanned changes. |
|
Secret detection covers the full commit history, not only the latest diff. |
|
No hardcoded passwords, API keys, or tokens are present in source or config. |
|
No private keys or certificate material are committed to the repository. |
|
Any secret flagged as verified-active has been revoked before the gate passes. |
|
Secret scanning runs on push and blocks the pipeline when triggered. |
|
Build artifacts contain no embedded cloud credentials or session tokens. |
|
Environment and secret files are excluded from version control and artifacts. |
Infrastructure, container, and dynamic scanning
| Exit condition | What it checks |
|---|---|
|
Infrastructure-as-code scanning reports no misconfigurations above the threshold. |
|
IaC scanning finds no resources unintentionally exposed to the public internet. |
|
Infrastructure definitions pass the organization’s policy-as-code rule set. |
|
Container image scanning reports no vulnerabilities above the configured threshold. |
|
The built container image contains no unresolved critical-severity CVEs. |
|
The container base image is a currently supported, non-end-of-life version. |
|
The container image is configured to run as a non-root user. |
|
The image contains no unnecessary packages beyond the runtime’s needs. |
|
Dynamic application security testing reports no findings above the threshold. |
|
No high-severity DAST findings remain open on the tested deployment. |
Build reproducibility and hermeticity
| Exit condition | What it checks |
|---|---|
|
Rebuilding from the same source yields a bit-for-bit identical artifact. |
|
The build runs in an isolated environment with fully declared inputs. |
|
All build tools are pinned to exact, verified versions. |
|
The compiler and language toolchain versions are pinned rather than floating. |
|
The build performs no unmanaged network access after dependency resolution. |
|
All build inputs are content-hashed and recorded for verification. |
|
Artifacts embed normalized timestamps to preserve reproducibility. |
|
Dependency resolution is fully locked and does not vary between builds. |
Artifact integrity and provenance
| Exit condition | What it checks |
|---|---|
|
Every released artifact is cryptographically signed by the pipeline. |
|
Artifact signatures are verified against a trusted key before promotion. |
|
A software bill of materials is generated for each build. |
|
The generated SBOM is attached to and distributed with the release. |
|
A signed provenance attestation accompanies each produced artifact. |
|
The build provenance satisfies the required SLSA level. |
|
Artifacts are referenced by immutable content digest rather than mutable tag. |
|
Consumed artifacts are integrity-checked against their recorded digests. |
|
Provenance is generated by the trusted build platform and cannot be forged by the build. |
Pipeline security and hardening
| Exit condition | What it checks |
|---|---|
|
Pipeline definitions are version-controlled and code-reviewed before merge. |
|
CI actions and reusable workflows are pinned to full commit SHAs. |
|
No third-party CI action is referenced by a mutable tag or branch. |
|
Build caches are scoped and validated to prevent cross-branch poisoning. |
|
Release branches enforce protection rules against direct or force pushes. |
|
Deployment to protected environments requires a recorded manual approval. |
|
Deployment gates block promotion until all upstream checks succeed. |
|
CI secrets are scoped to the minimum environments and jobs that need them. |
|
Pipeline runners operate with least-privilege credentials and permissions. |
|
Untrusted code does not execute on self-hosted runners with elevated access. |