Join our Newsletter — 33% off our NHI Course

Supply-chain worms: are your dependency controls keeping up?

 

(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 16489
Topic starter  

TL;DR: Most npm and PyPI supply-chain attacks now begin with a compromised maintainer account, then spread through malicious releases that steal npm, GitHub, AWS and SSH credentials before any CVE exists, according to Nullify research. CVE scanning is too late for this class of attack, and governance has to shift to pinned versions, release-age gating and fast exposure investigation.

Editorial analysis by NHI Mgmt Group, based on content published by Nullify: “Catching Supply-Chain Attacks Before a CVE Exists: Pins, Cooldowns, and Threat Investigations”.

Key questions

Q: What breaks when organisations rely on unpinned or automatically updated dependencies in software supply chains?

A: Unpinned dependencies remove the trust boundary between a known package and whatever version gets fetched later.

Q: Why do release-age controls reduce supply-chain risk before a CVE exists?

A: Release-age controls buy the ecosystem time to detect and remove malicious packages before your build accepts them.

Q: How do security teams know whether a malicious package has spread across the environment?

A: They need cross-application visibility that ties package names, versions, and dependency relationships to deployed assets.

Practitioner guidance

  • Implement exact-version pinning for direct dependencies Require reviewed version changes for npm, PyPI, Go, RubyGems, Maven, Gradle, Cargo, NuGet, Composer and Conda dependencies so a malicious registry release cannot enter builds through a floating spec.
  • Enforce a minimum release-age window Set a default cooldown, such as seven days, for direct and development dependencies, and apply ecosystem-specific overrides only where native release-age gates already exist.
  • Gate pull requests on dependency freshness Block or warn on PRs that add or bump packages newer than the policy window, and surface package name, publish date, age and window directly in the review.

Bottom line: Supply-chain worms exploit the gap between publication and vulnerability cataloging, so CVE-first defenses arrive too late for this threat class.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 5 months ago
Posts: 16980
 

Release-age policy is now a supply-chain trust control, not a convenience setting. The article shows that the relevant risk is not only malicious code but the timing of when that code becomes installable. Once ecosystem cleanup lags behind publication, a minimum release-age window becomes a practical governance boundary. Practitioners should treat that boundary as part of dependency admission control.

A few things that frame the scale:

  • 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.
  • 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.

A question worth separating out:

Q: Should teams prioritise cooldowns or CVE scanning for new package campaigns?

A: Cooldowns should take priority for unknown or newly published packages, because CVE scanning only works after a vulnerability has been identified and cataloged. CVE tooling still matters for known-bad dependencies, but it is not the primary control for fresh supply-chain compromise. Use both, but place admission controls ahead of catalog checks.

👉 Read our full editorial: Supply-chain worms outrun CVEs, so release-age controls matter



   
ReplyQuote
Share:

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.