feat: package managers supply chain blog draft

_posts/2025-06-07-package-managers.md

@@ -0,0 +1,120 @@
+---
+layout: post
+title: Package Managers - How To Install Malware On Your Systems
+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.
+
+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.
+
+## 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
+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
+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) - but we all know this doesn't address the
+issue, otherwise supply chain attacks would not be nearly as common.
+
+## SAST 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 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.
+
+## 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 if 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 suppl chain attack" 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)
+
+## 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 performed an attack to illustrate how easy it can be to compromise a library
+by [purchasing a domain which allowed him to 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).
+
+## 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 just use SAST,
+it should not be surprised when it gets compromised by a supply chain attack.
+
+## Summary
+
+Here are some high level takeways to keep in mind:
+
+* Package managers 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 is a feel good 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 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.
+
+