Notifications
Clear all
Topic starter
14/09/2026 10:09 am
TL;DR: SLSA provenance and trusted publishing can prove that a package came from an approved workflow, but they do not stop compromised source repositories, maintainer accounts, or release paths from producing valid attestations for malicious code, according to Kusari. The practical lesson is that supply chain security fails when teams treat one control as the whole program instead of layering source, build, and publish protections.
NHIMG editorial — based on content published by Kusari: why SLSA didn't stop the last attack and what that means for layered supply chain security
Questions worth separating out
Q: What breaks when build provenance is treated as the main security control?
A: Build provenance breaks as a security strategy when teams confuse attestation with trust.
Q: When should teams prioritise source-side controls over downstream signing?
A: Teams should prioritise source-side controls when malicious code can enter the release path before the build boundary.
Q: What do security teams get wrong about package provenance and trusted publishing?
A: They often assume provenance replaces older authentication paths automatically.
Practitioner guidance
- Harden source-side trust before build-side trust Require signed commits, protected branches, and review enforcement on every release-adjacent path so a compromised build can never be fed from an ungoverned source.
- Bind workflow identities to release authority Replace long-lived publishing secrets with short-lived OIDC-based workflow identities, then restrict who can approve the workflows that mint them.
- Map upstream-to-downstream release chains Document the full path from repository to build to package registry to consumer so you can identify which control actually breaks the attack chain.
What's in the full article
Kusari's full article covers the operational detail this post intentionally leaves for the source:
- A stage-by-stage breakdown of source, build, publish, and consumer trust boundaries in real supply chain incidents
- Specific control examples for signed commits, protected branches, and maintainer approval enforcement
- A deeper comparison of build provenance, trusted publishing, and source-side protections in live attack paths
- Audience-specific guidance for producers, distributors, and consumers of software
👉 Read Kusari's analysis of why SLSA and trusted publishing do not stop source compromise →
SLSA and supply chain controls: where the trust boundary breaks?
Explore further
14/09/2026 10:10 am
Single-control thinking is the real failure mode here: supply chain incidents keep exposing the gap between a control that attests to an event and a programme that governs the full trust chain. Build provenance and trusted publishing are useful, but only inside a layered model that also controls source integrity, maintainership, and release authority. The practitioner takeaway is to stop asking whether one control "should have stopped" an incident and start asking which upstream trust decision it never covered.
A question worth separating out:
Q: How should practitioners govern software release trust chains?
A: Practitioners should govern the release chain as one linked system, not as separate tools. Source control, build integrity, publish identity, and consumer trust each need explicit ownership and policy. If any upstream stage can be influenced without review, the downstream attestation may be accurate and still unsafe.
👉 Read our full editorial: SLSA does not stop source compromise: what the incidents show
