Software Supply Chain Security, Provenance, and Attestation
Passing tests does not establish what was built, from which source, by which identity, with which dependencies, or whether the artifact later changed. An autonomous factory expands the supply chain: models, prompts, tools, MCP servers, runn
A rapid review of the chapter’s existing Quick Read, principles, definitions, lessons, and review material.
Reconstruct and defend this chapter’s architecture.
Reconstruct the architecture, name each boundary, and defend the tradeoffs.
Open the source exercise
Draw the chain from approved Plan to deployed digest. Mark every identity, trust boundary, signing event, verification event, mutable reference, and revocation check. Then show how a compromised dependency registry and a compromised CI worker are detected by different controls.
3. Enduring Principle
Bind every claim to immutable subjects
Evidence should identify source and artifacts by cryptographic digest. The minimum lineage is:
approved Plan digest -> WorkOrder revision -> execution manifest digest -> source/base SHA -> Attempt -> commit SHA -> build artifact digest -> deployment digest
Artifact identity must survive copying and renaming. Human-friendly names may locate an object; digests establish which bytes a claim concerns.
Distinguish provenance, attestation, signature, and transparency
- Provenance describes how an artifact was produced: builder, inputs, invocation, environment, and outputs.
- Attestation is a typed claim by an identified producer about one or more digest-bound subjects.
- Signature provides integrity and signer authentication for the attestation envelope.
- Transparency makes equivocation or deletion more detectable by recording verifiable entries.
None is a quality verdict. A perfectly signed vulnerable build remains vulnerable.
Adopt interoperable envelopes
SLSA 1.2 defines build provenance and graduated build/source assurance. Its build track progresses from available provenance to signed hosted builds and hardened, isolated builds. The in-toto Statement v1 supplies a common subject plus predicateType envelope. DSSE safely signs typed payloads without requiring JSON canonicalization.
The factory should store a normalized evidence envelope while preserving the original attestation bytes and media type. This avoids coupling policy to one vendor or future schema version.
evidence_envelope:
subject:
name: ghcr.io/example/service
digest: {sha256: "..."}
predicate_type: https://slsa.dev/provenance/v1
producer:
identity: github-actions://example/service/.github/workflows/build.yml@refs/heads/main
source_digest: "..."
work_order_revision: WO-42-R2
issued_at: "..."
storage_ref: "..."
verification:
signature_status: VERIFIED
identity_policy: SATISFIED
transparency_status: VERIFIED
Generate and govern SBOMs
Generate an SBOM for each releasable artifact, not once per repository. Include direct and transitive components, versions, package URLs, hashes, dependency relationships, licenses, and creation metadata. SPDX 3.0 and CycloneDX 1.7 are current interoperable choices as of this chapter; select a canonical organizational format but ingest both.
An SBOM becomes operational when policy correlates it with vulnerability intelligence, approved licenses, package-source policy, end-of-life data, and exceptions. A changed dependency graph should affect risk and may invalidate prior security evidence.
Harden the builder and publication boundary
Prefer ephemeral, isolated builders with minimal permissions; pinned actions and dependencies; short-lived workload identities; protected source; hermetic or controlled inputs; secret redaction; and separate build and release authority. Sign by digest, verify before promotion, and record the expected signer identity and workflow—not merely “any valid signature.”
SLSA’s central lesson is that provenance strength depends on the build platform’s resistance to producer-controlled falsification. Asking the same mutable worker to generate and vouch for its own history is weak assurance.
Make verification a policy gate
Before release, verify:
- subject digest equals the candidate artifact;
- attestation and predicate types are allowed and version-supported;
- signature chain, timestamp, and transparency proof are valid;
- signer/workload identity matches policy;
- builder and source repository are authorized;
- source, Plan, WorkOrder, and execution-manifest lineage match;
- required SBOM and scan results concern the same digest; and
- attestations are current, not revoked, and free of conflicting claims.
GitHub correctly warns that artifact attestations establish provenance and integrity, not a guarantee of security. Verification is mandatory at the consumption boundary.
Treat prompts, tools, and models as dependencies
For agent-produced work, provenance should also record the executor configuration, model/provider identifier, tool and MCP server versions, policy bundle, context sources, and prompt/instruction digest where retention policy permits. Do not store secrets or unrestricted prompt content in public attestations. The goal is reproducibility and accountability, not disclosure of sensitive reasoning.
8. Personal notes and lessons learned
- Provenance answers “how did these bytes come to exist?” Quality evidence answers “why are these bytes acceptable?” Both are required.
- A signature without an identity policy is only a cryptographic fact.
- Tags locate; digests identify.
- The factory itself is part of the software supply chain and must be governed accordingly.
9. Interview questions
- What does SLSA provenance prove, and what does it not prove?
- How are SBOM, attestation, signature, and transparency log different?
- Why is builder isolation important when agents generate software?
- How would you revoke trust in an already-issued quality certificate?
- What agent-runtime inputs belong in provenance without exposing secrets?
Review this chapter.
Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.
- Claim
- Boundary
- Failure
- Evidence