Topic starter
18/08/2026 2:37 pm
TL;DR: A compromised Trivy release spread through CI/CD pipelines because downstream projects trusted unpinned GitHub Actions and transitive dependencies, allowing credentials theft and wider supply chain impact, according to Kusari. The lesson for identity and security teams is that implicit trust in build-time artifacts creates a governance gap that immutable verification must close before code ships.
Editorial analysis by NHI Mgmt Group, based on content published by Kusari: “How Kusari Protects Against Recent Supply Chain Attacks”.
Key questions
Q: What breaks when a CI workflow depends on mutable action tags?
A: Mutable tags turn a build step into a remote code execution dependency because the workflow resolves whatever code the tag points to at run time.
Q: Why do compromised build tools so often expose credentials?
A: CI systems commonly hold deployment tokens, package publishing secrets, and other machine credentials with enough privilege to move code or access services.
Q: What are the signs that software supply chain controls are failing in practice?
A: Common warning signs include overreliance on vulnerability lists, weak visibility into third party dependencies, limited scrutiny of developer tooling, and no practical way to audit the full software estate.
Practitioner guidance
- Pin every workflow reference to an immutable commit hash Replace mutable version tags in GitHub Actions and other CI tooling with commit-hash pins so reviewed workflow logic cannot be swapped after approval.
- Inventory transitive dependencies in build pipelines Maintain a dependency graph that includes indirect packages and actions so hidden upstream exposure is visible before a compromise reaches production builds.
- Generate build-level SBOMs for every release Record the exact versions used in each build so responders can identify affected services quickly when an upstream package or action is compromised.
Bottom line: The compromise exposed a common software supply chain failure mode: teams trust mutable build inputs and only discover the problem after secrets have already been exposed.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:22 pm
Build trust has become a governance control, not a developer convenience. The article shows that mutable workflow references and implicit confidence in popular open source tooling let a single poisoned release travel through CI/CD systems. In governance terms, this is not just a software quality issue. It is a control failure over what automation is allowed to execute before code ships.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: How should teams respond when a trusted dependency is poisoned?
A: Contain the identity layer first: revoke exposed tokens, rotate credentials, inspect active sessions, and trace which pipelines consumed the poisoned reference. Then rebuild trust from immutable artifacts and verified provenance. The response is less about removing bad code from one repository and more about closing the access paths the compromised code could use.
👉 Read our full editorial: Software supply chain trust gaps are still breaking CI pipelines