Software supply-chain security: source, dependencies, builds, provenance, and policy

Supply-chain assurance links a delivered artifact digest to reviewed source, resolved dependencies, a controlled build, trustworthy provenance, an inventory, and deployment policy. SBOMs, signatures, and provenance provide different evidence and none alone proves software is safe.

Security invariants

• SC-C1: Source assurance identifies immutable revisions and protects change creation through authenticated source control and continuous policy such as review.
• SC-C2: Dependency resolution combines identity, immutable digest, registry policy, inventory, and update review; a lockfile alone does not establish trust.
• SC-C3: SLSA Build L1 provides provenance, L2 uses authenticated provenance from a hosted platform, and L3 adds hardened isolation and protects signing material from user build steps.
• SC-C4: Provenance and signatures are verified against artifact digest, builder identity, source, inputs, and policy expectations before release.
• SC-C5: An SBOM is component inventory for analysis and response and does not by itself prove integrity, absence of vulnerabilities, or policy approval.
• SC-C6: A compromised trusted builder can sign malicious output, so builder hardening, isolation, expectation checks, revocation, and digest-pinned rollback remain necessary.

Trust-boundary map

Topology edges represent authenticated or otherwise explicit communication paths. Responses reuse those physical paths in reverse; no response-only or bypass edges are added.

Executable scenarios

protected-source-change — Protect source changes and revision identity

Authenticated changes, branch policy, review, and immutable revision identity establish expected source before a build starts.

dependency-resolution — Resolve dependencies by trusted identity and digest

A lockfile records resolution, while registry namespace, checksums, signatures or provenance, allowlists, and update review determine trust.

isolated-build — Use an isolated hardened build

Builds start from declared inputs, cannot influence another run, and user-defined steps cannot access the platform provenance signing secret.

provenance-production — Produce artifact-bound provenance

The build platform generates provenance that identifies the artifact digest, builder, build process, source, and resolved inputs; the platform authenticates that statement.

sbom-is-inventory — SBOM is inventory, not proof of safety

An SBOM describes components and relationships for analysis and response; it does not prove those components are untampered, vulnerability-free, licensed, or approved.

release-verification — Verify evidence against release expectations

Verification checks artifact digest, provenance authenticity, builder identity, source and input expectations, SBOM binding, and policy before deployment.

artifact-substitution — Reject artifact substitution after build

A signature or provenance statement is useful only when its subject digest matches the bytes selected for deployment.

compromised-builder — A signature does not cure a compromised builder

If a trusted builder is compromised, it can produce malicious bytes and matching provenance; isolation, builder hardening, source expectations, reproducibility where suitable, and incident response bound this risk.

revocation-and-rollback — Revoke compromised evidence and roll back by digest

Incident response marks signer, builder, source revision, package, or artifact digest untrusted and deploys a previously verified digest without disabling verification.

Operational and failure rules

• Every rejection path fails closed at the component that owns the decision; infrastructure failure is never converted into authentication, authorization, or integrity success.
• Retries preserve stable transaction identity, replay detection, bounded freshness, and audit context. A retry does not erase a prior success or compromise signal.
• Concurrent validation branches are independent checks. Completion requires every mandatory branch, and no check substitutes for another.
• Logs contain decision metadata and stable identifiers, not credentials, bearer tokens, cryptographic keys, or sensitive payloads.

Related concepts

Authoritative sources

1. SLSA specification version 1.2
2. NIST SP 800-218: Secure Software Development Framework
3. SLSA Build Track Basics version 1.2
4. SLSA Verifying Artifacts version 1.2
5. SPDX Specification 3.0.1
6. Sigstore Cosign signature verification
7. SLSA 1.2 FAQ: provenance and SBOM boundaries