Notifications
Clear all
Topic starter
02/08/2026 11:38 am
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.
NHIMG editorial — based on content published by Semgrep: LLMjacking and supply chain worm analysis of compromised non-human identities
By the numbers:
- 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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read Semgrep's analysis of supply chain worms and compromised maintainer identities →
Supply chain worms and compromised maintainers: what teams should change?
Explore further
02/08/2026 12:51 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Supply chain worms are exposing a structural NHI governance gap
