EVIDENCE
A signature proves a claim—not the health of the system making it.
On May 15, 2026, the SLSA community published a technical analysis of a software supply-chain incident in which compromised packages carried cryptographically valid provenance. Its central finding was precise: authenticated provenance remained meaningful, but the build environment lacked the stronger isolation properties required to prevent one workflow from influencing another.
SLSA v1.2 separates these guarantees into layers. Provenance records where and how an artifact was produced. Build isolation, source controls, verification policy, and operational monitoring answer different questions. NIST's SSDF makes the same broader point: secure development practices must be integrated through the lifecycle, not bolted onto its final output.
INFERENCE
Trust failure repeats like copied code.
The dangerous unit is rarely one dependency. It is the same untested assumption repeated across hundreds of dependencies, workflows, teams, and downstream users.
Source
Which exact revision entered the build?A familiar repository name substitutes for verified source identity.
Review
What change-control evidence exists?A protected main branch coexists with an unreviewed automation path.
Isolation
Can one build influence the next?A shared cache becomes invisible memory between trust zones.
Identity
Can build steps reach the signing identity?The receipt is cryptographically valid because the factory itself signed it.
Provenance
Do consumers verify the expected builder and inputs?Teams celebrate that an attestation exists without checking what it proves.
Outcome
Did publishing occur from a successful, expected run?A failed workflow can still leave a successful release behind.
EDITORIAL VIEW
Stop buying seals. Start examining boundaries.
A badge is a snapshot. Security is the relationship between who may change a thing, who may sign it, who checks it, and what happens when those identities overlap.
The mature question is not “Does this package have provenance?” It is “What guarantee does this provenance provide, which guarantees remain outside it, and who owns each remaining boundary?” That shift—from possession of a control to comprehension of its limits—is how a checklist becomes engineering.
DEFENSIVE FIELD CARD
Six questions before trust crosses the boundary.
- 01
Can untrusted contribution workflows access privileged repository context?
- 02
Are caches isolated by trust level and complete build inputs?
- 03
Is the signing identity structurally inaccessible to build steps?
- 04
Do verification policies require the expected source, builder, and parameters?
- 05
Are publish events compared with workflow outcomes and approved release paths?
- 06
Can the team explain what its provenance level does—and does not—guarantee?
These are review prompts, not incident-response instructions or a claim of compliance. Validate controls with the platform owner and your organization's threat model.