SLSA does not stop source compromise: what the incidents show

At a glance

What this is: This analysis argues that SLSA, trusted publishing, and similar integrity controls solve narrow trust questions, not end-to-end supply chain security.

Why it matters: It matters because IAM, PAM, and NHI practitioners often inherit the same trust-boundary mistake in software pipelines: one authenticated step is not the same as governed lifecycle control across the whole chain.

👉 Read Kusari's analysis of why SLSA and trusted publishing do not stop source compromise

Context

Supply chain integrity controls are often misunderstood as broad security guarantees when they are really point controls at specific stages of software production. A signed build attestation or trusted publishing workflow can confirm what happened in a pipeline, but it cannot prove that the source, maintainer account, or release branch was trustworthy before the pipeline ran. That distinction matters for any programme that depends on governed identities, whether those are human maintainers or non-human identities inside delivery systems.

The article's core claim is that control composition matters more than any single control family. For identity practitioners, that is familiar territory: authentication, authorisation, and lifecycle governance only reduce risk when they are connected across the full path of access, rather than deployed as isolated checks. The same logic applies to software supply chains, where a hardened downstream control can still faithfully attest to a compromised upstream event.

Key questions

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. It can prove that an artifact came from a declared workflow, but it cannot stop compromised source code, maintainer accounts, or release branches from entering that workflow in the first place. The result is a valid signature on a malicious artifact.

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. If branch protection, maintainer approval, or commit signing is weak, downstream signing only preserves the story of compromise more reliably. Upstream trust decisions determine whether the build should happen at all.

Q: What do security teams get wrong about package provenance and trusted publishing?

A: They often assume provenance replaces older authentication paths automatically. It does not. If a legacy token, secret, or key remains valid, the attacker can use that path even when provenance controls exist. The control failure is leaving old and new trust models active at the same time.

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.

Technical breakdown

What SLSA provenance actually proves

SLSA build provenance is a signed record that says an artifact came from a specific builder, source, commit, configuration, and time. It answers a narrow authenticity question about the build event. It does not prove the source code was benign, the maintainer was trustworthy, or the commit should have been built. In practice, provenance can be perfectly valid and still describe a malicious artifact if the compromise happened before the build boundary. That is why provenance is an integrity control, not a full trust model.

Practical implication: Treat provenance as evidence for the build step, not as a substitute for source review, branch protection, or maintainership controls.

Why trusted publishing narrows one attack path

Trusted publishing replaces long-lived registry tokens with short-lived OIDC-bound workflow identities. That removes a common secret-theft path, because there is no persistent registry credential sitting in a repo secret for an attacker to steal and reuse. But it only binds publication to an approved workflow. If the repository or release workflow itself is compromised, the binding still produces a valid publish event for bad code. The control reduces credential exposure, but it does not govern whether the source that entered the workflow deserved to enter it.

Practical implication: Use trusted publishing to remove static registry secrets, then separately harden repository and workflow trust decisions.

How compromise propagates downstream in supply chains

The article's most useful model is the one-way chain from source to build to artifact to publish to consumer. Once an attacker lands upstream, every downstream step can behave exactly as designed while still carrying malicious output. This is why layered controls can appear to fail when they are actually doing only the job they were built to do. The chain of custody matters more than any single checkpoint, and the weakest upstream link often determines the final outcome.

Practical implication: Map every release path end to end so you can identify which control breaks the chain before a compromised step becomes a trusted artifact.

Threat narrative

Attacker objective: The attacker wants malicious code to be published and consumed with the appearance of legitimate provenance.

1. Entry occurs when an attacker compromises source control, maintainer identity, or a release workflow before the build boundary.
2. Escalation occurs when the compromised source or workflow is allowed to trigger a legitimate build and publishing path, producing valid attestations for bad code.
3. Impact occurs when downstream consumers trust the signed artifact and install malicious software that appears to have followed normal release procedures.

NHI Mgmt Group analysis

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.

