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.
Editorial analysis by NHI Mgmt Group, based on content published by Kusari: “One lock is not a security program”.
Key questions
Q: What breaks when SLSA provenance is treated as the whole supply chain programme?
A: Teams lose sight of the source layer.
Q: Why do source repository compromises still defeat trusted publishing?
A: Trusted publishing protects the registry token path, not the source repository itself.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/09/2026 10:10 am
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.
A question worth separating out:
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.
👉 Read our full editorial: SLSA does not stop source compromise: what the incidents show