For two decades the threat model was what the application did wrong at runtime. Application security (OWASP) covers that. The supply chain — what was shipped into the application before the user ever ran it — was assumed out of scope because it was somebody else’s job. SolarWinds (2020), Log4Shell (2021), and the npm event-stream incident (2018) ended that assumption: attackers who cannot crack the application crack the build pipeline instead, because the build pipeline is trusted, and trusted code is undefended code.

This topic is the defence of the supply chain: the artefact manifests, the signing mechanisms, the maturity ladder, and the dependency hygiene that makes any of it hold.

The Supply Chain as an Attack Surface

The chain has many links; any one is a viable entry point:

Each link is a place the artefact could be modified between what the developer shipped and what the operator ran. The whole defensive program of supply chain security is collapsing that gap to zero.

SBOMs (Software Bills of Materials)

An SBOM is a machine-readable manifest of every component that went into an artefact: direct and transitive dependencies, their versions, their licences, their hashes. Two formats dominate: SPDX and CycloneDX.

What an SBOM enables:

• Vulnerability matching: when a CVE drops, you grep your SBOMs and learn “where is this vulnerable library deployed, in which artefacts, in which environments”.
• Licence compliance: machine-checked, not “have we audited this repo yet?”.
• Provenance auditing: an SBOM signed alongside the artefact says “this artefact contains exactly these dependencies, by name and hash”.

An SBOM is necessary, not sufficient. Without a signed attestation that the SBOM corresponds to a real artefact built from a real source, it is just a file someone wrote.

Signed Artefacts: Sigstore and Cosign

Signing an artefact proves who built it and when. The signing key creates a chain: if you trust the key, you trust the artefact.

The breakthrough of Sigstore is keyless signing: instead of a permanent private key, the build pipeline proves its identity via OIDC (GitHub Actions token, GitLab CI, …) and Fulcio issues a short-lived certificate valid only for this artefact. The certificate is recorded in the Rekor transparency log, which is append-only and publicly auditable.

The property bought: anyone can verify who built an artefact, when, against what source commit — without trusting a key the maintainer has to keep in a vault.

SLSA: The Maturity Ladder

SLSA (slsa.dev, “slopsa”) is the framework the industry uses to measure supply chain integrity, in four levels:

Reaching SLSA L3 buys you the property that SolarWinds-style attacks fail. It is increasingly a procurement requirement (US executive order 14028 mandates SBOMs for software sold to the federal government; SLSA L2/L3 is the natural match).

Dependency Hygiene

Signing and attestations tell you your build is what it claims to be. They do not protect you from a malicious dependency you knowingly depended on. Three practices compound:

• Pin direct deps to a hash — lodash@4.17.21 is mutable; lodash@npm:4.17.21 resolved to a specific sha512 is immutable. Pin to the hash, the SHA, the digest — never the tag.
• Lock transitive deps too — package-lock.json / yarn.lock / Cargo.lock / go.sum record the resolved tree. Commit the lockfile. Verify reproducible installs.
• Vet, don’t just install — there are ~3,000 new npm packages per day, many typosquatted. Vetting the reputation of a dependency (download counts, maintainer history, GitHub stars activity) before adoption is no longer optional.

Two complementary tools close the loop:

• Dependabot / Renovate pulls newer versions when patched; the merge is human-reviewed.
• OSV-Scanner / Trivy / Grype cross-references your SBOM against known vulnerability databases on every commit and every artefact build.

The full pattern: pin → lock → scan → update through review.

Trust Policies in CI

The deploy pipeline is the last gate before production. Three policies harden it against supply-chain compromise:

1. if: from_hash(artefact) AND provenance == signed_by_known_identity — do not deploy anything whose attestation fails. This is the runtime enforcement of SLSA L3.
2. Dependency pinning at the runner image itself — building on ubuntu:latest means someone else chose your build environment; building on ubuntu:22.04@sha256:... means your build is reproducible.
3. OIDC trust, no long-lived cloud credentials in CI — the runner proves its identity to the cloud and receives short-lived role assumption; a compromised runner cannot exfiltrate a deploy key.

Practice Trajectory

1. Generate an SBOM (CycloneDX or SPDX) for a small application. Resolve one CVE listed against it by upgrading the offending dependency; re-generate; confirm the CVE is gone.
2. Set up Cosign keyless signing in a GitHub Actions pipeline. Push an image, sign it, verify the signature against the Rekor transparency log. Note what proves what.
3. Audit your own dependency file. Find one transitive dependency you cannot explain (why is underscore in my lockfile?). Trace its introducer.
4. Score a project at SLSA. Where is it L1, where is it L2, what would L3 take? Write the gap.
5. Sketch the runbook for “a CVE just dropped in a library you use in production.” Which tool surfaces the affected artefacts; what branches the patch; what gates the deploy?

When It’s the Right Tool