---
layout: post
title: Package managers - malware delivery as a service
date: 2025-06-07
---

Using third-party code, such as open source libraries has made it much easier to
rapidly develop software as it allows the reuse of code to solve particular
problems. There is no need to write the same software from scratch over and over
again - and in some cases, such as when implementing cryptographic libraries,
the likelihood an implementation error is made are high - making open source
software the obvious choice.

While it does make sense to use third party code the approach most companies
take today to ensure its secure usage is insufficient.

## The "Industry Standard"

While most responsible companies have policies around reviewing first party
code from their developers, there is a widely held belief that the same is not
necessary for third party dependencies. The confusing part about this is that
in most cases, if someone was to point out the window at a random person walking
by and ask if it would be okay for that individual to make changes to a codebase
without revision, most would say that it isn't. When the same question arises
about whether it's okay for millions of lines of code by hundreds or even
thousands of developers from around the globe to introduce changes to a
codebase, most companies shrug and say that they use Static Application Security
Testing (SAST) and monitoring - but we all intuitively know this doesn't
reasonably mitigate the associated risks, otherwise supply chain attacks would
not be nearly as common.

## SAST, monitoring and Spiderman

![](/assets/base/spiderman-meme.png)

The industry participants point to each other for examples of how things are
meant to be done. The problem is that not all companies have the same risk
exposure. For some companies, they may tolerate attacks because they don't have
assets that are as valuable as other's. A great example of this are companies
handling digital assets. If a tech stack has the ability to move digital assets,
or handles otherwise valuable data, different security measures are required.
Using SAST and monitoring, and claiming it's a complete security control for
supply chain risks is akin to putting a security guard at the front door of the
building while the backdoor is unguarded and wide open. SAST and monitoring
will only reliably detect previously found vulnerabilities, as they are
typically rule or behaviour based, and can often be circumvented because the
attackers design their attacks to evade detection. The [SolarWinds attack](http://web.archive.org/web/20250226000211/https://www.wired.com/story/the-untold-story-of-solarwinds-the-boldest-supply-chain-hack-ever/)
occurred despite sophisticated monitoring and SAST systems at one of the leading
cybersecurity firms in the world. The nature of that compromise is such that
full code review likely wouldn't have prevented the attack, reproducible builds
would have (more on that another time), but the point is that there is an
over-reliance on monitoring. "Nobody else reviews all their dependencies" - yes,
and that's why the compromises keep happening so frequently and why attackers
spend so much energy on this attack vector. According to a study by
[ReversingLabs](https://web.archive.org/web/20240806233532/https://3375217.fs1.hubspotusercontent-na1.net/hubfs/3375217/Documents/The-State-of-Software-Supply-Chain-Security-2024.pdf), there has been a 1300% increase
in the number of threats in software packages between 2020 and 2023 alone.

## Getting Pwned via Package Managers

There is nothing sophisticated or mysterious about how introducing non-vetted
code into an application results in compromise. If a function is imported and
used, its entire call stack comes along with it - which could be hiding
undesirable behavior. It gets worse because package managers such as `npm` and
`pip` can often result in full system compromise during the installation step,
before even running any application code. Both of these package managers run
installation life-cycle scripts, which are executed with user permissions. Many
attacks rely on this, and leverage these scripts to run arbitrary code on the
user's machine when they install a given package. Unfortunately because
privilege escalation attacks are often fairly simple to do, the risk is
exacerbated.Typing "npm malware", "pypi supply chain attack" or similar will
yield seemingly endless results but here are some "fun" highlights just from
this year so far:

* March 26 2025: "These were simple downloaders whose malicious payload was cleverly hidden, with a second stage that “patches” the legitimate npm package ethers, installed locally, with a new file containing the malicious payload. That patched file ultimately serves a reverse shell." [ref](https://web.archive.org/web/20250118001432/https://www.reversinglabs.com/blog/a-lurking-npm-package-makes-the-case-for-open-source-health-checks)

* April 1 2025: "... the official XPRL (Ripple) NPM package was compromised by sophisticated attackers who put in a backdoor to steal cryptocurrency private keys and gain access to cryptocurrency wallets" [ref](https://web.archive.org/web/20250423022218/https://www.aikido.dev/blog/xrp-supplychain-attack-official-npm-package-infected-with-crypto-stealing-backdoor)

* June 5 2025: "One collection of PyPI packages is designed to "monkey patch" Solana key-generation methods by modifying relevant functions at runtime without making any changes to the original source code." [ref](https://web.archive.org/web/20250605205948/https://thehackernews.com/2025/06/malicious-pypi-npm-and-ruby-packages.html)

So next time when installing a package, consider what is being installed. The
issue is that it's usually not just the top level dependency that will end up
being installed - there are often many sub-dependencies, and package managers
like npm will run the installation lifecycle scripts of each one. Of course this
isn't unique to `npm`, and `pip`, they are just highlighted as some they are
widely used, but this applies to package managers and third party code in
general.

## Who Wrote The Code?

Package managers are part of open ecosystems with contributors from all over the
world, and this means that essentially anyone on this planet can write software,
and offer it as a package. Some of these individuals happen to be threat actors,
whether individuals, or state funded actors. In fact, in some cases attackers
will purchase a library or use an expired domain to take over a library that is
already widely used, to attack its unassuming users, as was the case in the
[attack via the `event-stream` package](https://web.archive.org/web/20250418194828/https://www.techtarget.com/searchsecurity/news/252453398/Compromised-NPM-package-highlights-open-source-trouble) in 2018, but many
similar attacks have occurred since ([ref 1](https://web.archive.org/web/20250418194828/https://www.techtarget.com/searchsecurity/news/252453398/Compromised-NPM-package-highlights-open-source-trouble)). Our co-founder
and security engineer Lance Vick showed that an attack could be performed to
illustrate how easy it can be to compromise a library by [purchasing a domain which could allow control the
`foreach` npm package](https://web.archive.org/web/20250418194828/https://www.techtarget.com/searchsecurity/news/252453398/Compromised-NPM-package-highlights-open-source-trouble). Just because something is widely used
it doesn't mean it's sufficiently reviewed and secure.

## Review All The Code...

"All the code? That's just too much code to review". If that's the case,
consider cutting down  on how much third party code is used in the stack. Look
for opportunities to  remove libraries which are not necessary, libraries which
duplicate  functionality, huge libraries where only a small subset of them is
used etc. To reasonably secure a system, at the least, one should know what
software is running in it. Rather than relying on the absence of a discovered
exploit to certify an application’s security, organizations should mandate a
comprehensive  audit of every single line of code—both their own and in every
supply-chain dependency. Only once this exhaustive review is complete is it
possible to meaningfully claim the supply chains is reasonably secure. Of course,
even a full audit of code may not surface all code issues and there are other
risks stemming, for example, from the way the code is built, or the runtime
environment. The idea is to layer all defense mechanisms available, but admit
that not reviewing third party code is a bad idea and that this needs to change.

## Summary

Here are some high level takeaways to keep in mind:

* Third party code can easily run arbitrary code on a machine, both during
installation and during runtime resulting in complete compromise.

* Not reviewing every line of code manually will inevitably lead to compromise
given a long enough time horizon.

* SAST/monitoring is a partial measure that is not sufficient for ensuring
code security.

* If it can be done with the standard language library, avoid adding
dependencies.

* Evaluate cost of using third party libraries based on how much it costs to
review them rather than assigning them cost of $0 as though they are free to use.

* Consider donating to maintainers of your most important third party
dependencies, both for development, and to pay for security assessments.