Source integrity is the more important boundary than many teams admit: a hardened build can faithfully sign malicious source, which means the highest-value controls often sit before the build begins. That is the same governance lesson identity teams see with lifecycle controls, where authentication without ownership, review, and offboarding leaves a trusted system pointed at the wrong actor. The concept to name here is chain-of-custody trust gap: a situation where each checkpoint is valid in isolation but the handoff between them is not governed. Practitioners should design controls around the handoff, not just the checkpoint.

Supply chain security now behaves like identity governance in disguise: the relevant question is not whether a system can prove an event happened, but whether the entity that caused the event should have been able to do so. That is the same logic behind least privilege, approval workflows, and non-human identity lifecycle management. For teams running build systems, registries, and CI/CD platforms, the practitioner conclusion is that identity and trust policy must be enforced across source, build, and publish boundaries together.

Velocity is turning old assumptions into operational debt: more repos, more pipelines, more automated releases, and faster attacks mean manual review is no longer enough to preserve the integrity boundary. If the weakest layer remains source-side hygiene, then investing only in downstream signing creates the illusion of control. Practitioners should re-balance effort toward the earliest point where an attacker can influence the release path.

The market signal is clear: control composition is replacing tool accumulation: incidents now reward teams that connect provenance, branch protection, workflow identity, and release governance into one operating model. The article's strongest contribution is not a new mechanism, but a corrective to a common security assumption that one attestation can stand in for a security programme. Teams should use that correction to rebuild their SDLC governance around linked controls, not isolated products.

What this signals

Software supply chain security is moving toward a governance model that looks increasingly like identity lifecycle management. The practical shift is from proving that an event occurred to proving that the right entity was allowed to cause it, which aligns closely with the logic behind least privilege, approval, and offboarding in identity programmes.

Chain-of-custody trust gap: teams will increasingly need to model not just whether controls exist, but whether each handoff between source, build, and publish is governed end to end. That thinking pairs naturally with the Ultimate Guide to NHIs , Key Challenges and Risks because trust gaps and identity sprawl fail in similar ways when ownership is unclear.

For practitioners, the next priority is operational composition. Map release identities, workflow identities, and approval boundaries the same way you would map service accounts and privileged accounts, because the attack surface is now defined by trusted handoffs, not just by tooling.

For practitioners

• 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.
• Separate attestation from trust decisions Treat provenance and SBOMs as evidence artifacts, then keep source review, maintainer governance, and release approvals as separate control gates.
• Prioritise the weakest layer first If build provenance is mature but source controls are not, invest in the upstream gap before adding more downstream signing or scanning.

Key takeaways

• SLSA and trusted publishing are narrow integrity controls, not full security programmes, so they must be paired with source-side governance.
• The incidents described in the article succeed because attackers move upstream of the visible check, then let downstream controls faithfully attest to the compromise.
• The most effective response is to govern the entire chain of custody, from maintainer identity to release workflow to artifact consumption.

Key terms

• Build provenance: Build provenance is the evidence chain showing where a software artefact came from, how it was assembled, and which identities and keys were used. It is essential when teams need to prove that an embedded release was produced from trusted source and controlled inputs.
• Trusted Publishing: Trusted publishing is a release method that ties package publication to a verified CI workflow, usually with short-lived identity tokens and provenance evidence. It reduces the value of stolen legacy credentials, but only if older publish paths are fully removed and not left alongside the new flow.
• Chain Of Custody Trust Gap: A chain of custody trust gap is the weakness that appears when each control is valid on its own, but the handoff between controls is not governed. In supply chain security, that gap lets compromise move from source to build to publish while every attestation remains technically true.
• Source Integrity: Source integrity is the assurance that the evidence feeding an identity decision has not been manipulated in transit, at capture, or before policy evaluation. For modern identity programmes, it is a prerequisite for trusting verification signals, especially where generative AI can fabricate convincing inputs.

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

👉 Kusari's full article walks through the attack chain, the missing source-side controls, and the layered response model.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners build the lifecycle and access-control skills needed to govern trusted identities across complex programmes.