luvv to help

Menu

Topic 4 of 8

Supply Chain Security Basics

Learn Supply Chain Security Basics for free with explanations, exercises, and a quick test (for Platform Engineer).

Published: January 23, 2026 | Updated: January 23, 2026

Table of Contents

Who this is for

Platform Engineers and security-minded developers who build or operate CI/CD pipelines, container images, or deployment platforms and want a practical foundation in supply chain security.

Prerequisites

  • Basic Git usage and code review practices
  • Familiarity with a CI system (any vendor)
  • Container basics (build, tag, push, deploy)

Why this matters

Modern attacks target your software factory: dependencies, build systems, and deployment pipelines. As a Platform Engineer, you will:

  • Design CI pipelines that prevent tampering and secret leakage
  • Choose base images, generate SBOMs, and enforce dependency pinning
  • Sign artifacts and verify them at deploy time
  • Respond quickly to new CVEs by tracing impacts via SBOM
  • Gate releases with policy checks to reduce production risk

Concept explained simply

Supply chain security protects how software is made, not just the running app. Think of it as securing every handoff: code → dependencies → build → artifact → deploy.

Mental model

  • Trust comes from proof: signatures, attestations, and reproducible steps
  • Reduce unknowns: pin versions, avoid latest tags, verify checksums
  • Limit blast radius: minimal permissions, isolated builds, ephemeral runners
  • Prove provenance: record who built what, when, and with which inputs
Jargon to human-speak
  • SBOM: A bill of materials for software (what’s inside your app)
  • Attestation/Provenance: Evidence about how an artifact was built
  • Artifact signing: Cryptographically proving an image/binary came from you
  • Hermetic build: Build that doesn’t reach out to the internet
  • Pinning: Locking exact versions (and sometimes checksums) of dependencies

Core components and practices

  1. Source integrity: Enforce branch protection, code reviews, mandatory status checks, and require commit signing where feasible.
  2. Dependencies: Use lockfiles; pin versions and verify checksums; scan for vulnerabilities and licenses; prefer well-maintained sources.
  3. Build hardening: Use ephemeral, isolated runners; least-privilege tokens; avoid curl|bash; prefer hermetic builds; separate build and deploy jobs.
  4. Artifacts: Produce immutable tags (e.g., git SHA); generate SBOM; sign artifacts; store attestations alongside artifacts.
  5. Deploy gates: Verify signature and provenance; enforce policy (approved base images, vulnerability thresholds, registry allowlists).
  6. Monitor and respond: Track CVEs; rebuild with patched bases; roll forward quickly; prove coverage using SBOM.

Worked examples

Example 1: Pin and verify dependencies

Scenario: A Node or Python service builds on CI and occasionally breaks due to transitive updates.

  • Action: Use a lockfile (package-lock.json/poetry.lock). Pin critical tooling versions in CI.
  • Verification: Add checksum verification for critical downloads (e.g., installer archives).
  • Outcome: Reproducible builds; quick diff of dependency changes in PRs.

Example 2: Sign and verify container images

Scenario: You build a container image for each commit.

  • Action: Tag images with the git SHA; sign the image and generate provenance and SBOM in the build job.
  • Deploy gate: The deploy job verifies the signature and checks the SBOM has no critical vulns.
  • Outcome: Only verified, policy-compliant images reach the cluster.

Example 3: Lock down CI runners and caches

Scenario: Builds run on shared runners with broad permissions.

  • Action: Use ephemeral runners; set least-privilege token permissions; restrict network egress in build steps; avoid reusing untrusted caches.
  • Outcome: Compromise of one job cannot pivot to secrets or other builds.

Example 4: Rapid response to a base image CVE

Scenario: A new critical CVE hits your base image.

  • Action: Update the base image to a patched version; rebuild all affected services by tracing via SBOM; redeploy after tests pass.
  • Outcome: Measurable, fast remediation across the fleet.

Exercises

Try these before revealing solutions. They mirror the Exercises section below.

Exercise 1 (harden a CI job)

Identify risks and rewrite a safer CI snippet: pin actions, avoid curl|bash, least privilege, immutable tags, add signing, provenance, and SBOM, and verify at deploy.

Exercise 2 (deploy gate policy)

Draft 5–7 boolean checks your CD must pass before releasing a containerized service.

Checklist: Minimum viable guardrails

  • Lockfiles in all buildable repos
  • No latest tags in base images or dependencies
  • CI actions and tools pinned (version or commit SHA)
  • Build job creates SBOM and signs artifacts
  • Deploy job verifies signature and enforces policy
  • Ephemeral runners and least-privilege tokens

Common mistakes and self-check

  • Mistake: Using latest tags everywhere. Self-check: Can you reproduce last month’s build byte-for-byte?
  • Mistake: Trusting third-party CI actions by name only. Self-check: Are actions pinned by commit SHA?
  • Mistake: Pushing unsigned images. Self-check: Can your deploy job fail a tampered image?
  • Mistake: Mixing build and deploy responsibilities in one job. Self-check: Is deploy gated by independent verification?
  • Mistake: Keeping broad, long-lived tokens. Self-check: Are permissions minimal and tokens short-lived?

Practical projects

  • Retrofit a service pipeline: add SBOM, signing, and a deploy verification job.
  • Create a base-image allowlist with owners and update cadence, then enforce via policy.
  • Build a small dashboard that shows each service’s last signed build, SBOM timestamp, and vulnerability status.

Learning path

  • Before: Source control hardening and secrets management basics
  • Now: Supply Chain Security Basics (this page)
  • Next: Policy-as-code for deploy gates, advanced provenance, and reproducible builds

Mini challenge

Take one existing service and make its next deployment reject unsigned images. Measure time-to-fix from failed gate to successful, verified deploy.

Quick Test

Everyone can take the quick test. If you log in, your progress will be saved automatically.

Next steps

  • Document your organization’s minimum supply chain bar as a one-page checklist
  • Automate the checks; treat manual approvals as exceptions, not the norm
  • Review and improve quarterly as threats and tooling evolve

Practice Exercises

2 exercises to complete

Instructions

Rewrite the following risky CI workflow into a safer version. Identify at least 7 issues and fix them. Focus on: pinning, least privilege, immutable tags, SBOM/signing, and deploy verification.

name: build
on: push
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install deps
        run: |
          curl -s https://get.example.dev/install.sh | bash
      - name: Build
        run: docker build -t myapp:latest .
      - name: Push
        run: docker push myapp:latest
      - name: Deploy
        run: kubectl apply -f k8s/deploy.yaml
      - uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKER_USER }}
          password: ${{ secrets.DOCKER_PASS }}
Expected Output
A CI config with pinned actions by commit SHA, no curl|bash, least-privilege permissions, immutable image tags (git SHA), SBOM and signature generation, separate deploy job that verifies signature and policy, and sanitized secret handling.

Supply Chain Security Basics — Quick Test

Test your knowledge with 10 questions. Pass with 70% or higher.

10 questions70% to pass
Network Segmentation And Zero Trust BasicsImage Scanning And SBOM Basics

Have questions about Supply Chain Security Basics?

AI Assistant

Ask questions about this tool