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.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Kusari's blog post: SLSA and trusted publishing solve build and publish integrity, but not source compromise, so valid attestations can still accompany malicious code.
Why it matters: It matters because IAM, CI/CD, and software supply chain teams need to govern source trust, maintainer access, and release paths as separate controls, not one security claim.
Context
SLSA build provenance answers a narrow question: whether an artifact was produced by the expected build service from the expected source at a given commit and configuration. That does not protect the source itself, so a malicious commit, compromised maintainer account, or abused release path can still feed bad inputs into a trustworthy build and produce a trustworthy-looking result.
Trusted publishing replaces long-lived registry tokens with short-lived OIDC-bound workflow identities, which closes token theft but not repository compromise. In identity terms, the control narrows one credential path while leaving source authority and release governance as separate risks that must be managed explicitly.
The article frames a recurring supply chain governance problem rather than a single vendor or tool failure. The starting position it describes is common: teams deploy one control and assume it covers the full chain, even though source, build, and publish are different trust boundaries.
Key questions
Q: What breaks when SLSA provenance is treated as the whole supply chain programme?
A: Teams lose sight of the source layer. Provenance can prove where an artifact came from, but it cannot prove that the source was trustworthy when the build ran. The practical failure is false confidence, where a valid attestation is mistaken for a full trust decision instead of one link in the chain.
Q: Why do source repository compromises still defeat trusted publishing?
A: Trusted publishing protects the registry token path, not the source repository itself. If an attacker lands a malicious commit in an approved repository and the legitimate workflow runs, the publisher identity is still valid. The risk is not credential theft at publish time, but abuse of the authority to trigger publication.
Q: What are the signs that a software supply chain control is only proving one layer?
A: Look for controls that answer a narrow question, such as who built the artifact or who published it, while leaving commit authority, branch protection, and maintainer identity weak. If a compromised upstream account can still feed the pipeline, the control is documenting trust rather than enforcing it.
Q: How should teams govern source, build, and publish trust as separate controls?
A: Assign each stage its own policy, identity checks, and review requirements. Source governance should control who can change code, build governance should prove how artifacts were produced, and publish governance should control who can release. When those stages are merged in practice, the weakest one becomes the bypass path.
Technical breakdown
SLSA build provenance only asserts build-side truth
SLSA provenance is a signed statement about how an artifact was built, by which workflow, from which source, and with which inputs. That makes it a build integrity control, not a source integrity control. If the source repository is compromised before the build starts, the build can still produce a perfectly valid attestation for malicious code. The security property is authenticity of the build record, not endorsement of the code’s trustworthiness.
Practical implication: Treat provenance as evidence of build origin, not as proof that the source was safe to build.
Trusted publishing binds publishing to workflow identity, not code quality
Trusted publishing swaps static registry secrets for short-lived OIDC identities tied to a specific repository and workflow. That removes a common credential theft path and reduces the value of leaked tokens. But if an attacker lands a malicious change in the repository that triggers the approved workflow, the system will publish it legitimately. The control is about who may publish, not whether the publish should happen.
Practical implication: Pair workflow-bound publishing with source review and branch controls so publication cannot bypass code trust checks.
Downstream attestations preserve a compromised chain of custody
Software supply chains are directional: source feeds build, build feeds artifact, artifact feeds publish, and publish feeds consumers. Once compromise enters upstream, downstream controls can truthfully describe a bad state without preventing it. That is why attestations can be correct and still unhelpful in an incident. The chain of custody has to be defended at each link, because a strong control on one link cannot repair a broken one earlier in the path.
Practical implication: Map controls to each stage of the chain and verify that no single stage is carrying the whole trust burden.
Threat narrative
Attacker objective: The attacker wants malicious code to reach consumers through a path that still generates trustworthy-looking provenance or publish evidence.
- Entry begins when an attacker compromises the source repository, maintainer account, or release path upstream of the build.
- Credential or workflow abuse then causes the approved build or publishing process to run on malicious inputs while still producing valid provenance or trusted-publishing evidence.
- Impact follows when consumers ingest a signed, attestable package that is malicious despite appearing to come from a legitimate workflow.
Breaches seen in the wild
- Shai-Hulud npm worm first wave 2025: The first Shai-Hulud wave used stolen npm tokens to trojanise 500+ packages, starting with tinycolor, and leaked developer and CI secrets on GitHub.
- axios npm compromise 2026: North Korea-linked UNC1069 hijacked an axios maintainer's npm account to ship a backdoor that bots pulled into public repos within minutes.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Source integrity, build integrity, and publish integrity are separate governance problems. The article’s core correction is that SLSA answers one of those problems, not all three. That distinction matters because teams regularly over-rotate on build provenance and then discover that repository compromise still feeds a trustworthy pipeline. Practitioners should stop asking whether one control works and start asking which trust boundary it actually protects.
Trusted publishing reduces token theft but leaves repository authority intact. Replacing long-lived registry secrets with workflow-bound OIDC identities is useful, but it does not stop a compromised maintainer path from authorising bad code. In IAM terms, the control narrows one credential class while leaving approval authority and branch governance untouched. Practitioners should treat publish identity as necessary but insufficient.
Chain-of-custody failures are the real supply chain risk, not attestation failure. The valid attestation is often the evidence that the control worked as designed while the wrong thing was still shipped. That is why the named concept here is downstream trust leakage: a later control inherits the legitimacy of earlier compromised inputs. Practitioners should design for upstream prevention, not only downstream proof.
The right program design is layered, not additive in name only. Defense in depth only works when the gaps do not align. Source review, maintainer identity hardening, branch protection, build provenance, and publish binding need to compose into one chain of trust. Practitioners should evaluate whether each layer independently blocks a distinct failure mode rather than merely documenting it.
Supply chain assurance has become an identity governance problem as much as a tooling problem. Who can commit, who can approve, who can trigger builds, and which workflow may publish are identity decisions with security consequences. That makes CI/CD access governance and maintainer lifecycle controls part of supply chain security, not adjunct processes. Practitioners should govern those identities with the same care as privileged infrastructure access.
What this signals
Downstream trust leakage: the recurring failure pattern in modern supply chains is that a later integrity control can correctly describe a compromise it never had the power to stop. That changes the practitioner task from proving artifact lineage to constraining who can alter source, trigger build, and publish release credentials.
For teams running software delivery at scale, the signal is clear: branch protection, maintainer identity, workflow approvals, and publishing identity now sit in the same risk chain as the build system itself. If any one of those layers can be bypassed, provenance becomes evidence after the fact rather than a preventive control.
For practitioners
- Harden source-side approval paths Require signed commits from allowlisted maintainers, protected release branches, and mandatory review on release-adjacent paths so a compromised account cannot move bad code into the build.
- Separate build provenance from source trust decisions Treat provenance as evidence of build origin only, then add source review, maintainer identity checks, and branch policy as independent gates before a workflow can publish.
- Replace long-lived publishing secrets Use workflow-bound OIDC identities for package publication so registry tokens are not sitting in repo secrets where they can be phished or reused.
- Map controls to the full chain of custody Document which control protects source, which protects build, and which protects publish, then test whether any single compromise can still produce a valid artifact downstream.
Key takeaways
- SLSA provenance and trusted publishing are useful controls, but they only cover parts of the software delivery chain and cannot compensate for compromised source, maintainer, or release authority.
- The incidents described in the article show that a valid attestation can accompany malicious code when the source or release path is already compromised.
- The control model that works is layered and stage-specific, with separate governance for source change, build integrity, and publish identity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | The article shows how compromised upstream identities and release paths still produce valid downstream trust evidence. |
| NHI-05 — Overprivileged NHI | Maintainer and workflow privileges can still be abused to move malicious code through the chain. | |
| Recommendation — Map release and workflow identities to NHI-03 and separate source trust from publish authority. Reduce maintainer and workflow privilege so no single identity can approve, build, and publish alone. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The incidents described rely on upstream credential and workflow abuse to move compromise downstream. |
| Recommendation — Track source and release compromise patterns against TA0006 and TA0008 to strengthen detection and containment. | ||
| CIS Controls v8 | CIS-5 — Account Management | Maintainer, CI, and publishing accounts are the trust boundary the article says teams mis-handle. |
| Recommendation — Use CIS-5 to inventory, review, and remove excess access across source and release accounts. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about who can change code, trigger builds, and publish releases. |
| Recommendation — Apply PR.AA-05 to verify that source, build, and publish permissions are independently authorised. | ||
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.
- 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.
- Chain of custody: A documented record that preserves the integrity of evidence from the moment an event is detected through investigation and response. In identity and data protection workflows, it helps prove what happened, when it happened, and which actor or session was involved.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is suitable for practitioners who need to connect identity governance with software supply chain and privileged workflow access.
Published by the NHIMG editorial team on September 14, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org