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

Component	Responsibility
developer	Authenticated Developer
source-control	Protected Source Control
dependency-registry	Dependency Registry and Lock
build-platform	Isolated Hosted Build Platform
provenance-signer	Platform Provenance Signer
artifact-registry	Digest-Addressed Artifact Registry
sbom	SBOM Inventory
transparency-log	Transparency and Signing Evidence
policy-verifier	Release Policy Verifier
deployer	Deployment Controller
runtime	Production Runtime
attacker	Compromised Account, Package, or Builder

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.

▶Walkthrough: protected-source-change (not found)

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.

▶Walkthrough: dependency-resolution (not found)

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.

▶Walkthrough: isolated-build (not found)

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.

▶Walkthrough: provenance-production (not found)

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.

▶Walkthrough: sbom-is-inventory (not found)

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.

▶Walkthrough: release-verification (not found)

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.

▶Walkthrough: artifact-substitution (not found)

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.

▶Walkthrough: compromised-builder (not found)

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.

▶Walkthrough: revocation-and-rollback (not found)

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

[CONCEPT]secrets-management [CONCEPT]owasp-top-10 [CONCEPT]threat-modeling-stride [CONCEPT]data-encryption

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