Supply chain worms are exposing a structural NHI governance gap

At a glance

What this is: This article argues that modern supply chain worms work because trusted publishing, maintainer credentials, and CI/CD automation create a fast-moving trust inheritance problem.

Why it matters: It matters to IAM, PAM, and NHI teams because the same credential and workflow assumptions that govern software delivery now determine how quickly compromise can spread through build pipelines and downstream packages.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Semgrep's analysis of supply chain worms and compromised maintainer identities

Context

Supply chain worms succeed when trust is inherited faster than it can be revoked. In this case, the key problem is not only malicious code in a package registry, but the combination of maintainer phishing, CI/CD triggers, and automated dependency consumption that turns a single compromise into repeated downstream execution. In identity terms, the NHI exposure window is created by long-lived publishing rights and workflow credentials that are treated as reliable until after damage is done.

The article's central point is that modern package ecosystems still assume trust can be reviewed after the fact. That assumption fails when attackers use maintainer credentials, OIDC extraction, or pull_request_target workflow abuse to move through publishing pipelines before defenders can react. For identity and security teams, this is a governance problem as much as a malware problem, because the blast radius is defined by who or what can publish, execute, and inherit trust without fresh verification.

Key questions

Q: What breaks when a trusted npm package publisher is compromised?

A: When a trusted publisher is compromised, registry trust collapses because malicious code can arrive through a legitimate release path. The immediate failure is not only package integrity, but also the downstream assumption that a maintainer identity is a reliable control point. In practice, one hijacked publishing account can turn install-time trust into broad credential exposure.

Q: Why do CI/CD workflows make supply chain worms harder to contain?

A: CI/CD systems are built to consume new code automatically, often with privileged access to secrets, caches, and release rights. That means malicious code can execute before a human notices the change. The more automated the pipeline, the smaller the defender's reaction window becomes.

Q: How can security teams measure whether supply chain controls are actually working?

A: Look for reduced use of long-lived publishing tokens, fewer workflows with broad secrets access, lower dependency auto-update exposure, and faster revocation after compromise. If malicious releases still reach trusted build paths before detection, the controls are not containing trust inheritance.

Q: Who is accountable when a workflow compromise leads to malicious package releases?

A: Accountability is shared, but it cannot be vague. Repository owners, platform engineering, security, and package maintainers all have control over workflow design, secret scoping, and publishing identity governance. In regulated environments, incident response and control ownership should be documented before the next compromise happens.

Technical breakdown

How supply chain worms exploit publishing rights and workflow trust

A supply chain worm needs an entry point, a propagation path, and a payoff. In these campaigns, the entry point is often maintainer phishing or workflow abuse, while the propagation path is the publisher's own package rights or CI/CD automation. The malicious code does not need to be clever. It only needs to ride trusted publishing flows, execute inside build systems, and reach dependency consumers before detection catches up. This is why registry trust and pipeline trust are inseparable.

Practical implication: treat package publishing credentials and CI workflows as high-risk NHI assets with strict scoping and short lifetimes.

Why pull_request_target and cache poisoning create reusable access

The pull_request_target event runs with base-repository context, which can include secrets and write permissions even when the pull request comes from a fork. If a workflow also writes to a shared Actions cache, an attacker can poison that cache and influence later trusted jobs that read from it. This is a classic trust-boundary failure: an untrusted contributor action is allowed to affect a privileged execution path. The result is not just code execution, but credential exposure inside the trusted build context.

Practical implication: remove privileged secrets from fork-triggered workflows and separate cache namespaces from sensitive release jobs.

Trusted Publishing does not remove the NHI problem by itself

Trusted Publishing replaces long-lived package tokens with OIDC-based federation, which reduces one class of credential theft. But the article shows that attackers adapt by targeting the runtime environment for token extraction or by shifting to earlier workflow stages. That means the control surface has moved, not disappeared. The real issue is whether a publisher identity can be assumed to remain trustworthy across the full lifecycle of a build and release chain.

Practical implication: pair OIDC federation with hard controls on build isolation, runtime secret access, and workflow approval boundaries.

Threat narrative

Attacker objective: The objective is to convert a single trusted maintainer or workflow compromise into repeated package publishing, downstream code execution, and credential theft across the ecosystem.

1. Entry occurs when attackers phish maintainers or abuse pull_request_target workflows to get code executing in a privileged CI context.
2. Escalation follows when the workflow context exposes secrets, writable caches, or publishing rights that let the attacker poison release paths or extract tokens.
3. Impact lands when malicious packages propagate through dependency graphs and infected builds exfiltrate credentials before the registry takedown closes the window.

NHI Mgmt Group analysis

