Supply Chain Basics: Pinning, Verification, and SBOMs

In one line

Every action, base image, and dependency your pipeline pulls in is code you didn't write, running with real access — pinning versions and verifying what you trust is the pipeline-level extension of the exact risk Git's own course covered for secrets.

0/4 · 0%

Key ideas

01
A SUPPLY CHAIN ATTACK targets not your own code directly, but something your pipeline TRUSTS and pulls in automatically — a compromised third-party GitHub Action, a compromised base Docker image, or a compromised open-source dependency, each capable of running WITH your pipeline's own real access (Topic 7.2's credentials, Phase 2.2's secrets) the moment it's pulled in and executed.
02
VERSION PINNING (Phase 2.1's action pinning, revisited here as a genuinely broader principle) applies to EVERYTHING a pipeline depends on — a third-party action pinned to a specific commit SHA rather than a moveable tag, a Docker base image pinned to a specific, immutable digest rather than a floating tag like latest, and application dependencies pinned to exact versions (Git's own course, Phase 1.4's .gitignore topic touched on lock files; this is the security angle on the same underlying mechanism).
03
DEPENDENCY SCANNING tools (Snyk, Dependabot, and others named directly in the original DevOps roadmap's DevSecOps section) automatically check your project's actual dependencies against known-vulnerability databases, flagging (or, with auto-merge configured, automatically opening a pull request to fix) a dependency with a publicly disclosed security issue — genuinely useful as an ongoing, automated check that no human would realistically keep up with manually across a large dependency tree.
04
An SBOM (Software Bill of Materials) is a genuinely complete, structured inventory of every single component — direct AND transitive dependencies, down to exact versions — that makes up a specific built artifact. Generating one as part of a pipeline (a genuinely common, growing real requirement, especially in regulated industries) means that if a vulnerability is later disclosed in some deeply nested dependency, you can immediately and precisely answer 'which of our actual deployed artifacts contain this' rather than needing to investigate from scratch.
05
IMAGE/ARTIFACT SIGNING (Cosign and Sigstore are genuinely common real tools, both named directly in the original DevOps roadmap) lets you cryptographically sign a built artifact, and lets anything consuming it later VERIFY that signature — directly the same principle as Git's own commit signing (that course's Phase 3.4), just applied to a built container image or artifact instead of a commit, providing genuine proof that a specific artifact actually came from your own trusted pipeline and hasn't been tampered with since.
06
The genuinely important mindset this topic teaches, tying every piece together: your pipeline's actual TRUST BOUNDARY extends to every action, base image, and dependency it pulls in automatically — treating all of these with the same 'verify, pin, and scan' discipline as your own first-party code is what genuine supply-chain security actually means in practice, not a separate, optional add-on.

Code & diagrams

SupplyChainTrustBoundarydiagram

Everything a pipeline pulls in automatically is inside its real trust boundary, whether or not a team thinks of it that way.

Rendering diagram…

supply-chain-pipeline.ymlmarkdown

Pinned actions and images, dependency scanning, an SBOM, and a signed artifact — one realistic, hardened pipeline.

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # Pinned to a specific commit SHA, not a moveable tag (Phase 2.1)
      - uses: actions/checkout@8f4b7f84864484a7bde6946f5a76f7f6b1f5c17e

      - name: Dependency vulnerability scan
        uses: snyk/actions/maven@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

      - name: Build using a digest-pinned base image
        run: |
          docker build -t myapp:${{ github.sha }} \
            --build-arg BASE=eclipse-temurin@sha256:abc123... .

      - name: Generate a Software Bill of Materials
        run: syft myapp:${{ github.sha }} -o spdx-json > sbom.json

      - name: Sign the built image
        run: cosign sign --key cosign.key myapp:${{ github.sha }}

      - uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.json

Explain it without notes

Why does pinning a Docker base image to a specific digest, rather than a tag like latest, matter for supply-chain security specifically?

What genuine, practical question does having an SBOM let a team answer quickly, that they otherwise couldn't answer at all without real investigation?

Practice

Check a real pipeline you use (or this topic's own example) for any action, base image, or dependency that's currently referenced by a moveable tag rather than a pinned, immutable identifier, and identify what pinning it would actually require changing.

If you have access to a tool like Syft or a similar SBOM generator, generate an SBOM for a real project and look through it to see exactly how deep the transitive dependency tree genuinely goes.

Trade-offs

↔
Pinning everything to exact, immutable versions genuinely improves security and reproducibility, but it also means you stop receiving automatic updates (including legitimate security patches) until you deliberately, manually bump each pin — this is exactly why dependency-scanning tools (Dependabot and similar) that automatically PROPOSE pin updates via pull requests exist: keeping the safety of deliberate, reviewed pinning while still getting a fast, low-effort path to actually applying genuine security updates promptly.

Done when you can

I understand what a supply-chain attack targets and why a pipeline's trust boundary extends to everything it pulls in automatically.
I can explain why pinning to an immutable identifier (a commit SHA, an image digest) matters more than a moveable tag for security.
I understand what an SBOM is and what practical question it lets a team answer quickly.