Supply-chain Compromise

1. Matching the expected package name does not prove release lineage

Imagine a local release bundle with a source revision, lockfile, build attestation, and artifact digest, but one lineage edge no longer satisfies policy. A package name, version, or single digest is only a local observation. A release decision needs evidence for the source revision, dependency selection, builder identity, provenance subject, and the stored artifact. This lesson finds the first broken trust link instead of constructing a confident story from one symptom.

2. Source track and Build track are separate evidence problems

SLSA v1.2 is an approved specification and models Source and Build as distinct tracks. The Source track concerns evidence about how a source revision was created and retained; the Build track concerns provenance and how an artifact was produced from inputs by a builder. [SLSA-12] A trustworthy source history therefore does not, by itself, prove the build, and build provenance does not prove the intent or functional correctness of the code.

3. Provenance is lineage evidence, not a guarantee that software is flawless

SLSA provenance is verifiable information about where, when, and how an artifact was produced. [SLSA-12] A provenance subject mismatch prevents the expected lineage from closing for that release. Correct provenance still does not establish that the software is bug-free or free of malicious logic; this lesson makes no such claim.

4. A lockfile is one link, not the whole chain

A lockfile can make dependency resolution more reproducible and auditable, but it does not cover the build environment, source control, artifact repository, signing infrastructure, or provenance. OWASP likewise treats software supply-chain security across source, dependencies, build tooling, artifact repositories, signing, and provenance. [OWASP-SUPPLY] Therefore, a valid lockfile is not proof that the entire supply chain is uncompromised.

5. A signature must be interpreted within its claim boundary

A valid signature means verification succeeded for the configured identity/key and policy. It does not by itself establish source correctness, builder trust, or absence of malicious behavior. OWASP discusses code signing together with hardening signing and build infrastructure. [OWASP-SUPPLY] Signature evidence is therefore one trust link, not a verdict on the full chain.

6. Build a trust-link map

For this lesson, inspect source revision → dependency evidence → builder identity → provenance subject → artifact/repository digest → release policy in that order. The first point where evidence fails the declared policy is the candidate broken trust link. If evidence for a link is missing, preserve UNKNOWN; do not infer an upstream cause from a downstream result.

7. Supply-Chain Compromise Trace & Quarantine Record v1

The owned artifact records Source Revision, Dependency Evidence, Builder Identity, Provenance Subject, Artifact Digest, Repository Digest, Signature/Policy Check, Broken Trust Link, Quarantine Scope, Trusted Rebuild Evidence, Verification Result, and Residual Trust Gap. Every decisive entry must be traceable to observation, authority-backed policy, explicit inference, or UNKNOWN.

8. Separate the first broken link from the downstream symptom

A repository digest mismatch may indicate storage tampering, but if provenance already points at the wrong subject, the trust chain broke earlier. Read the chain from upstream to downstream. Quarantine should cover downstream outputs derived from the first unsupported link rather than only the final symptom.

9. Use negative evidence to reject alternatives

If the builder is suspected, verify whether the source revision and dependency evidence still satisfy policy. If they do and the builder identity is outside the approved set, the alternative that dependency selection was the first failure becomes weaker. If dependency evidence is incomplete, do not claim the builder is definitively the first failed link.

10. Do not absorb an adjacent failure family

A signer-credential alert may matter, but if the supply-chain evidence in this lesson still matches, the alert alone does not establish Supply-chain Compromise. Credential compromise is owned by FLR-008. This lesson may hold release and route review, but it does not diagnose the credential cause without its own evidence.

11. Containment limits blast radius

Containment may quarantine an artifact and downstream releases, stop promotion, freeze a repository path, or require rebuilding with an approved dependency set and builder. These actions limit propagation of uncertain output. They do not prove the cause and are not closure by themselves.

12. Recovery needs a new trusted lineage and an independent oracle

Do not simply repeat the same build and treat a green rerun as proof. A defensible trusted rebuild path has the expected source revision, valid dependency evidence, an approved builder identity, the correct provenance subject, consistent digests, and a passing verification policy. Closure applies only to the bounded fixture and declared policy, not to every real-world supply-chain risk.

13. Missing evidence must remain open

Consider a signed artifact whose digest matches while source-policy evidence for the revision is unavailable. The signature and digest do not fill that missing link. The classification must remain OPEN_TRUST_LINK_UNRESOLVED, affected outputs should be quarantined, and a human-review or evidence-retrieval trigger must be explicit.

14. Lab: eight fixtures and 64 assertions

The lab is entirely local and inert. Eight cases cover a safe baseline, dependency mismatch, unapproved builder, provenance-subject mismatch, repository digest mismatch, an adjacent credential signal, incomplete source-policy evidence, and a transfer mutation. The administrative evaluator checks eight outputs per case for 64 assertions. No malicious package is created or published, and no external registry or target is used.

15. Exit checklist and claim boundary

Before exit, you must be able to trace the chain from source to release; identify the first broken trust link from evidence only; reject at least one alternative; preserve UNKNOWN; separate containment from recovery; verify a trusted rebuild with an independent oracle; and explain why a lockfile, signature, provenance record, or one successful rerun cannot independently prove complete supply-chain security.