Securing the CI/CD pipeline for container security means treating the build and delivery path as a first-class attack surface. You reduce risk by enforcing least privilege on runners, signing build provenance, scanning images before they ship, and gating releases on policy. The pipeline that produces your containers is part of the product's threat model.

TL;DR

• The CI/CD pipeline is a high-value target: it can inject malicious code or images into every deployment automatically.
• Adopt SLSA build levels incrementally; Level 2 (hosted, tamper-evident) is a realistic starting point for most teams.
• Generate and verify signed provenance with Sigstore/cosign and in-toto so consumers can trust what was built and how.
• Practice secrets hygiene: short-lived tokens, no long-lived creds in env, and OIDC federation to cloud instead of static keys.
• Run least-privilege runners: ephemeral, isolated, non-root, and network-restricted by default.
• Gate every build on vulnerability scanning (Trivy/Grype) and policy checks (Kyverno/OPA) before the image is promoted.

Why is the CI/CD pipeline a container security target?

The pipeline sits between your source code and production. An attacker who compromises it does not need to breach a cluster - they ride an already trusted path straight into every image you ship. The SolarWinds and Codecov incidents showed this pattern: trusted build infrastructure becomes the distribution channel for malicious artifacts.

Common pipeline threats include:

• Compromised runner: a reused or shared build agent with leftover state that an attacker poisons for later jobs.
• Poisoned dependencies: a malicious package or a hijacked registry pull that enters the build unverified.
• Stolen credentials: long-lived tokens in CI variables that leak through logs, forks, or PRs.
• Unsigned and unverified artifacts: images promoted to production with no provenance to prove who built them or what ran.
• Privilege creep: a build job that can push to any registry, deploy to any environment, or read every secret in the vault.

What are the SLSA build levels and which should you target?

SLSA (Supply-chain Levels for Software Artifacts) describes a maturity ladder for build integrity. It focuses on how an artifact was produced, not on whether its code is bug-free.

• Level 1: Provenance exists, but it is self-attested and unaudited. Better than nothing, easy to fake.
• Level 2: Provenance is generated by a hosted, tamper-evident build service, with a stronger identity. This is where most cloud CI platforms land today.
• Level 3: Builds run in a hardened, hermetic environment with a documented, reproducible build definition.
• Level 4: Builds are hermetic and reproducible - the same inputs always produce the same output, defeating tampering.

Most teams should target Level 2 first. GitHub Actions, GitLab CI, and Google Cloud Build can emit SLSA provenance today. Level 3 and 4 pay off for high-assurance environments but require hermetic builds that pull no network at runtime - a real engineering investment.

How do you produce and verify signed provenance?

Signed provenance answers three questions for every image: who built it, what source and inputs were used, and what steps ran. The toolchain is mature and open.

Use cosign (from Sigstore) to sign images and attach an in-toto attestation. A minimal flow looks like this:

# Build and push the image
docker build -t registry.example.com/app:1.2.3 .
docker push registry.example.com/app:1.2.3

# Generate SLSA-style provenance and sign it with Sigstore (OIDC, no key to store)
cosign attest --type slsaprovenance --predicate provenance.json \
  registry.example.com/app:1.2.3

# Sign the image itself
cosign sign registry.example.com/app:1.2.3

# Verify both the signature and the attestation before deploy
cosign verify registry.example.com/app:1.2.3
cosign verify-attestation registry.example.com/app:1.2.3

Verification belongs in the deployment gate, not just the build. A consumer - your admission controller or a Kyverno policy - should reject any image lacking a valid signature from your trusted identity.

Key practices:

• Use OIDC-based signing (Sigstore) so there is no long-lived private key to exfiltrate.
• Store provenance next to the artifact and reference it from your SBOM (CycloneDX or SPDX).
• Rotate identities and require freshness: reject attestations older than your release window.

What does good secrets hygiene look like in CI?

Secrets in CI are the fastest way to turn a minor bug into a full compromise. The goal is to make every secret short-lived and scoped, and to make leakage useless.

• Prefer OIDC federation: let the runner mint a temporary cloud token at job time instead of storing a static key. AWS, GCP, and Azure all support this from major CI providers.
• Scope secrets per environment: a staging job should not be able to read production credentials.
• Never echo secrets: disable command echo and redact them from logs by default.
• Pin trusted branches: do not expose secrets to jobs running untrusted fork PRs.
• Rotate on suspicion: any leaked run should trigger automatic rotation, not a manual ticket.

How do you run least-privilege runners?

The runner is the engine of the pipeline. If it is over-privileged, every job inherits that power. Treat runners as disposable, isolated, and minimal by default.

• Ephemeral by default: spin up a fresh runner per job (container or VM) and tear it down after. No shared state, no lateral movement.
• Non-root inside the job: build containers as a non-root user and drop capabilities.
• Network-restricted: deny outbound to the internet except allow-listed registries and package mirrors.
• Minimal permissions: the job token should only push to its target repo and registry, nothing else.
• Separate privileged work: anything that needs Docker-in-Docker or kernel access runs in a quarantined pool, never on the shared fleet.

How do you gate releases on security policy?

Gating is where pipeline security becomes enforceable rather than advisory. A gate is a check that must pass before an image is promoted, and it fails closed.

A practical gating stack:

• Scan the image with Trivy or Grype for CVEs and misconfigurations before it leaves the build.
• Generate an SBOM with Syft so every component is inventoried and auditable.
• Enforce policy with Kyverno or OPA/Gatekeeper: require a signature, block known-exploited (KEV) CVEs, and fail on criticals above a CVSS or EPSS threshold.
• Run runtime guardrails like Falco or eBPF-based detection in staging to catch anomalous behavior before production.

RapidFort can help here by hardening images to remove unused packages and shrink the CVE surface before the scan gate runs - fewer findings means a gate you can actually enforce instead of one you bypass.

Securing the CI/CD Pipeline for Container Security FAQ

What is the difference between pipeline security and supply-chain artifact security?

Pipeline security protects the process that builds and ships software - runners, credentials, gates, and provenance. Artifact security focuses on the resulting image: its CVEs, SBOM, base image, and configuration. They overlap but are distinct; this post covers the pipeline path, while artifact hardening is a sibling concern you can layer on top.

Do I need SLSA Level 4 to be secure?

No. Level 4 (hermetic, reproducible builds) is valuable for high-assurance workloads but expensive. Most teams get strong assurance at Level 2 by using a hosted build service that emits signed, tamper-evident provenance. Move to Level 3 or 4 only when your risk profile or compliance requirements demand it.

Can I sign images without managing private keys?

Yes. Sigstore uses OIDC identity (your CI provider proves who you are) to issue short-lived signing certificates. There is no long-lived private key to store or leak. cosign handles the signing and verification transparently once the workflow is configured.

How do I stop secrets leaking through CI logs?

Disable command echo, redact secrets by default, and use OIDC federation so there is no static credential to leak in the first place. Also scope secrets per environment and never expose them to untrusted fork PRs. Treat any run that printed a secret as compromised and rotate.

What should the first pipeline gate I add be?

Start with image signing plus a vulnerability scan before promotion. Signing establishes provenance you can verify later, and a scan gate (Trivy or Grype) blocks known-exploited and critical CVEs from reaching production. Add SBOM generation and policy enforcement (Kyverno/OPA) once the basic gate is stable.