Over the years, I’ve talked with a lot of developers and engineering teams—first during my DevSecOps consulting work, then while building SecureStack. Now, as I focus full-time on software supply chain research and red teaming, I’ve noticed several recurring themes in these conversations.
Recently, my friend Peter and I met with a group of engineering leaders, and these same themes surfaced in their questions. That’s when I thought, “This needs to be a blog post.” So, here we are!
3 myths about package-based threats
While I’ll focus on npm today, these insights apply equally to all package ecosystems: Maven, Nuget, RubyGems, Docker Hub, Go.dev, Crates.io, and PyPi. This isn’t just an npm problem.
Myth #1: “SCA tools help me identify malicious packages”
Unfortunately, this isn’t true. Software Composition Analysis (SCA) tools are designed specifically to check for known accidental vulnerabilities. They work by parsing package manifest files (package.json, requirements.txt, mod.sum, etc) into key-value pairs of package names and versions. These tools then check their internal databases or external sources like OSV or deps.dev for known vulnerabilities—typically accidental issues that the authors mistakenly added to the codebase. Some examples are things like prototype pollution, use of older, less secure functions or lack of input sanitization and output encoding. These accidental errors, can end up being used individually or combined to allow bad guys to attack applications.
Contrary to popular belief, SCA tools typically can’t identify purposely malicious packages. It’s not what they’re designed for, though many developers don’t realize this limitation. Here’s a telling example: I recently disclosed several npm-based threats to GitHub and npm. I then waited and monitored how long it took Snyk, Socket, Mend, and other SCA tools to flag that package as malicious. In a similar test, I published dozens of public advisories about malicious npm packages to OSV malicious package advisory. None of the SCA vendors marked these packages as malicious based on the existence of an OSV malicious package advisory.
Most SCA providers only flag malicious packages as bad after npm has removed them from the registry and replaced them with a warning: “This package contained malicious code and was removed from the registry by the npm security team.”
Simply put, these SCA tools lack the built-in capability to detect malware in npm packages. They depend on npm’s actions to identify threats. By the time they flag something, the whole world already knows—so how exactly has your SCA tool helped you?
This is a serious gap as traditional SCA tools help you find accidental vulnerabilities, while ignoring the purposely malicious packages.
Myth #2: “npm packages need to use pre or post-install scripts to be dangerous“
The web3-parser library I recently identified illustrates this perfectly. It avoided installing scripts and took a more strategic approach. It attracted developers by offering to help parse and standardize web3 event functions like transactions. While it did provide this parsing functionality, it secretly transmitted all parsed web3 event data to an attacker-controlled server. Though not the most sophisticated npm threat, its author was smart enough to skip install scripts and provide genuine value, ensuring developers would keep the package installed.
Let’s look at the data…
To verify this, I analyzed the GitHax database, sorting through critical, high, medium, and low severity findings to determine what percentage of alerts involved pre- or post-install scripts.
By sorting the threat campaigns from December and January this way, I was able to see what percentage of them used install scripts.
None of the critical-severity software supply chain threats we tracked in December and January used pre- or post-install scripts. Zero.
Only 16% of the high-severity software supply chain threats from unique threat actors in December or January used pre- or post-install scripts.
56% of medium-severity threats used install scripts. This is even lower than I thought! I expected the medium-severity threats to use install scripts more.
Finally, 87% of low-severity threats used install scripts. This is to be expected as most of the bug bounty and low-skilled exfil-based attacks fall into the “low” severity in GitHax.
Myth #3: “It’s only script kiddies writing these exploits“
I’ve heard this several times in my conversations with engineering teams. The thinking here is that if the threat actor programming skillset is bad, there’s nothing to worry about. There’s a bit of hubris involved here, but historically, many of the software-based threats that developers have seen were not from highly skilled threat actors. Many developers are used to the typo-squatting “noise” and assume that all software package-based threats are equally as simplistic.
The reality, however, is that many software package-based threats I analyze require days of intensive research to identify. This is because threat actors now employ really good programmers and AI to create sophisticated payloads that masterfully hide their intentions.
In my malicious package research, identifying threats is incredibly challenging. While I look for certain “tells” like code obfuscation, exfiltration functions and author reputation, these signals aren’t always reliable. When threat actors invest time in building credible GitHub profiles and social presence, and when their obfuscation techniques appear normal, malicious payloads can slip through. That’s why I created GitHax to automate this analysis—but the fact remains that we’re dealing with professionals who know their shit.
The XZ utils attack perfectly illustrates this point. The authors showed remarkable sophistication in concealing their multi-stage malicious payloads. XZ became a watershed moment precisely because it demonstrated such technical complexity. My friend Thomas Roccia created a beautiful infographic that captures the attack’s intricacy.
The XZ utils attack was truly masterful. Don’t let your developers assume threat actors are just script kiddies. Instead, recognize that many are well-trained professionals who know exactly how to compromise your software supply chain. Starting with this mindset will better prepare you for when threats appear in your code and applications.
Attack sophistication is increasing, quickly
Because I look at malicious packages everyday I’ve noticed several things in particular that scare me:
Crafty use of obfuscation to hide the nature of the attack: Multiple layers of obfuscation, new obfuscation functions, obfuscating non-payload bearing files, and more means you spend a lot of time just trying to decipher if there is a malicious payload or not. Many threat hunters give up and miss these craftier payloads. I know I have. 🙁
Nesting dependencies many package layers deep, so you have to spend hours chasing down these dependency trees to find the one malicious package. Unfortunately, SCA tools can’t help you find these dependencies as these tools can only find existing known vulnerabilities in flagged packages. More nuanced attackers take advantage of this by publishing bigger packages with more “stuff” to hide their payloads in the noise.
Outsourcing Javascript dependencies (and their malicious payloads) to third parties: CDNs, GitHub repos, S3 buckets, etc. This is becoming more common for legitimate and illegitimate packages, and I’ve noticed it is particularly common in crypto projects. The number of Chinese CDNs is HUGE, and how would someone know what’s legit and what’s not? Is anyone in your company watching your packages to see if they call any third parties?
There are probably more than 3 myths, so if you can think of any other myths or misinformation about NPM package-based threats, please hit me up!
If you want to check out my new GitHax threat portal, please visit https://githax.com. If you want access to the threat portal, or a demo, you can email us at https://githax.com/contact.html
Thanks for reading!
