Every time you run cargo add or pip install , you are taking a leap of faith. You trust that the code you are downloading contains what you expect, comes from who you expect, and does what you expect. These expectations are so fundamental to modern development that we rarely think about them. However, attackers are systematically exploiting each of these assumptions.
In 2024 alone, PyPI and npm removed thousands of malicious packages; multiple high-profile projects had malware injected directly into the build process; and the XZ Utils backdoor nearly made it into millions of Linux systems worldwide.
Dependency scanning only catches known vulnerabilities. It won’t catch when a typosquatted package steals your credentials, when a compromised maintainer publishes malware, or when attackers poison the build pipeline itself. These attacks succeed because they exploit the very trust that makes modern software development possible.
This post breaks down the trust assumptions that make the software supply chain vulnerable, analyzes recent attacks that exploit them, and highlights some of the cutting-edge defenses being built across ecosystems to turn implicit trust into explicit, verifiable guarantees.
Implicit trust
For many developers, the software supply chain begins and ends with the software bill of materials (SBOM) and dependency scanning, which together answer two fundamental questions: what code do you have, and does it contain known vulnerabilities? But understanding what you have is the bare minimum. As sophisticated attacks become more common, you also need to understand where your code comes from and how it gets to you.
You trust that you are installing the package you expect. You assume that running cargo add rustdecimal is safe because rustdecimal is a well-known and widely used library. Or wait, maybe it’s spelled rust_decimal ?
You trust that packages are published by the package maintainers. When a popular package starts shipping with a precompiled binary to save build time, you may decide to trust the package author. However, many registries lack strong verification that publishers are who they claim to be.
You trust that packages are built from the package source code. You may work on a security-conscious team that audits code changes in the public repository before upgrading dependencies. But this is meaningless if the distributed package was built from code that does not appear in the repository.
You trust the maintainers themselves. Ultimately, installing third-party code means trusting package maintainers. It is not practical to audit every line of code you depend on. We assume that the maintainers of well-established and widely adopted packages will not suddenly decide to add malicious code.
... continue reading