public
/
website
5
0
Fork 0
Code Issues 6 Pull Requests 4 Packages Projects Releases Wiki Activity

feat: package managers supply chain blog draft #41

Open
anton wants to merge 7 commits from anton/blog/package-managers into main
pull from: anton/blog/package-managers
merge into: public:main
Conversation 0 Commits 7 Files Changed 2 +76 -63
1 changed files with 76 additions and 63 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit 5bfae12d6e - Show all commits

139
_posts/2025-06-07-package-managers.md
View File

@ -4,32 +4,32 @@ title: Package managers - malware delivery as a service
date: 2025-04-02
---
Open source software 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.
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 open source software, and it's the most
optimal way to develop technologies in a way most equitable and helpful for the
advancement of humanity, the approach most companies take today to ensure
the secure usage of open source software is insufficient.
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 that is not
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 you were to point out the window at a random person walking
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 individuals would say that that it isn't okay. 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 monitor - but we all know this doesn't
address the issue, otherwise supply chain attacks would not be nearly as common.
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 and Spiderman
## SAST, monitoring and Spiderman
![](/assets/base/spiderman-meme.png)
@ -39,26 +39,35 @@ 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 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. SAST will only reliably detect previously found
vulnerabilities, as it is rule based. "Nobody else reviews all their dependencies" -
yes, and that's why the compromises keep happening so frequntly 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.
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/)
occured 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, 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 package managers such as
`npm` and `pypi` result in full system compromise. Both of these package managers
run installation lifecycle scripts, which run under user permissons. Many attacks
rely on this, and simply 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. The other common way that
packages can compromise a target is by modifiying the flow of regularly invoked
functions to perform additional actions or entirely change the expected
behavior of software. Typing "npm malware" or "pypi supply chain attack" will
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
`pypi` 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:
@ -71,44 +80,48 @@ this year so far:
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.
like npm will run the installation lifecycle scripts of each one. Of course this
isn't unique to `npm`, and `pypi`, 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 open ecosystems with contributors from all over the world,
and this means that essentially anyone on this planet can create a package and
upload it to `npm` or `pypi`, amongst other package managers. 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 unexpecting 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 occured
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).
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...
Some of you may be saying "you can't be serious, that's just too much code". If
that's the case, you should likely consider cutting down on how much third party
code is used in your stack. 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 can we meaningfully claim the software is reasonably secure. Today’s
typical 1–2-week audit windows, however, fall dramatically short of the time
required to manually vet millions of lines of code, exposing a fundamental gap
in our security assurance process. If an organization chooses to only use SAST
and monitoring solutions, it should not be surprised when it gets compromised
by a supply chain attack.
"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 takeways to keep in mind:
Here are some high level takeaways to keep in mind:
* Package managers can easily run arbitrary code on a machine, both during
* 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