Software Supply Chain Attacks: The Dependency You Never Reviewed

Every developer knows the moment. You type one install command, a progress bar scrolls, and your project gains dozens of packages written by people you will never meet. Most of them arrive as dependencies of dependencies, and nobody on your team chose them. Attackers have noticed. ReversingLabs, cited in the CSIS Spring 2026 Threat Matrix Report, recorded a 100% increase in malicious npm packages in 2025. In Q2 2026, NCC Group reported a sharp escalation in attacks on the ecosystems developers rely on. The uncomfortable question for any engineering leader is simple: if one of those packages were malicious tomorrow, how would you find out?

 

 

The Numbers Behind the Warning

Three data points, from three different vantage points, tell the same story.

 

Volume. Sonatype's Q2 2025 Open Source Malware Index counted 16,279 new malicious packages in a single quarter, taking its cumulative total to 845,204, with detected malware up 188% on the same quarter a year earlier. (The percentages Sonatype reports for sub-categories do not reconcile cleanly with its counts in the coverage I reviewed, so I have used only the headline figures.)

 

Technique. CSIS notes that open-source compromise has broadened from typosquatting into maintainer compromise and malicious updates, and that developer tooling and build infrastructure have become a recurring "first breach" vector.

 

Escalation. NCC Group's Q2 2026 report describes a sharp rise in attacks on GitHub Actions, npm, PyPI, Docker Hub, Open VSX, and the Visual Studio Code Marketplace. It links much of the most significant activity to TeamPCP, a financially motivated group, and says these attacks exploit "transitive trust." That phrase is the heart of the problem.

 

 

Case Study: A Worm That Published as the Maintainer

In September 2025, CISA warned of a widespread compromise of the npm ecosystem by a self-replicating worm known as Shai-Hulud. After gaining access to one developer's account, it used an automated process to authenticate to npm as that developer, inject its code into other packages the developer maintained, and publish the compromised versions. CISA reported more than 500 affected packages. The malware hunted for GitHub personal access tokens and cloud API keys for AWS, Google Cloud, and Azure, then exfiltrated them, including to a public GitHub repository.

 

Note the shape of the attack. Nobody had to fool a customer. The route in was a maintainer's credentials, and the spread rode on the trust each package inherited from the last. NCC reports that the source code of a successor, "Mini Shai-Hulud," was published to GitHub in May 2026, spawning derivative campaigns named Miasma and Hades. Once a technique is public, it is reused.

 

 

Why "We Scan for Vulnerabilities" Is Not Enough

Vulnerability scanners ask whether a known flaw exists in a package you use. A supply chain attack asks a different question: is the package itself hostile? A malicious release has no CVE on the day it ships. Teams that rely only on scanning learn about it after the advisory, which may be after the credentials have gone.

 

A dependency review closes that gap. It treats third-party code as something you adopt deliberately, the way you would a vendor, instead of something that simply appears.

 

 

What a Dependency Review Looks Like in Practice

1. Build the inventory first. List every direct and transitive dependency from your lockfiles, and produce a software bill of materials (SBOM). Include more than application libraries: CI actions, build plugins, container base images, and IDE extensions are all part of what NCC lists as targeted ecosystems.

 

2. Rank by blast radius. Not every package is equal. Prioritise those that run during install or build, touch secrets or production credentials, handle authentication or cryptography, or are maintained by one person.

 

3. Vet before you add. For each new dependency, ask whether you need it at all, who maintains it, how recently and how actively, whether releases carry provenance information, and whether the name resembles a popular package (typosquatting). A package you can replace with twenty lines of your own code is often a risk you can remove.

 

4. Lock, pin, and review the diff. Install from lockfiles so builds are reproducible, and review lockfile changes in pull requests as you would code. In its Shai-Hulud guidance, CISA advised pinning npm dependencies to known safe releases and checking nested dependencies. A reasonable extension, which is our recommendation, is a short delay before adopting brand-new releases of critical packages.

 

5. Shrink what a compromised package can steal. Shai-Hulud harvested tokens and cloud keys, so limit what build environments hold. Use short-lived, narrowly scoped credentials in CI instead of long-lived secrets, and require phishing-resistant multi-factor authentication on developer accounts, as CISA recommends. GitHub has announced npm changes along the same lines: mandatory 2FA for local publishing, wider use of short-lived trusted-publishing tokens, and publishing tokens limited to seven days. Check what is in force before you rely on any of it.

 

6. Watch, and rehearse the response. Subscribe to advisories for your critical packages, and keep a runbook for the day one is compromised: identify affected builds, rotate every credential those builds could reach, and rebuild from known-good versions. CISA's guidance includes immediate rotation of developer credentials.

 

 

Where Code Analysis Fits, and Where It Does Not

Static and dynamic code analysis find flaws in your own code and in how it uses libraries: injection paths, unsafe deserialisation, hard-coded secrets, and weak authentication. That matters, because a dependency is only dangerous when your application gives it somewhere to act. But code analysis does not, by itself, tell you that a package has been backdoored. It complements dependency review and does not replace it. The two together cover what you wrote and what you borrowed.

 

 

The Newest Dependencies Are Not Packages

Applications increasingly depend on pre-trained models, datasets, and agent tools pulled from public hubs. These are dependencies too, and they carry the same trust problem: someone else built them, and you may be running them with real permissions. The review questions above apply almost unchanged: who published it, can you verify it, and what can it reach? Most teams have not yet extended their review process this far.

 

 

Where ILLUME Intelligence Can Help

ILLUME Intelligence approaches supply chain risk from three sides. Our Secure SDLC service builds dependency vetting, pipeline hardening, and secrets handling into how your teams build and release. Our Static and Dynamic Code Analysis service tests the code you wrote and the way it uses what you imported. And our AI Supply Chain Security service extends the same scrutiny to models, datasets, and AI tooling. A good first step is a dependency and pipeline review of one critical application, which shows how large the unknown really is.

 

 

The Bottom Line

The weakest link in your software may be a package you never chose, maintained by someone whose account you cannot protect. You cannot review everything by hand, but you can know what you depend on, rank it by risk, slow down unvetted changes, and limit what any one compromise can steal. Start with the inventory. Every other control depends on it.

---

Comments

---

No Comments Found.