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.
At a glance
What this is: Sonar argues that modern software supply chain attacks increasingly exploit secrets leakage and workflow trust, not just vulnerable dependencies.
Why it matters: This matters because IAM, PAM and AppSec teams need to treat CI/CD secrets, package trust and developer tooling as part of the access control surface, not just the code review surface.
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.
Context
Software supply chain security is a governance problem because the trusted path from code to release now includes dependencies, build systems, CI/CD secrets and AI-assisted development tools. Traditional scanning can still catch known vulnerabilities, but it does not by itself control what enters the pipeline, what credentials are exposed inside it, or what malicious logic is introduced through trusted tooling. The primary issue is not just code quality, but trust expansion across the software delivery chain.
For IAM and AppSec practitioners, the identity angle is real: pipeline credentials, maintainer accounts, service tokens and assistant configuration files all become access points once software delivery is treated as a security boundary. In this article, the supply chain is not a side topic to identity governance. It is the place where identity, secrets management and software assurance collide, and that makes workflow controls part of the access model.
The incidents Sonar cites are typical of the broader pattern, not exceptions. Once attackers can reach a build system, a package account or an AI coding workflow, they can reuse legitimate trust to move downstream at scale.
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. In this incident, the same compromise path reached GitHub, npm, AWS, GCP, Azure, Vault, SSH, and database credentials. That makes token scope and runner isolation central to blast-radius reduction.
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. They may have no CVE, no obvious defect and still behave normally enough to pass tests. Teams need provenance, package trust and behavioral screening, not only CVE status.
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. That creates provenance gaps, attribution problems, and review inconsistency. AI-written code should pass through the same identity, policy, and remediation controls as human-written code, especially when it enters shared repositories at speed.
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.
Technical breakdown
Why build pipelines become the real trust boundary
Modern supply chain attacks succeed because build systems often execute untrusted inputs with broad privileges. A misconfigured workflow, an unpinned dependency or a compromised maintainer account can turn a routine build into a secret-extraction or release-poisoning event. The attack does not need to break the software itself. It only needs one trusted execution point that can reach credentials, artifact publishing or downstream distribution. That is why pipeline design matters as much as source code review.
Practical implication: Treat CI/CD as a privileged environment and restrict what workflows, tokens and runners can access.
Why malicious packages evade CVE-centric controls
A CVE process describes known defects in legitimate software, but malicious packages are not defects in that sense. They are intentionally harmful artifacts that may look functional, pass tests and carry no vulnerability identifier at all. This is why registry reputation, version checks and standard vulnerability scanning miss part of the threat surface. The control problem is provenance and intent, not just known weakness detection.
Practical implication: Add malicious-package screening and provenance checks alongside ordinary vulnerability management.
How AI coding tools widen the supply chain surface
AI assistants now consume local files, prompts and configuration data to generate code, which means hidden instructions and leaked secrets can influence output before a human notices. Invisible Unicode characters in assistant rule files can embed backdoors, while local credentials can be captured and forwarded into provider logs through agent context gathering. That shifts risk from the repository alone to the developer workspace and the AI interaction layer. The governance question is no longer whether code was committed safely, but whether code generation was controlled safely.
Practical implication: Scan assistant configuration files and block secret exposure in agentic coding workflows before generated code is trusted.
Threat narrative
Attacker objective: The attacker wants to convert one trusted software distribution path into broad downstream compromise, credential theft and persistent access.
- Entry occurs through a misconfigured workflow, an unpinned dependency or a compromised maintainer account that attackers can use as a trusted foothold.
- Credential access follows when pipeline secrets, tokens or maintainer credentials are exposed and reused to publish malicious packages or poison releases.
- Impact comes when backdoored artifacts propagate into downstream installs at scale, harvesting credentials or enabling remote access across many environments.
Breaches seen in the wild
- tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
- 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
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.
Malicious package detection is now a distinct control category from vulnerability management. CVE-driven processes are designed to find flaws in legitimate software, while supply chain attacks increasingly ship intentionally malicious artifacts with no vulnerability record. That means traditional scanning can be necessary and still incomplete. Practitioners need controls that evaluate package trust, not only package defect status.
Developer workflow security is where modern supply chain governance has to move. The article shows that attacks can start in GitHub Actions, continue through package publishing and end inside AI-assisted coding environments. That creates a named concept worth tracking: workflow trust expansion, the steady enlargement of what is implicitly trusted inside the software delivery path. Practitioners should narrow that trust boundary before it is used against them.
AI coding assistants extend the software supply chain into the prompt and context layer. Hidden instructions in rules files and leaked local secrets show that the attack surface now includes what the developer asks the model to do and what the model can see. That makes AI usage a governance issue for code integrity as well as data handling. Practitioners should bring AI-assisted development under the same control discipline as package ingestion and release signing.
Quality gates only work when they are enforced at the point of change. Sonar's core argument is that detection after the fact is too late when malicious code can move from publication to downstream installs in hours. The industry problem is not lack of tools, but late control placement. Practitioners should place enforcement in the pull request and pipeline path, where trust is granted.
From our research library:
- The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
- Read next: Secrets Management Buyer's Guide
What this signals
Workflow trust expansion: software teams now grant trust to code, build systems, package registries and AI assistants in one path, which means the weakest approval point can become the release point. Practitioners should narrow that trust boundary so a compromised workflow cannot automatically inherit publishing power.
The more release logic and developer assistance move into automated tooling, the more security teams need controls that evaluate provenance and intent rather than just known vulnerabilities. That shift changes AppSec from defect hunting to trust-boundary management, and it pulls IAM and PAM deeper into the developer lifecycle.
For practitioners
- 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.
- Review AI assistant rule files for hidden instructions Inspect .cursorrules, .mdc and similar assistant configuration files for invisible control characters or policy-bypassing text that could alter generated code.
- Force incident response on affected build environments Rotate credentials and assume compromise for any runner or workstation that executed a malicious dependency, even if the package was later removed.
Key takeaways
- 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.
- The article's examples show that a single workflow weakness can cascade into poisoned releases, exposed credentials and broad install-time impact across ecosystems that developers rely on.
- The control gap is at the point of trust grant, which means teams need enforcement in CI/CD, package ingestion and AI-assisted development rather than only after deployment.
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, OWASP API Security 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-02 — Secret Leakage | The article centers on exposed CI/CD and developer secrets as the entry point for supply chain compromise. |
| NHI-07 — Long-Lived Secrets | Reusable pipeline tokens and maintainer credentials enable the cascading compromise described in the article. | |
| Recommendation — Scan code, pipelines and AI tool inputs for secret leakage and revoke any exposed credentials immediately. Reduce the lifespan and reuse of pipeline secrets so one compromise cannot persist across releases. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Compromised maintainer and bot credentials show how authentication failure enables release abuse. |
| Recommendation — Harden authentication for publishing accounts and bot tokens before they can be used to ship malicious artefacts. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article's incidents depend on abused maintainer, bot and workflow accounts. |
| Recommendation — Review and remove stale accounts and automation identities that can still publish or sign releases. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Pipeline permissions and release entitlements determine whether a compromise can cascade downstream. |
| Recommendation — Limit workflow and release permissions so build systems can only do the minimum required. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The attack pattern uses credential theft to move from one trusted point into downstream environments. |
| Recommendation — Map pipeline secret theft and release poisoning to TA0006 and TA0008 in your threat detections. | ||
Key terms
- Supply chain attack path: A supply chain attack path is any route by which a trusted external tool, dependency or partner becomes the mechanism for compromise. It matters because attackers often abuse legitimate integrations instead of exploiting the core system directly, which makes detection and containment harder.
- CI/CD secret: A CI/CD secret is a credential used by build or deployment automation to reach source control, cloud services, registries, or internal systems. In practice it is a non-human identity artifact, so its scope, lifetime, storage location, and revocation path must be governed like any other privileged access token.
- Malicious Package: A malicious package is software published into a legitimate repository but designed to execute harmful code when installed. It abuses normal dependency workflows so that the attacker’s code reaches the environment through trust in the package ecosystem, not through a traditional exploit.
- Workflow trust boundary: A workflow trust boundary is the point where one step in a business or technical process stops being fully trusted and must be checked before the next step continues. It defines where identity, data, or action permissions change, and where controls such as approval, validation, logging, or isolation should be applied.
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 practitioners connect identity controls to the software delivery paths that now carry real production risk.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org