Every previous cluster secures something you can point at: a repository, a credential, a file of source code. This one secures a process — and specifically, the gaps between its steps.
The question underneath all ten lessons is the same:
The artifact running in production — what evidence exists that it was built from the source that was reviewed, by the system you believe built it?
For most organisations the honest answer is “the CI job said so”, which is an assertion by the system whose compromise you would most want to detect.
Start with Software Supply Chain Security ExplainedThe chain
Section titled “The chain”A vertical chain: source, dependencies, trusted build, artifact, SBOM, provenance and attestation, signature and verification, release, deployment policy. Each stage both consumes and produces evidence.
Read it as a chain of custody. Each stage receives something, does something to it, and — if the chain is worth anything — records what it did in a form somebody else can check without trusting the recorder.
The last stage is the one that turns all of it from paperwork into a control. Provenance nobody verifies is metadata; provenance a deployment policy rejects deployments over is a security boundary.
Five words that are not synonyms
Section titled “Five words that are not synonyms”More incorrect statements come from confusing these than from any other cause in the pillar.
| Term | What it is | What it does not tell you |
|---|---|---|
| SBOM | An inventory of the components inside an artifact | Whether any of them is safe |
| Provenance | A record of where and how the artifact was built | Whether the build was correct |
| Attestation | A signed claim about an artifact or its build | That the claim is important to you |
| Signature | Cryptographic evidence linking content to a key or identity | That the content is good |
| SLSA | A framework of levels for supply-chain integrity | That a compliant build is vulnerability-free |
Every one of those right-hand cells has been asserted incorrectly in a vendor blog post. Each lesson in this cluster restates its own version of the boundary, because it is the part that gets dropped first.
The most important instance:
An attestation provides verifiable provenance information that can be evaluated against a security policy. It does not make the artifact secure.
An attested container image with eleven critical CVEs is exactly as vulnerable as an unattested one. What you gain is the ability to know which build produced it and to refuse anything else.
The threat model
Section titled “The threat model”Threat. The artifact deployed to production is not what the reviewed source would produce — because a dependency was compromised, the build was tampered with, a credential was stolen, or an artifact was substituted after the build.
Attack surface. Package registries and the resolution process. Third-party actions and build plugins, which execute with the build’s privileges. The build system and its runners. Artifact storage and registries. Release assets and the tags that point at them. Anything mutable between build and deployment.
Impact. The highest in this pillar, because a compromised artifact is distributed by your own trusted channel to everyone who consumes it, and it is the thing nobody reads.
Control. Reduce what the build trusts (pinned dependencies, pinned actions, isolated builds); reduce what the build holds (OIDC instead of stored credentials, minimal permissions); make the output identifiable (digests, not tags); record what happened (provenance, SBOM); make the record checkable (signing, transparency); and refuse anything that fails the check at deployment.
Verification. Take an artifact from your registry and verify its attestation from a machine that was not involved in building it. If you cannot, the chain has a break in it.
Why this is genuinely harder
Section titled “Why this is genuinely harder”It is worth being honest about why supply-chain work stalls, rather than presenting a checklist and implying the rest is willpower.
It spans systems you do not all own. Registries, cloud providers, package ecosystems and deployment platforms each have their own model, and the joins are where evidence gets lost.
Verification has to happen somewhere that can act on failure. Generating attestations is a workflow step. Checking them at deployment means a policy engine in the deployment path, an escalation route for failures, and an answer to “what do we do at 03:00 when verification fails during an incident”.
Rebuilding is not idempotent. Two builds of the same commit usually differ — timestamps, paths, ordering. That undermines “just rebuild it and compare”, which is why provenance exists at all.
Some of it is new. Immutable releases, artifact attestations and the SLSA source track are recent. Availability, behaviour and terminology are moving, so every page in this cluster states what was checked and when.
The lessons
Section titled “The lessons”- Lesson 1: 01. Supply Chain SecurityThe complete chain from developer to runtime — where each stage can be compromised, what dependency confusion and build tampering look like, and which evidence makes each handoff verifiable.
- Lesson 2: 02. SBOMsSoftware bills of materials in practice — what an SBOM records, SPDX versus CycloneDX, generating one from source and from a container, attaching it to a release, and what it cannot tell you.
- Lesson 3: 03. SLSAThe current SLSA specification in practice — the Build and Source tracks, what each level actually requires, how GitHub Actions maps onto them, and what claiming a level does and does not mean.
- Lesson 4: 04. Artifact AttestationsAttestations as supply-chain trust — what the claim contains, how OIDC and Sigstore make it verifiable, generating and verifying binaries and images, SBOM attestations.
- Lesson 5: 05. Build ProvenanceWhat provenance records and why it exists — the fields that matter, provenance versus signatures versus SBOMs, its relationship to reproducible builds.
- Lesson 6: 06. SigstoreSigstore in practice — Fulcio, Rekor, Cosign and Gitsign, how keyless signing with ephemeral keys and OIDC works, what the transparency log adds, and how verification policy is expressed.
- Lesson 7: 07. Signing Container ImagesContainer image integrity end to end — digests versus tags, keyless signing with Cosign, GitHub attestations for images, registry storage.
- Lesson 8: 08. Dependency SecurityThe full dependency risk picture — lock files and integrity hashes, pinning strategy, typosquatting and dependency confusion, malicious packages, private registries.
- Lesson 9: 09. Secure Release PipelinesA release pipeline that produces verifiable artifacts — protected source, trusted build, immutable artifacts, SBOMs, attestations, approvals, immutable references.
- Lesson 10: 10. Immutable GitHub ReleasesWhat immutable releases lock down — tags pinned to commits, assets protected from modification, automatic release attestations, repository resurrection protection.
Lesson 1 is the cornerstone and establishes the vocabulary the rest depend on. Lessons 2 and 3 cover the two artefacts people most often conflate — inventory and framework. Lessons 4 to 6 are the cryptographic core: what GitHub’s attestations claim, what provenance means generally, and how Sigstore makes signing without key management possible. Lesson 7 applies all of it to containers. Lesson 8 is a broad treatment of dependency risk beyond the vulnerability-alert framing of the previous cluster. Lesson 9 assembles everything into a release pipeline, and lesson 10 covers release immutability.
The two directions
Section titled “The two directions”Supply-chain security is usually taught from one side only, which is why teams end up with tooling that produces evidence and no habit of consuming it. Both directions apply to almost every organisation simultaneously.
Downstream — you are a consumer. You install packages, pull base images and run third-party actions. Your controls here are pinning, integrity hashes, dependency review, private registries and verifying what you can before you use it.
Upstream — you are a producer. Something you build is installed by somebody else: another team, a customer, the public. Your controls are the ones that let them verify without trusting you: published provenance, signed artifacts, immutable releases, an SBOM.
The asymmetry worth noticing is that producing evidence is easy and consuming it is a habit. Adding an attestation step to a build takes an afternoon. Making every deployment refuse artifacts that fail verification means changing a process people rely on under pressure — and that is the half that delivers the security benefit.
If you only ever do one direction, do the consumer side first. Pinned dependencies and verified inputs protect you today. Published attestations protect somebody else, later, if they bother to check.
Prerequisites
Section titled “Prerequisites”This is the most demanding cluster on the site. It assumes you can read a workflow file, understand what a job’s credentials are, and reason about the difference between a tag and a digest.
Common mistakes
Section titled “Common mistakes”Believing an attested artifact is safe. It is an artifact whose origin you can check. Vulnerability scanning is a separate activity with a separate answer.
Using mutable tags for build inputs. A base image referenced as :latest, or an action referenced
by a branch, means your build’s inputs change without any change to your repository. Provenance
faithfully records that you built from something you cannot reproduce.
Rebuilding for production. If staging and production run different binaries, everything you tested applies to a different artifact. Build once; promote by digest.
Generating evidence nobody consumes. SBOMs in a bucket and attestations nobody verifies are cost without control. Decide who checks, where, and what happens on failure — before generating them.
Treating SLSA levels as a score. They describe properties of a build platform and process. Claiming a level you have not met is worse than claiming none, because it invites downstream consumers to skip their own checks.
After this cluster
Section titled “After this cluster”This is the final cluster of Pillar 5, and the end of the current curriculum.
A reader who has worked through all five pillars can reason about Git’s internals, use it deliberately in a team, engineer on GitHub, automate the lifecycle, and secure and verify the whole path from a developer’s keyboard to a running artifact.
Back to the Git Security overview