Skip to main content
Previously we covered securing what runs inside the cluster — RBAC, admission control, Pod Security Standards, and mTLS. This final lesson shifts left: we secure what gets into the cluster in the first place. In this article we focus on protecting the CI/CD supply chain: container images, build dependencies, and artifacts. If attackers can’t breach your runtime, they will try to compromise the pipeline that produces the runtime. Here we walk through image scanning, image signing, and admission-time enforcement that together satisfy SLSA and SBOM-driven supply chain integrity.
A slide titled "Learning Objectives" with a blue gradient sidebar and numbered colored markers. It lists objectives like image scanning for vulnerabilities, image signing for provenance, admission policies enforcing scanning/signing, and SLSA/SBOM concepts for supply chain integrity.

​
Why supply-chain security matters

Supply chain attacks are especially damaging because they subvert trust at the source — if the build produces a compromised artifact, every deployment that consumes it is at risk. Typical vectors include:
  • Vulnerable base images (public images with known CVEs).
  • Compromised dependencies (malicious packages injected into NPM, PyPI, Go modules, etc., during build).
  • Tampered artifacts (images modified after build and before deploy).
  • Unscanned images promoted straight to production without gating.
These threats target the build and release process rather than runtime. The defense is to shift security left into CI/CD and enforce gates that validate artifacts before they reach the cluster.

​
The four pipeline gates

A robust delivery pipeline enforces four gates. Each gate addresses distinct threat classes and, together, they greatly reduce supply-chain risk.
A slide titled "The Secure Pipeline: Four Gates" showing four stages—Build, Scan, Sign, and Admit—with brief descriptions of each. Example tools are listed for each stage (e.g., Distroless/Alpine, Trivy/Grype/Snyk, Cosign/Notary, Kyverno/Gatekeeper).
Code should flow through each gate — Build → Scan → Sign → Admit — before it reaches production. Below we step through the scanning, signing, and admission enforcement stages and include practical commands and policy examples you can use in CI and at runtime.

​
Image scanning (CI gate)

Image scanning finds known vulnerabilities in OS packages and application dependencies. Trivy is a common open-source scanner that integrates well into CI pipelines.
  • Goal: Fail the pipeline if unacceptable severities (e.g., CRITICAL, HIGH) are detected.
  • Coverage: OS packages, language dependencies, container images, and IaC misconfigurations (depending on configuration).
Example Trivy usage:
Integrate this command as a pipeline step that blocks promotion/push when the exit code indicates critical issues. You can customize severities or whitelists as your risk policy dictates.

​
Image signing (provenance and integrity)

Signing proves that an image was produced by your pipeline, and that it hasn’t been tampered with since signing. Cosign (part of Sigstore) is a modern, well-supported tool for signing container images. It supports both key-based and keyless (OIDC-based) signing. Typical Cosign flow:
Cosign keyless signing uses your CI provider’s OIDC identity to sign and records the attestation in Sigstore’s transparency log. This simplifies key management and provides public verifiability.
Keyless signing (Sigstore) simplifies key management: your CI workflow uses the OIDC identity to sign and records attestations in a public transparency log. Use key-based signing when you need stricter private-key control.
A secure build-and-release pipeline typically follows this sequence:
  1. Write code and run unit/CI tests.
  2. Build a minimal, reproducible container image (multi-stage, pinned dependencies).
  3. Generate an SBOM for the image (optional but recommended).
  4. Scan the image with Trivy/Grype; fail on policy violations.
  5. If scan passes, sign the image with Cosign.
  6. Push signed image + attestation to the registry.
  7. Cluster admission enforces signature/SBOM/SLSA requirements before allowing runtime Pod creation.
A flowchart titled "Image Signing With Cosign (Complete Pipeline)" showing pipeline steps: Code → Build → Scan (Trivy) → Sign (Cosign) → Push to Registry → Deploy (Admit). Colored circular icons and arrows illustrate the sequence and a loop from scanning back to signing.

​
Admission control (runtime enforcement)

Signing is only effective if the cluster enforces it at admission time. Kyverno or Gatekeeper (OPA) can verify Cosign signatures and attestations when Pods are created. Example Kyverno ClusterPolicy that enforces image signatures from your registry:
When this policy is applied, Pod creation will be rejected if an image from the specified registry is not signed by one of the listed public keys (or the signature is invalid). This closes the loop: CI enforces scanning and signing, and the cluster enforces those guarantees at runtime.

​
SLSA and SBOM (supply-chain standards)

SLSA (Supply-chain Levels for Software Artifacts) and SBOMs (Software Bill of Materials) provide frameworks and artifacts to reason about and audit supply-chain integrity. SLSA levels (high-level): Generate SBOMs during CI so you can quickly answer “Which services are affected?” when a CVE is disclosed. Tools like Syft or Trivy can produce SPDX or CycloneDX outputs that integrate with your vulnerability management workflow.
A two-column infographic titled "SLSA and SBOM: Supply Chain Standards" comparing Supply-Chain Levels for Software Artifacts (SLSA) with Software Bill of Materials (SBOM). The left column lists SLSA levels (Level 1–4) and the right column lists SBOM features like component lists, OS packages/versions, formats (SPDX, CycloneDX), and generation tools.

​
Best practices and recommendations

  • Enforce the scan gate in CI with fail-on-severity flags (e.g., CRITICAL,HIGH).
  • Keep base images and dependencies pinned and minimal.
  • Use multi-stage builds and Distroless or scratch images where possible.
  • Produce and store SBOMs alongside artifacts and scan them for affected services when CVEs appear.
  • Sign images and attestations (key-based or keyless) and enforce verification at admission time.
  • Maintain a small, auditable set of signing identities/keys and rotate them periodically.
  • Automate everything — human gaps enable attackers; CI/CD should be the source of truth.

​
Wrap-up

The secure delivery pipeline enforces the four gates: Build (minimal/pinned images), Scan (Trivy with failing exit codes for policy), Sign (Cosign key-based or keyless), and Admit (Kyverno/Gatekeeper verifying signatures and attestation). Together, these controls materially reduce risk from supply-chain compromises. Quick command reminders:
By embedding these gates into CI/CD and enforcing them at admission time, you harden your delivery pipeline and greatly reduce the blast radius of supply-chain attacks.

Watch Video

Practice Lab