diff --git a/_posts/2025-06-07-package-managers.md b/_posts/2025-06-07-package-managers.md
new file mode 100644
index 0000000..278c804
--- /dev/null
+++ b/_posts/2025-06-07-package-managers.md
@@ -0,0 +1,142 @@
+---
+layout: post
+title: Package managers - malware delivery as a service
+date: 2025-04-02
+---
+
+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/)
+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 (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.
+
+
diff --git a/assets/base/spiderman-meme.png b/assets/base/spiderman-meme.png
new file mode 100644
index 0000000..9dd04a5
Binary files /dev/null and b/assets/base/spiderman-meme.png differ