Secret scanning has become the default CI/CD security recommendation: scan commits for API keys, tokens, and credentials, and prevent their accidental exposure in source code. Tools like GitLeaks, TruffleHog, and native platform features handle this well. Most engineering teams have implemented some form of secret scanning.
What most pipeline security guidance doesn’t cover is the broader attack surface of the CI/CD pipeline itself: image provenance verification, CVE gates on build outputs, hardening as a pipeline stage, and the controls that prevent a compromised pipeline from shipping vulnerable or tampered software.
Secret scanning prevents one category of supply chain risk. A comprehensive pipeline security posture requires a complete control checklist.
The CI/CD Security Layers That Secret Scanning Doesn’t Cover
Image provenance and build integrity
Secret scanning verifies that credentials didn’t leak into source code. It doesn’t verify that the container image produced by the build was produced by the authorized build process from the claimed source code.
Pipeline compromise—where a build step is modified to inject malicious behavior into the output artifact—produces images that look legitimate. They’re signed by the CI system’s identity, they pass post-build scanning, and they’re promoted to production registries. The compromise is in what the build step does, not in what secrets it exposed.
SLSA-aligned build provenance—signed attestations that document each build step, its inputs, and its outputs—provides the evidence layer that image signing alone doesn’t: not just “this image was signed” but “this image was produced by these specific steps from this specific source.”
CVE gates on build outputs
Container images produced by CI pipelines are build outputs that carry CVEs in their component inventory. Without CVE gating in the pipeline—a step that fails the build if CVE counts exceed defined thresholds—vulnerable images are promoted to registries and deployed to production because nothing stopped them.
Software supply chain security programs that add CVE gates to CI pipelines enforce a security standard at build time rather than detecting violations after deployment. The gate can be calibrated: fail on critical CVEs in packages confirmed as executing, warn on dormant CVEs, allow low-severity findings with documentation.
Hardening as a pipeline stage
Container hardening—removing unused packages, minimizing the installed toolchain, reducing the attack surface to what the application requires—is a pipeline stage that belongs between the build step and the registry promotion step.
A pipeline that builds a container and immediately promotes it to the registry is shipping whatever CVEs the build introduced. A pipeline that builds, hardens, and then promotes is shipping the minimized, hardened artifact. The hardening stage is the difference between what the build produces and what gets deployed.
Secret scanning secures the inputs to the pipeline. Provenance, CVE gates, and hardening secure the outputs. A pipeline security posture that only addresses inputs while ignoring outputs is half a security posture.
Building a Comprehensive Pipeline Security Checklist
Layer 1: Source integrity
Dependency scanning on package manifest changes (SCA in PR checks)
Secret scanning on every commit
SBOM generation from lock files in the development environment
Branch protection requiring review before merge
Layer 2: Build integrity
SLSA Level 1 provenance generation (minimum: document what built the artifact and what inputs were used)
SLSA Level 2 signed provenance with OIDC-based CI identity (for mature programs)
Hermetic build environment configuration (for SLSA Level 3 aspirations)
Layer 3: Output security
Container image scanning immediately after build
CVE gates configured at appropriate thresholds by severity
Container hardening as a pipeline stage before promotion
SBOM generation and attachment to the produced image
Layer 4: Registry integrity
Cosign-based image signing before registry push
Provenance attestation storage alongside the signed image
Secure software supply chain registry policies enforcing scanning before image availability
Immutable image tags for production registry entries
Layer 5: Deployment verification
Admission controller signature verification before pod start
SLSA provenance verification at deployment time
Registry source enforcement (only images from approved registries)
CVE threshold verification as a deployment gate
Practical Steps for Pipeline Security Beyond Secret Scanning
Add SBOM generation as a standard pipeline output. Every container produced by the CI pipeline should have an attached SBOM. This is a one-time pipeline configuration—add Syft or cdxgen as a pipeline step, store the SBOM artifact alongside the container image. No per-project developer work required.
Implement CVE gating calibrated to your risk threshold. Start with blocking only on critical CVEs in actively-executing packages (requires runtime profiling integration) or conservatively on any critical CVE. Adjust the threshold based on the CVE distribution you observe—gates that are too aggressive create developer friction; gates that are too permissive provide no security value.
Add Cosign signing to the promotion step. Image signing at promotion—the step where an image moves from the build registry to the production registry—provides the integrity guarantee that the promoted image is the one that passed security review. Unsigned images that fail the signature check at deployment are blocked before they run.
Document the complete pipeline control map. A document that maps each security control to the pipeline step that enforces it, and identifies which attack vectors each control addresses, serves two purposes: it reveals gaps in the current control coverage, and it provides audit evidence that the pipeline security design was intentional.
Frequently Asked Questions
What CI/CD pipeline security controls go beyond secret scanning?
CI/CD pipeline security beyond secret scanning encompasses controls at both the build integrity and output security layers. Build integrity controls include SLSA provenance generation (documenting what produced the artifact and what inputs were used) and Cosign-based image signing. Output security controls include container image CVE scanning with severity-gated thresholds, container hardening as a pipeline stage between build and registry promotion, and SBOM generation attached to every produced image. Secret scanning protects the pipeline’s inputs; provenance, CVE gates, and hardening protect its outputs—a complete CI/CD security posture requires both.
How do CVE gates in CI/CD pipelines improve software supply chain security?
CVE gates in CI/CD pipelines enforce a minimum security standard at build time by failing the build when container images contain CVEs above defined severity thresholds. Without gating, vulnerable images are promoted to registries and deployed to production because nothing in the pipeline stopped them. A software supply chain security program that adds CVE gates can calibrate the threshold—blocking on critical CVEs in confirmed-executing packages, warning on dormant package CVEs—so that the gate provides real security value without creating excessive friction. The gate is most effective when combined with container hardening, which reduces the CVE count before the gate evaluates the image.
What is SLSA provenance and why does it matter for CI/CD pipeline security?
SLSA provenance is a signed attestation generated during the build process that documents what was built, what CI system built it, and what source inputs were used. It matters for CI/CD pipeline security because image signing alone confirms that an image was signed—it doesn’t confirm that the image was produced by the authorized build process from the claimed source code. Pipeline compromise that injects malicious behavior into build steps produces signed images that still appear legitimate. SLSA provenance provides the additional evidence layer: not just “this image was signed” but “this image was produced by these specific verified build steps.”
How should container hardening be positioned in a CI/CD pipeline?
Container hardening should be positioned as a pipeline stage between the build step and the registry promotion step, not as an optional post-deployment activity. The hardened image—with unused packages removed and attack surface minimized—should be the artifact that enters the registry, not the raw build output. Placing hardening in the platform promotion pipeline rather than in team-controlled CI ensures it cannot be bypassed under delivery pressure. The hardening stage is the practical difference between what the build produces and what actually gets deployed to production.
The Pipeline as the Control Layer
The CI/CD pipeline is the chokepoint through which all software passes before deployment. Security controls embedded in the pipeline—not adjacent to it, not downstream of it—enforce standards at the point where enforcement is most efficient: before vulnerable or compromised software reaches production. Secret scanning is one control in that pipeline. A comprehensive security posture requires the full checklist.
