Your CI pipeline builds an image. Someone modifies it after build. Or injects a different image entirely. Supply chain security ensures the image running in production is exactly what your pipeline built — nothing added, nothing changed.
Supply Chain Threats
1. Compromised dependency → Malicious package in node_modules
2. Tampered build artifact → Image modified after CI build
3. Registry substitution → Different image pushed with same tag
4. Compromised base image → Vulnerability in upstream image
5. Missing provenance → No proof of how the image was builtSLSA Framework
Supply-chain Levels for Software Artifacts (SLSA) defines four levels:
| Level | Requirements |
|---|---|
| SLSA 1 | Build process exists and produces provenance |
| SLSA 2 | Hosted build service, authenticated provenance |
| SLSA 3 | Hardened build platform, unforgeable provenance |
| SLSA 4 | Two-party review, hermetic builds |
Most organizations start at SLSA 2 and progress to SLSA 3.
Master this topic with hands-on labs
Go beyond reading — build real projects in sandboxed environments with expert video guidance.
Browse Courses →Build Provenance with SLSA
# GitHub Actions with SLSA provenance
jobs:
build:
runs-on: ubuntu-latest
permissions:
contents: read
id-token: write
packages: write
steps:
- uses: actions/checkout@v4
- name: Build and push
id: build
uses: docker/build-push-action@v5
with:
push: true
tags: ghcr.io/myorg/order-api:${{ github.sha }}
- name: Generate SLSA provenance
uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v1.9
with:
image: ghcr.io/myorg/order-api
digest: ${{ steps.build.outputs.digest }}The provenance attestation proves: - Who triggered the build (git push by alice) - What was built (commit abc123 on branch main) - Where it was built (GitHub Actions runner) - How it was built (Dockerfile, build args)
Verify Provenance
# Verify SLSA provenance
cosign verify-attestation \
--type slsaprovenance \
--certificate-identity-regexp="https://github.com/myorg/.*" \
--certificate-oidc-issuer=https://token.actions.githubusercontent.com \
ghcr.io/myorg/order-api:v1.0SBOM Generation and Attestation
# Generate SBOM
syft ghcr.io/myorg/order-api:v1.0 -o spdx-json > sbom.json
# Attest SBOM
cosign attest --predicate sbom.json \
--type spdxjson \
ghcr.io/myorg/order-api:v1.0
# Verify SBOM attestation
cosign verify-attestation \
--type spdxjson \
ghcr.io/myorg/order-api:v1.0The SBOM lists every package and library in the image. If a new CVE is discovered, you can check which images are affected without scanning them again.
Get weekly IT automation tips
Docker, Ansible, Terraform, MLOps — curated insights delivered to your inbox. No spam.
Subscribe Free →Enforce Policies in Kubernetes
# Sigstore Policy Controller
apiVersion: policy.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
name: require-slsa-provenance
spec:
images:
- glob: "ghcr.io/myorg/**"
authorities:
- keyless:
identities:
- issuer: https://token.actions.githubusercontent.com
subjectRegExp: "https://github.com/myorg/.*"
ctlog:
url: https://rekor.sigstore.dev
attestations:
- name: must-have-slsa
predicateType: https://slsa.dev/provenance/v0.2
policy:
type: cue
data: |
predicateType: "https://slsa.dev/provenance/v0.2"Images without valid SLSA provenance cannot be deployed.
VEX (Vulnerability Exploitability)
Not every CVE is exploitable in your context:
{
"@context": "https://openvex.dev/ns/v0.2.0",
"statements": [
{
"vulnerability": { "name": "CVE-2024-1234" },
"products": [{ "@id": "ghcr.io/myorg/order-api" }],
"status": "not_affected",
"justification": "vulnerable_code_not_in_execute_path"
}
]
}VEX statements document that a CVE exists in the image but is not exploitable. This reduces false-positive noise in vulnerability reports.
Implementation Roadmap
- Week 1: Sign all images with Cosign in CI
- Week 2: Generate SBOMs for all images
- Week 3: Add SLSA provenance to build pipelines
- Week 4: Deploy policy controller in audit mode
- Week 5: Switch to enforce mode for staging
- Week 6: Enforce in production
Start with signing. It is the foundation for everything else.
---
Ready to go deeper? Master container security with hands-on courses at CopyPasteLearn.
Ready to learn by doing?
Stop reading tutorials — start building. Expert video courses with hands-on labs in real sandboxed environments.
Related Articles
Falco Runtime Security Kubernetes
Falco detects runtime threats in Kubernetes using eBPF. Learn how to set up Falco for container security monitoring, write custom rules, and integrate.
Sigstore Container Image Signing
Sigstore provides keyless signing for container images and software artifacts. Learn how to sign images with Cosign, verify signatures in Kubernetes.
Trivy Container Vulnerability Scanner
Trivy scans container images, filesystems, and IaC for vulnerabilities and misconfigurations. Learn how to integrate Trivy into your CI/CD pipeline.
Checkov Infrastructure as Code Scan
Checkov scans Terraform, CloudFormation, Kubernetes, and Dockerfile for security misconfigurations with 1000+ built-in policies. Learn how to integrate.
CI/CD for ML on Kubernetes
Build a CI/CD pipeline for ML models using GitHub Actions, MLflow, Docker, and Kubernetes. Automate the path from training to production.
CI/CD Pipeline Tutorial from Scratch
Build a complete CI/CD pipeline from scratch with GitHub Actions. Lint, test, build, and deploy your application — fully automated on every push to your.
Explore topics
Browse more articles on the topics covered here.