TL;DR: Supply chain worms are succeeding because compromised maintainer credentials, CI/CD trust, and automated package consumption let malicious code spread before detection and revocation can catch up, according to Semgrep. The real control gap is not just faster response, but reducing the standing trust that lets one compromised NHI or workflow propagate across an ecosystem.
At a glance
What this is: Semgrep says supply chain worms are succeeding because compromised maintainer access, CI/CD trust, and automated package publication let malicious code spread before defenders can contain it.
Why it matters: This matters because IAM and NHI teams need to treat package publish rights, OIDC-bound workflows, and third-party dependency trust as governance problems, not just incident-response problems.
By the numbers:
- 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.
Context
Supply chain worms exploit trust that was designed for software distribution, not for adversarial propagation. In practice, a maintainer account, CI/CD workflow, or package registry permission becomes a machine-access path, so the security question is no longer only code integrity but also who can publish, trigger, or inherit trust across the delivery chain.
The article’s central NHI angle is that publishing tokens, workflow credentials, and build-time identities behave like non-human identities with standing authority. Once one of those identities is phished or abused, downstream packages and automated consumers can inherit the compromise without any deliberate human action. That is why this pattern keeps recurring across ecosystems rather than stopping after the first takedown.
Key questions
Q: What breaks when a package maintainer account is compromised?
A: When a maintainer account is compromised, the attacker inherits trusted publishing rights and can turn legitimate release channels into malware distribution paths. That breaks the assumption that package provenance is tied to a stable, accountable identity. The result is not just one bad package, but potentially broad downstream exposure across automated build and install pipelines.
Q: Why do phishing-resistant MFA and token rotation only partially reduce supply chain worm risk?
A: They reduce the chance that a stolen credential keeps working, but they do not remove the ecosystem conditions that let a worm spread. Automated consumption, broad publishing rights, and trusted CI workflows can still propagate malicious code quickly. The risk falls, but the underlying trust model remains intact.
Q: What are the signs that a CI/CD supply chain compromise is already underway?
A: Common warning signs include new outbound connections from runners, secrets appearing in logs, unexpected use of trusted domains, and workflow behavior that no longer matches the established baseline. A clean pipeline usually shows stable network patterns and predictable execution. When those patterns change suddenly, teams should treat it as an active compromise signal.
Q: How should teams respond when a supply chain worm spreads through trusted packages?
A: Contain the publishing surface first. Revoke exposed tokens, rotate credentials, review repository creation and workflow changes, and roll back to known-clean package versions. Then scope the blast radius across developer environments, CI/CD systems, and any cloud accounts that shared the same secrets.
Technical breakdown
Why package ecosystems are worm-friendly
Dependency ecosystems create the three conditions a worm needs: entry, spread, and value before detection. A phished maintainer or compromised workflow provides entry. Publishing rights, reusable tokens, and CI/CD automation provide spread. Automated consumers provide value because they fetch and run new versions quickly, often before any human review occurs. This is not the same as classic malware persistence inside a network. The worm does not need long dwell time if it can move through trusted distribution channels and execute inside build pipelines that are already permitted to run code.
Practical implication: Treat package publish rights and build identities as attack surface, not just developer convenience.
How pull_request_target and cache poisoning turn CI into access
A pull_request_target workflow runs in the context of the base repository, so a forked pull request can execute logic with access to secrets and write permissions if the workflow is misconfigured. If that workflow also writes to a shared cache namespace, a malicious fork can poison data that later production workflows read back. The result is not just a bad build. It is attacker-controlled code execution inside a trusted CI context, often with credential exposure through environment variables, tokens, or artifact handling. In identity terms, the workflow identity inherited more privilege than the contributor should have received.
Practical implication: Review pull_request_target usage and cache scope as privilege boundaries, not only as build optimisations.
Why trust inheritance is the real governance failure
The deeper problem is trust inheritance. A package may have years of legitimate history, but once a maintainer identity is abused, the ecosystem continues to trust the package name, the version stream, and the surrounding automation. That means revoking a token after detection limits one incident, yet it does not unwind the access already exercised by downstream consumers. In machine-identity terms, the lifecycle is incomplete: issuance is easy, but offboarding and revocation happen after the malicious execution has already propagated. This is why the control gap is structural rather than tactical.
Practical implication: Move from post-breach revocation to pre-execution gating on publisher, workflow, and dependency trust.
Threat narrative
Attacker objective: The attacker wants to turn one compromised maintainer or workflow into broad downstream code execution and secret theft across the package ecosystem.
- Entry begins with phishing, a pwn request, or another compromise of a maintainer-facing identity that can trigger publishing or workflow access.
- Credential access and workflow abuse let the attacker extract tokens or exploit a misconfigured GitHub Actions path with write permissions and secret access.
- Escalation happens when the attacker reuses those publishing rights to infect additional packages or poison CI caches that later trusted workflows consume.
- Impact is malicious code execution inside downstream build pipelines and package consumers, followed by secret theft and wider ecosystem spread.
Breaches seen in the wild
- Trivy supply chain attack 2026: A PAT stolen via a Trivy workflow and a botched rotation let TeamPCP poison Trivy releases and Action tags to steal CI/CD secrets.
- 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.
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
Supply chain worms expose a standing-trust problem, not just a malware problem. The recurring failure is that publishing rights, workflow permissions, and registry trust remain valid long enough for an attacker to use them multiple times before revocation catches up. In an NHI lens, those credentials behave like unmanaged service identities with broad blast radius. Practitioners should stop describing this only as a faster detection problem and start treating it as a lifecycle control failure.
Trust inheritance is the named concept that best captures the gap. Once a package or maintainer has years of legitimacy, downstream consumers and automation continue to trust it even after its identity has been abused. That makes the compromise invisible to controls that only look for unknown packages or obvious typosquatting. The lesson for identity teams is that provenance must be checked at issuance time, not only after a version is already published.
CI/CD runners are now part of the identity perimeter. Build systems, release workflows, and cache layers are not neutral infrastructure when they can access secrets and publish artifacts. If a workflow can inherit write authority from a base repository or token, then it is already an identity governance problem. Security teams should map these paths as privileged access chains and not as ordinary automation.
Revocation alone cannot solve a propagation problem. Token rotation after the fact still matters, but it only limits the current campaign. The next wave will simply use the same ecosystem properties unless teams reduce standing trust, constrain automatic consumption of unvetted releases, and separate build identities from publish identities. The practical conclusion is that package trust needs runtime gating, not just incident cleanup.
Cross-ecosystem spread confirms that the control gap is architectural. The same pattern is now appearing across npm, PyPI, and other registries because the core dependency model is shared: many publishers, many consumers, and too much implicit trust between them. That means remediation cannot sit only with individual maintainers. Ecosystem governance, CI policy, and NHI lifecycle controls all have to move together.
From our research library:
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
- Read next: Ultimate Guide to NHIs — What are Non-Human Identities
What this signals
Trust inheritance is becoming the defining supply chain control gap. Ecosystems that assume package history equals package safety will keep absorbing repeated worm campaigns, because the publishing identity is what gets abused, not just the package name. Security programmes need to align dependency trust with identity lifecycle controls, or the same pattern will recur across registries.
CI/CD runners now sit inside the governance boundary for non-human identities. When build systems can write artifacts, consume secrets, and publish releases, they are operating as privileged machine identities and must be governed that way. The practical shift is to treat workflow design, cache scope, and publish permissions as part of NHI control design rather than DevOps implementation detail.
For practitioners
- Tighten workflow trust boundaries Remove broad secrets access from fork-triggered workflows, especially those using pull_request_target, and separate build-only execution from publish-capable paths.
- Constrain package publish identities Use short-lived, OIDC-bound publishing credentials and limit each identity to the smallest possible package set so one stolen token cannot spread laterally across a maintainer portfolio.
- Treat caches and artifacts as privileged inputs Assume shared caches, build artifacts, and dependency downloads can be poisoned, then require provenance checks before trusted workflows consume them.
- Add release cooldowns for newly published packages Delay automatic consumption of fresh upstream releases long enough for review, detection, and registry response to occur before production builds pull them in.
- Map maintainer and CI identities as a single access path Inventory which human maintainers, service accounts, and CI workflows can publish or modify packages so you can see where one compromise becomes ecosystem-wide reach.
Key takeaways
- Supply chain worms keep succeeding because trust in maintainers, workflows, and registries still outlasts the compromise of the identity that controls them.
- The pattern is already showing up across ecosystems, which means the issue is architectural rather than a one-off incident response problem.
- Reducing risk requires harder boundaries on publish rights, workflow permissions, and automatic consumption, not just faster token rotation.
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 NIST CSF 2.0 and CIS Controls v8 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 | Compromised maintainers and package publishers are third-party NHIs abused in this campaign. |
| NHI-04 — Insecure Authentication | Phishing and stolen publishing tokens show weak authentication paths for maintainers and workflows. | |
| NHI-07 — Long-Lived Secrets | The article repeatedly shows how durable tokens and cached trust let worms keep spreading. | |
| Recommendation — Inventory third-party publishing identities and revoke trust where offboarding or ownership is unclear. Move maintainer and publishing access to phishing-resistant, short-lived authentication paths. Replace long-lived publish tokens with short-lived credentials and tighten rotation enforcement. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack chain centers on credential theft followed by movement through packages and workflows. |
| Recommendation — Map maintainer compromise to TA0006 and TA0008 to prioritise credential theft and spread paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Publishing rights and workflow permissions are the core governance issue in this article. |
| Recommendation — Review entitlements for build and publish identities under PR.AA-05 and remove standing excess access. | ||
| CIS Controls v8 | CIS-5 — Account Management | Maintainer and CI account lifecycle failures enable repeated package compromise. |
| Recommendation — Apply account management controls to publish-capable identities and remove dormant or overbroad access. | ||
Key terms
- Supply Chain Worm: A supply chain worm is malware that uses one compromise to propagate into adjacent packages, repositories, or automation systems. In identity terms, it becomes far more dangerous when it can harvest and replay secrets that let it publish, move, or persist without further exploitation.
- Trust Inheritance: The condition where one credential or integration is allowed to carry trust into multiple connected systems. It is often invisible until a token is replayed from outside the intended context. In practice, trust inheritance is what turns a valid login event into a cross-platform compromise.
- Pull_request_target workflow: A GitHub Actions trigger that runs in the context of the base repository, not the contributor’s fork. That means it can access repository secrets while processing untrusted pull request content, which creates a sharp trust boundary and a common route to secret theft if not carefully segmented.
- 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.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to turn identity controls into durable programme decisions.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org