9.1 DevSecOps Pipeline: Signals, Gates, and Artifact Promotion

DevSecOps runs security checks with each change and delivers results to the people responsible for acting on them. The pipeline itself holds source code, artifacts, release permissions, and secrets, making it a high-value attack surface.

Answer Questions at Each Stage

Before commit: secrets, formatting, and quick checks for dangerous patterns
PR review: SAST, dependency/license checks, IaC policy, unit security tests, threat-model changes
Build phase: lock dependencies, isolate runner, generate SBOM/provenance, sign artifacts
Test environment: DAST, API authorization matrices, fuzzing/integration testing, configuration validation
Release: verify digest/attestation/policy, approvals, gradual deployment
Runtime: detect attack signals, monitor configuration drift, assess vulnerability reachability, feed findings back into backlog

Quick checks should provide developer feedback within minutes. Time-consuming fuzzing and full-scale DAST scans can run asynchronously. High-risk releases must wait for corresponding evidence; async execution should never be used as a permanent escape hatch.

Bind Checks to the Delivery Object

Source code scanning, build directory scanning, and final container or package scanning address different questions. Multi-stage images might omit build dependencies or inadvertently include binaries not present in the lockfile during the build process.

All results must be tied to immutable identities:

source revision → artifact digest → SBOM/provenance → deployment revision

If the report only records image:latest, it will be impossible to verify at repair time that the scan corresponds to the current running artifact.

Gate is Determined by Risk and Confidence

Block immediately: newly submitted secrets, disallowed licenses, high-confidence executable injections, unsigned published artifacts, publicly exposed management ports in production IaC configurations. Require manual triage: low-confidence SAST findings, CVEs present only in development dependencies, optional components whose reachable paths remain unconfirmed. A development dependency omitted from the final image may still execute during the build, steal credentials, or modify the output. The dev label does not make it harmless.

Exceptions do not disable rules:

finding + exact scope + evidence + compensating control
owner + approved_by + expiry + review trigger

For example, an exception allows finding F on digest D until Friday at 18:00. Digest D2 cannot inherit it, and D is blocked again after expiry. Missing time, finding identity, or evidence should produce an unresolved or failed decision, not unconditional approval.

Blocking resumes when an exception expires. Broad repository exemptions permanently suppress future issues, risking the disappearance of genuine problems that emerge later.

PR from a fork is considered untrusted code

Attackers can modify workflow, test, and build scripts to steal CI secrets. When handling external PRs:

• Do not inject secrets into untrusted code; non-production credentials can also grant important access;
• Use read-only, short-lived tokens;
• Isolate runners and destroy them after each task completes;
• Disallow mounting the host Docker socket or sharing credential caches;
• Privileged release jobs run only on revisions that have been reviewed and merged;
• Any post-approval execution must verify which commit and workflow version is actually being executed.

Self-hosted runners can carry contamination between builds through networking, caches, and persistent disks. A privileged follow-up job must not blindly execute scripts or restore executable caches from a low-trust PR. In GitHub Actions, pull_request_target runs in the base repository context; checking out and executing PR-head code there can bring untrusted code into a privileged environment.

Artifacts Are Built Only Once

build digest D
→ test D
→ staging deployment D
→ production promotion of the same D

Rebuilding across environments introduces untested differences. By decoupling environment configurations from artifacts, the release system updates only the verified digest. Database migrations and feature flags still require independent compatibility strategies.

Measure by Impact, Not by Scan Count

Meaningful metrics: rate of new risk mitigations, time from detection to resolution, developer wait time due to false positives, exception overruns, runtime escape issues, artifact evidence coverage. An increase in scanner findings may simply reflect more rules, not a more dangerous system or a more mature team.

The next lesson covers secrets, policy enforcement authority, and runtime feedback.

References

• NIST, SP 800-218 SSDF 1.1
• OWASP, CI/CD Security Cheat Sheet