Trust inheritance is the central failure mode in modern supply chain worms. The article describes a world in which a package's past reputation still matters more than its current integrity. That is the wrong model for ecosystems where maintainer credentials, publishing rights, and CI workflows can all be hijacked in a single chain. The control gap is not just bad code detection, but the assumption that legitimacy survives credential compromise.

Compromised maintainer credentials now function as reusable non-human identities. When a maintainer's publishing token or workflow identity is stolen, the attacker inherits the right to act as that maintainer across multiple packages and ecosystems. That places supply chain security squarely in NHI governance territory, not just software integrity management. The policy answer is lifecycle control over every publishing identity, not blind trust in historical ownership.

Workflow trust must be treated as a privilege boundary, not a build convenience. GitHub Actions patterns such as pull_request_target and shared caches can convert ordinary automation into a privileged execution lane. The article shows that a single misconfigured workflow can become the foothold for credential theft and spread. This is a governance failure in CI design, and teams should review it through least-privilege and zero-standing-privilege principles.

Detection-only supply chain defence creates posture management fatigue. Pulling malicious packages after they are reported reduces harm, but it does not stop the next wave from entering the same path. That means the industry is still over-relying on registry cleanup and security vendor alerts instead of reducing the conditions that let worms execute in the first place. Practitioners should treat runtime execution controls and publishing restrictions as the real boundary.

Package ecosystems need identity-aware guardrails, not just faster revocation. The article is clear that attackers adapt to each mitigation, whether that is Trusted Publishing, shorter token lifetimes, or renewed phishing pressure. That should push teams toward stronger identity verification for release workflows, better segregation of build privileges, and explicit trust boundaries around dependency consumption. The category is moving toward governance of who can publish, not just what can be scanned.

What this signals

Trust inheritance is now the operational weak point in software delivery. Teams that still rely on registry takedown and post-event scanning will continue to absorb damage from the next wave of package worms. The practical shift is toward explicit publish permissions, isolated build state, and revocation tied to identity lifecycle events, not just alerting.

Publishing identities need the same governance discipline as privileged human access. Maintainer tokens, OIDC trust relationships, and CI/CD release identities should be subject to ownership, expiry, and review. The more your delivery pipeline can act without fresh verification, the more likely an attacker can convert one foothold into repeated compromise.

Package ecosystems are moving from code risk to identity risk. That makes controls such as least privilege, short-lived credentials, and workflow isolation central to resilience, not optional hardening. For teams that want a framework anchor, the OWASP Non-Human Identity Top 10 and MITRE ATT&CK Enterprise Matrix are the most useful starting points for mapping the abuse path.

For practitioners

• Lock down privileged workflow triggers Review every pull_request_target workflow, shared cache path, and release job that can touch secrets or write into build state. Fork-originated contributions should not be able to influence privileged pipelines without explicit isolation and approval.
• Treat publishing identities as NHI assets Inventory package publishing tokens, OIDC trust relationships, and maintainer automation accounts as non-human identities with owners, expiry, and revocation steps. Limit each identity to a narrow repository or package boundary.
• Separate untrusted build state from release state Use distinct cache namespaces, isolated runners, and release-only environments so a low-trust job cannot poison later trusted jobs. Build systems should not reuse state across privilege levels.
• Reduce dependency auto-consumption windows Add cooldowns for newly published dependencies, pin versions where possible, and require human review for unexpected package updates. This gives defenders time to detect malicious releases before they are pulled into production builds.
• Rotate and revoke on workflow compromise, not just on package alerts If a CI workflow or maintainer account is suspected, revoke all associated secrets, tokens, and federation trusts immediately. Package takedown alone does not remove access already embedded in build systems.

Key takeaways

• Supply chain worms succeed because trusted publishing identities, CI workflows, and automatic dependency consumption create a reusable trust path.
• The evidence points to a fast-moving exposure window, where malicious code can execute before detection and revocation catch up.
• Teams need identity-aware workflow isolation, publishing controls, and revocation discipline, not just faster package scanning.

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.
• 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.
• Pull Request Target Risk: A workflow risk pattern where untrusted pull request content is processed in a privileged context. Because the job may run with write access or access to secrets, the boundary between review and execution collapses. The control failure is not the pull request itself, but the permissions attached to the trigger.
• 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.

What's in the full article

Semgrep's full analysis covers the operational detail this post intentionally leaves for the source:

• Workflow-level examples of how pull_request_target and shared cache abuse enable compromise.
• Practical response guidance for maintainers dealing with phished publishing credentials and reused package rights.
• Mitigations for dependency consumption, token rotation, and release pipeline hardening after a worm event.
• The specific attack variants and ecosystem differences across npm, PyPI, and Packagist.

👉 The full Semgrep article covers the attack chain, workflow abuse patterns, and response guidance in more detail.

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 helps practitioners connect identity controls to the operational realities of modern delivery pipelines.