Topic starter
20/08/2026 5:22 pm
TL;DR: March 2026 supply chain incidents involving Trivy, LiteLLM, and Axios show that one compromised workflow can cascade from secret theft to backdoored downstream installs, according to Sonar. The deeper issue is that modern supply chain risk now spans dependencies, CI/CD secrets, and AI coding tools, so security controls have to move into the developer workflow.
Editorial analysis by NHI Mgmt Group, based on content published by Sonar: “Why your supply chain attack surface is expanding”.
By the numbers:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
Key questions
Q: Why do CI/CD secrets create such a large blast radius in supply chain attacks?
A: CI/CD secrets are often shared across build, publish, and cloud tasks, so one exposed token can touch many systems at once.
Q: Why do malicious packages bypass traditional vulnerability management?
A: Because vulnerability management is built to track known flaws in legitimate software, while malicious packages are designed to be harmful from the start.
Q: What do teams get wrong about AI-generated code in supply chain security?
A: They often treat AI-generated code as a tooling novelty instead of governed production input.
Practitioner guidance
- Harden CI/CD runner trust boundaries Remove unnecessary write permissions, pin third-party actions and treat pipeline secrets as high-risk credentials that should not be broadly reusable.
- Separate malicious package checks from CVE scanning Add controls that detect intentionally harmful packages and do not assume a clean vulnerability report means the dependency is safe.
- Scan developer secrets before they reach source control Check code, config files and CI/CD inputs for exposed API keys, tokens and cloud credentials before commits are merged.
Bottom line: The core risk is no longer just vulnerable open source code. It is the way trusted workflows, pipeline secrets and AI tools let malicious artefacts move from one compromise into many downstream environments.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:13 pm
Secrets sprawl has become a supply chain exposure problem, not just an IAM hygiene issue. When credentials live in code, CI/CD systems and developer tooling, the boundary between access management and software assurance disappears. The practical failure is not simply that secrets exist, but that they are placed in environments where build systems and AI tools can consume them. Practitioners should treat secret location as a release-risk signal, not a housekeeping detail.
A few things that frame the scale:
- The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
A question worth separating out:
Q: How should IAM and AppSec teams govern release pipelines after a supply chain compromise?
A: They should treat the pipeline as privileged infrastructure, not as a neutral transport layer. That means enforcing least privilege on workflow tokens, limiting who can publish artifacts, and requiring rapid revocation when a build runner or maintainer account is compromised. Supply chain governance fails when release trust is left implicit.
👉 Read our full editorial: Software supply chain attacks are now a secrets problem