Open source software runs on a simple promise: anyone can read the code, so anyone can check what it does. That promise sits at the heart of open security for democratic societies. A supply chain attack flips that promise against the people who rely on it. Instead of going after your laptop or your phone directly, an attacker compromises a library, a build tool, an update server, or a maintainer account you already trust. When you install or update software, the malicious code rides along inside something that looks completely legitimate. For journalists, activists, small-business owners, and non-technical professionals, this is not a thought experiment. It is a real threat to sources, client data, and the tools you use every day.
Supply chain attacks are not new, but they have become more frequent and more deliberate. The 2020 SolarWinds compromise showed how a single poisoned update could reach thousands of organizations, including government agencies. The 2021 Codecov breach exposed how a modified uploader script could leak credentials from software testing environments. The 2024 XZ Utils backdoor attempt showed how a determined attacker could spend years building trust in a widely used compression library before slipping in a hidden backdoor. In each case, the attack did not require breaking encryption or finding a zero-day in the target’s own code. It only required the target to keep trusting a supplier that had already been compromised.
This article explains how supply chain attacks exploit trust in open source, what makes them hard to spot, and what you can do to reduce your exposure without abandoning the open source tools you depend on. The point is not to make you afraid of open source. The point is to help you verify what you can, watch what you cannot, and make informed decisions about the software you use.
What Is a Supply Chain Attack?
A supply chain attack is any attack that compromises a product or service by targeting a less secure element in its supply network. In software, that usually means a third-party component: a code library, a package manager, a build script, a container image, a browser extension, or an update mechanism. The attacker does not need to break into your computer. They only need to break into one of the many suppliers you already trust.
Open source is especially attractive for supply chain attacks because it is built on a distributed network of maintainers, contributors, and automated build systems. Many open source projects are maintained by volunteers who have limited time and limited security resources. A single maintainer account can control a package that is downloaded millions of times per week. If that account is compromised, the attacker can publish a malicious version that looks exactly like a normal update.
There are several common types of supply chain attacks:
- Dependency confusion: An attacker publishes a malicious package with the same name as a private internal package, hoping that a build system will pull the public version instead of the private one.
- Typosquatting: An attacker publishes a package with a name that is one character away from a popular package, hoping that a developer will mistype the name during installation.
- Maintainer account takeover: An attacker steals the credentials of a package maintainer and publishes a malicious update under the maintainer’s name.
- Build system compromise: An attacker gains access to the servers that build and sign software releases, then injects malicious code into the final binaries.
- Update server compromise: An attacker modifies the files served by an update mechanism, so that users receive malicious code when they check for updates.
For the audience of this blog, the most important point is that none of these attacks require you to do anything wrong. You can download a legitimate package from a legitimate repository, verify its checksum, and still end up with malicious code if the package was already compromised before it reached you.
Why Open Source Trust Is Different
Closed-source software also has supply chains. A proprietary application may include third-party libraries, cloud services, and update mechanisms. But the user of closed-source software has no way to inspect the code, so they must trust the vendor’s word that the software is safe. Open source changes that relationship. The user can inspect the code, but in practice very few people do. The result is a paradox: open source is more transparent, but that transparency does not automatically produce verification.
Most open source users rely on the community to catch problems. That works well for popular projects with many active contributors. It works poorly for small projects with one maintainer and a handful of users. A supply chain attacker looks for the weak points in that community model: abandoned packages, overworked maintainers, automated build pipelines with weak access controls, and users who never check what they are installing.
For journalists and activists, the stakes are higher than for an average consumer. A compromised open source tool could expose a source’s identity, alter a document before publication, or silently record a conversation. A compromised password manager could leak every credential you have. A compromised VPN client could route your traffic through an attacker’s server. The trust you place in open source tools is not just about convenience. It is about the safety of the people who depend on your work.
How Attackers Build Trust Before They Break It
The XZ Utils case is the clearest recent example of how a supply chain attack can be built slowly and deliberately. Starting in 2021, an attacker using the name Jia Tan began contributing to the XZ Utils project, a compression library used by many Linux distributions. Over several years, Jia Tan submitted legitimate patches, built relationships with the maintainer, and eventually gained commit access. In 2024, Jia Tan inserted a backdoor into the build process that would have allowed remote code execution on systems using certain versions of the library. The backdoor was discovered only by accident, when a Microsoft engineer noticed that SSH logins were taking longer than expected.
This pattern matters because it shows that supply chain attackers are willing to invest years in building trust. They do not always rely on stolen credentials or a single malicious commit. They may become a trusted contributor, a helpful maintainer, or a reliable package publisher. By the time they act, their malicious code is hidden inside a project that the community has already accepted.
Other attacks are faster and less subtle. In 2018, the event-stream package on npm was compromised when its maintainer handed control to a new contributor who then added malicious code targeting a specific cryptocurrency wallet. The package had millions of weekly downloads, and the malicious code was active for weeks before it was discovered. In 2021, the ua-parser-js package was compromised when an attacker published malicious versions that attempted to install cryptocurrency miners and steal credentials. These attacks show that even a single compromised package can have a wide blast radius.
What Makes Supply Chain Attacks Hard to Detect
Supply chain attacks are hard to detect for several reasons. First, the malicious code is often hidden inside a legitimate package, so it looks like a normal update. Second, the code may be designed to activate only under specific conditions, such as a particular operating system, a particular build environment, or a particular target. Third, the attack may be spread across multiple components, so no single file looks suspicious on its own. Fourth, the tools that developers use to verify packages, such as checksums and signatures, only verify that the package came from the expected source. They do not verify that the source itself is trustworthy.
For non-technical users, the problem is even harder. You may not know which open source packages are inside the applications you use. You may not know how to check a package’s history, its maintainers, or its build process. You may not have the time to audit every update. The result is that supply chain attacks often go unnoticed until someone with deep technical knowledge happens to spot an anomaly.
This is not a reason to give up on open source. It is a reason to be more deliberate about which open source tools you trust, how you update them, and how you monitor them for changes.
Practical Steps for Journalists, Activists, and Small-Business Owners
You do not need to become a security researcher to reduce your exposure to supply chain attacks. You need a few consistent habits and a willingness to ask questions about the software you use.
1. Reduce the Number of Tools You Depend On
Every additional tool is another supply chain. If you use a password manager, a VPN, an encrypted messaging app, a document editor, a cloud storage service, and a browser extension, you are trusting at least six different supply chains. Some of those tools may be open source, some may be closed source, and some may be a mix. The fewer tools you use, the fewer opportunities an attacker has to compromise your workflow.
This does not mean you should use one tool for everything. It means you should be intentional about which tools you choose and avoid adding new tools without a clear reason. For example, if you already use a password manager that works well, do not switch to a new one just because it has a new feature. Every switch introduces a new supply chain and a new set of risks.
2. Prefer Tools with a Strong Maintenance Record
Open source projects with many active contributors, regular security audits, and a clear process for reporting vulnerabilities are generally safer than projects with one maintainer and no documentation. Look for projects that have been around for several years, that publish security advisories, and that respond quickly to reported issues. A project that has survived multiple security incidents and improved its practices is often a better choice than a new project with no track record.
For example, the Tor Project, Signal, and the Electronic Frontier Foundation’s tools have all been through security reviews and have public processes for handling vulnerabilities. That does not make them immune to supply chain attacks, but it does mean that an attack is more likely to be detected and disclosed quickly.
3. Update Carefully, Not Automatically
Automatic updates are convenient, but they also mean that a compromised update can reach you before anyone has had time to notice. For high-risk users, it is often better to wait a few days after an update is released before installing it. This gives the community time to spot problems and publish warnings. It also gives you time to check whether the update has been discussed in security forums or on the project’s mailing list.
This does not mean you should never update. Outdated software is a security risk of its own. It means you should update on a schedule that gives you time to verify, rather than updating the moment a new version appears.
4. Verify What You Can
If you are comfortable with basic command-line tools, you can verify the checksum of a downloaded file against the checksum published by the project. This confirms that the file you downloaded is the same file the project published. It does not confirm that the project itself is trustworthy, but it does protect you against a compromised download server or a man-in-the-middle attack.
For packages installed through a package manager, you can check the package’s version history, its maintainers, and its dependencies. Many package managers now include tools for checking package integrity and for detecting known vulnerabilities. For example, npm includes npm audit, and Python’s pip includes pip-audit. These tools compare your installed packages against known vulnerability databases and can alert you to packages that have been flagged.
5. Separate High-Risk and Low-Risk Activities
If you are a journalist working with sensitive sources, do not use the same device for social media, personal email, and source communication. A supply chain attack that compromises a browser extension or a social media app could then reach your source files. Use a dedicated device or a dedicated virtual machine for high-risk work, and keep the software on that device to a minimum. This is sometimes called compartmentalization, and it is one of the most effective defenses against supply chain attacks because it limits the blast radius.
For small-business owners, the same principle applies. Do not use the same computer for online banking, customer data, and general web browsing. If a compromised browser extension steals your banking credentials, the damage is contained if your customer data is on a separate device.
6. Monitor for Unexpected Behavior
Supply chain attacks often leave traces. A program may start using more CPU or memory than usual. A login may take longer than expected. A network connection may appear to a server you do not recognize. These small anomalies are easy to ignore, but they can be the first sign of a compromise. If you notice something unusual, do not dismiss it. Check the project’s issue tracker, search for recent security advisories, and consider whether the behavior could be related to a recent update.
For non-technical users, this is the hardest step. You may not know what normal behavior looks like. But you can still notice when a program suddenly asks for a new permission, when a browser extension changes its behavior, or when a device starts running slowly for no obvious reason. These are signals worth investigating.
What the Open Source Community Is Doing
The open source community is not ignoring supply chain attacks. Several initiatives are working to make the ecosystem more resistant to compromise.
The Open Source Security Foundation (OpenSSF) is a cross-industry collaboration that funds security audits, develops best practices, and maintains tools like the Scorecard, which evaluates open source projects on criteria such as code review, branch protection, and dependency updates. The SLSA framework (Supply-chain Levels for Software Artifacts) defines a set of increasing security requirements for build systems, so that users can verify that a package was built from the source code it claims to be built from. The Sigstore project provides free tools for signing and verifying software artifacts, making it easier for maintainers to prove that a package came from them and not from an attacker.
These tools are not a complete solution. They require maintainers to adopt them, and they require users to check the results. But they are a meaningful improvement over the previous state, where a package’s trustworthiness was often based on nothing more than its download count and its age.
For the audience of this blog, the practical takeaway is that you can look for projects that use these tools. A project that publishes a SLSA provenance, signs its releases with Sigstore, and has a good OpenSSF Scorecard is making a public commitment to supply chain security. That commitment is not a guarantee, but it is a signal that the maintainers take the problem seriously.
What to Do If You Suspect a Compromise
If you suspect that a tool you use has been compromised, act quickly but calmly. The first step is to stop using the tool. Disconnect the affected device from the network if possible. Do not log into any accounts from that device until you have assessed the situation.
The second step is to check the project’s official channels. Look for a security advisory, a mailing list post, or a GitHub issue that describes the problem. If the project has a security contact, report what you observed. If the project does not have a security contact, consider reporting the issue to a relevant CERT or to the package repository where the tool is hosted.
The third step is to change any credentials that may have been exposed. If the compromised tool was a password manager, assume that all passwords stored in it are compromised and change them from a clean device. If the compromised tool was a VPN or a messaging app, assume that your traffic or your messages may have been intercepted and adjust your behavior accordingly.
Finally, document what happened. Write down what you observed, when you observed it, and what you did in response. This documentation will help you if you need to report the incident to an employer, a client, or a law enforcement agency. It will also help you spot patterns if the same problem occurs again.
Frequently Asked Questions
How do I know if an open source tool has been compromised?
You may not know immediately. Supply chain attacks are designed to be quiet. But you can watch for signs: unexpected permission requests, unusual network connections, slower performance, or a sudden change in behavior after an update. You can also check the project’s security advisories, issue tracker, and mailing list for reports of compromise. If you are comfortable with command-line tools, you can use package audit tools to check for known vulnerabilities in your installed packages.
Is open source more vulnerable to supply chain attacks than closed source?
Open source is not inherently more vulnerable, but it is attacked more often because it is widely used and because its supply chain is more visible. Closed-source software also has supply chains, but users cannot inspect them, so attacks may go unnoticed for longer. The advantage of open source is that when an attack is discovered, the community can analyze the code, publish a fix, and warn users. The disadvantage is that the same transparency that enables verification also enables attackers to study the code and find weak points.
What is the single most important thing I can do to protect myself?
Reduce the number of tools you depend on and update them carefully. Every tool is a supply chain, and every update is a chance for an attacker to slip in. Use fewer tools, choose tools with a strong maintenance record, wait a few days before installing updates, and separate high-risk activities from low-risk activities. These habits will not make you immune, but they will make you a much harder target.
Can I still trust open source software for sensitive work?
Yes, but trust should be based on evidence, not on the fact that the code is open. Look for projects that have been audited, that publish security advisories, that sign their releases, and that have a clear process for reporting vulnerabilities. Use tools like OpenSSF Scorecard and Sigstore to check a project’s supply chain practices. And remember that no tool is perfectly safe. The goal is to reduce risk, not to eliminate it.
Next Steps for This Blog
This article is the first in a series on open source supply chain security. Future articles will cover how to read a software bill of materials, how to evaluate a project’s maintainer history, and how to set up a minimal verification workflow for non-technical users. If you have questions about a specific tool or a specific incident, send them in. The goal of this blog is to build a practical, verifiable guide to open security for people who cannot rely on closed-source or vendor-controlled solutions.