The 2025 software-supply-chain incidents on npm read like a pattern, not a coincidence. The Shai-Hulud worm spread by stealing credentials from one compromised package and using them to publish malicious versions of others, propagating on its own. The chalk and debug compromise began with a maintainer being phished and ended with malicious releases of packages that sit underneath an enormous share of the JavaScript ecosystem. The Nx s1ngularity incident weaponized build automation to harvest developer secrets. Different entry points, same engine underneath.
That engine is the standing publish token. A long-lived credential that can publish to a registry is, functionally, the ability to ship code to everyone who depends on your package. When that credential is stolen — by phishing, by a compromised CI job, by a poisoned dependency already running on a maintainer’s machine — the attacker inherits the maintainer’s reach. And on a registry, reach is transitive.
Why a worm is even possible here
Self-propagation requires two ingredients: a credential with publish rights, and an environment where that credential is sitting around to be stolen. The npm ecosystem supplies both abundantly. Publish tokens are frequently long-lived, broadly scoped, and stored in CI environments and developer machines that themselves run untrusted code constantly. A worm does not need to break cryptography; it just needs to find the next token and use it the way it was designed to be used.
This is why these incidents propagate in a way that a typical vulnerability does not. A single stolen standing token is not one compromised package — it is a foothold from which to reach every package that token can publish, and every credential those packages’ build environments expose in turn. The blast radius compounds at the speed of the registry.
A worm does not need to break cryptography. It just needs to find the next standing token and use it exactly as designed.
Standing versus short-lived
The structural fix the industry keeps converging on is to stop having long-lived publish credentials at all. Short-lived, narrowly scoped tokens — minted just-in-time for a specific publish from a verifiable build, and expiring almost immediately — drain the pool an attacker fishes in. A credential that exists for ninety seconds and only authorizes one action is a far smaller prize than one that lives in a CI secret for two years and can publish anything.
TrustFix approaches publish and deploy identities as exactly that: non-human identities whose standing privilege is a measurable liability. We surface where long-lived, broadly scoped publish credentials exist, what they can reach, and which ones have quietly outlived their purpose — so the swap from standing to short-lived becomes a tracked decision rather than a someday-aspiration.
The limit, stated plainly
We will not pretend visibility into credentials prevents a maintainer from being phished. The chalk and debug incident started with a convincing email to a human being, and no inventory of tokens intercepts that moment. Phishing, malicious dependencies that execute on a developer’s machine, and social engineering of trusted maintainers are real and largely upstream of anything a posture tool can stop.
What changes with visibility is the second half of the attack. A worm’s power comes from finding standing credentials to reuse. If those credentials are short-lived, scoped, and inventoried — and if the long-lived ones that remain are known, owned, and on a clock — the phished maintainer is a contained incident instead of the first node of an outbreak. You cannot remove the human from the target list. You can remove the standing token that turns one victim into a thousand.
What to do on Monday
Find every credential in your build and release pipelines that can publish or deploy, and treat each as a governed identity with an owner and an expiry. Move publish credentials toward short-lived, just-in-time issuance wherever your registry and CI support it. Audit the long-lived tokens that remain and justify each one explicitly. The goal is not to make supply-chain attacks impossible — it is to ensure that when one lands, it stops at the first machine instead of riding your own credentials to the next.