Stage 4 · Provision
Registries & Security
Supply Chain
Use SBOMs, SLSA provenance, pinned base image digests, dependency updates, and vulnerability gates.
Supply Chain Attacks
Supply chain attacks compromise software by tampering with dependencies, build processes, or base images. In the container ecosystem, this includes malicious base images, compromised package registries, and tampered build pipelines. Securing the supply chain requires verifying every component.
Pinned Base Images
Pinning base images to digests ensures you always pull the exact same image. A tag like nginx:alpine can point to different images on different days. A digest like nginx@sha256:abc123... always resolves to the same image.
# Bad — mutable tag
FROM node:20-alpine
# Better — pinned version
FROM node:20.11-alpine
# Best — pinned digest
FROM node:20.11-alpine@sha256:abc123def456...
# Update digest with tools like:
# - docker pull node:20.11-alpine && docker inspect --format '{{index .RepoDigests 0}}'
# - renovate bot
# - dependabotDigest pinning guarantees reproducibility. Even if the registry is compromised, your image remains unchanged. Use tools like Renovate or Dependabot to automate digest updates.
A digest is a SHA256 hash of the image content. It cannot be faked or modified. If you build from a pinned digest, you get the exact same image every time, regardless of what happens to the tag.
SBOM Usage
# Generate SBOM during build
docker build --sbom=true -t myapp:1.0 .
# Generate SBOM with Trivy
trivy image --format cyclonedx myapp:1.0 > sbom.json
# Scan SBOM for vulnerabilities
trivy sbom sbom.json
# Store SBOM alongside image
cosign attest --predicate sbom.json --type cyclonedx myapp:1.0
# Verify SBOM exists
cosign verify-attestation --type cyclonedx myregistry.com/myapp:1.0SBOMs document every component in your image. Store them with the image, scan them for vulnerabilities, and share them with consumers for compliance.
SLSA Provenance
SLSA (Supply chain Levels for Software Artifacts) is a framework for ensuring software integrity. Provenance attestations record how an image was built: the build system, source repository, build steps, and dependencies. Consumers verify that images were built by trusted infrastructure.
# Generate provenance with BuildKit
docker build --provenance=true -t myapp:1.0 .
# Verify provenance
cosign verify-attestation --type slsaprovenance myapp:1.0
# Check provenance in OCI registry
crane manifest myregistry.com/myapp:1.0Provenance attestations prove that your image was built by your CI system, not by an attacker. SLSA Level 3+ requires build provenance that is signed and logged in a transparency log.
Dependency Management
- Pin all dependencies to specific versions
- Use lock files (package-lock.json, go.sum, poetry.lock)
- Scan dependencies with Trivy or Snyk
- Automate dependency updates with Renovate or Dependabot
- Review dependency changes in pull requests
- Monitor for new vulnerabilities in existing dependencies
# Pin package versions in RUN instructions
RUN apt-get update && \
apt-get install -y --no-install-recommends \
curl=7.88.1-10+deb12u5 \
ca-certificates=20230311 && \
rm -rf /var/lib/apt/lists/*
# Use lock files
COPY package-lock.json ./
RUN npm ci # Uses exact versions from lock file
# Pin builder image versions
FROM node:20.11.1-alpine3.19 AS builderPin every dependency version. Use lock files for language packages. Pin base image versions and digests. This creates a fully reproducible build.
Vulnerability Gates
name: Security Gate
on: [push]
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build
run: docker build -t myapp:scan .
- name: Trivy vulnerability scan
uses: aquasecurity/trivy-action@master
with:
image-ref: myapp:scan
format: sarif
output: trivy-results.sarif
severity: CRITICAL,HIGH
exit-code: 1
- name: Upload scan results
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: trivy-results.sarifThe vulnerability gate fails the build if any CRITICAL or HIGH vulnerabilities are found. The SARIF output integrates with GitHub Security tab for tracking and alerts.
Begin with CRITICAL-only gates to avoid overwhelming your team. Once CRITICAL vulnerabilities are resolved, expand the gate to HIGH. This progressive approach builds security culture without blocking all development.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.