Discover LinuxSecurity Features
What You Need to Know about Open-Source Software Supply Chain Security

Whenever you buy something, you receive the product of a massive collaboration, not just one company. That shirt started as raw materials at cotton farms that passed through logistics providers to get to manufacturers, who sent it through more trucking companies to land at a retailer. Just as physical products pass through this supply chain, so does software.
Digital resources pass through many hands, introducing the risk of supply chain attacks. In these incidents, cybercriminals target one of the organizations in the software supply chain to affect all the people downstream. Here’s a closer look at supply chain security threats, how to address them, and the critical role open-source software plays in supply chain security.
What Is Supply Chain Security and Why Is It Important?
As the name suggests, supply chain security secures the software supply chain from cyber threats. That means addressing vulnerabilities at every stage of the development process to stop weaknesses in one organization or step from affecting another.
This security is crucial because supply chains are often vulnerable. With so many parties involved, there are many chances for cyber criminals to find and target vulnerabilities. These attacks are also damaging because targeting just one supply chain party can affect hundreds or thousands of end-users.
Open-source software plays a vital role in stopping these threats. Many programs today build on open-source tools, which involve contributions from various developers and users. That can introduce more vulnerabilities to address and offer more opportunities to find and secure these risks before a cybercriminal does.
Supply Chain Security Threats to Be Aware Of
You must first understand the software supply chain to improve supply chain security. Vulnerabilities can arise at each point in the supply chain, so security starts with recognizing these risks.
Developer Practices
A software’s initial developers are the first link in the supply chain, where the first risks arise. Because this phase lays the groundwork for the entire project, how these developers approach their work has a massive impact on security.
The reality is that even experienced developers can make mistakes. That may be a scary prospect, but it also means threats in this phase often arise from simple failure to adhere to best practices. These practices include:
- Using multifactor authentication on developer accounts.
- Having a formal change-tracking process.
- Giving each release a unique identifier.
- Testing for bugs and unexpected behavior throughout the development cycle.
- Documenting and managing a project’s dependencies.
- Cryptographically signing a project’s integrity.
- Tracking and addressing vulnerabilities in open-source tools used in development.
Developers may skim past or not remember these practices for many reasons, from distraction to time pressure. As simple as they are to overlook, doing so can leave severe risks in the software supply chain.
Repositories
The next phase in the software supply chain is a repository — a server that hosts publicly available software packages. A repository is where developers place their open-source code for others to use, which is a relatively new practice. It used to be that most app development used in-house or licensed code, but the Linux Foundation reports that now 70%–90% of software solutions use open-source resources.
Because these repositories are so large, managing them can lead to security oversights. Code in them may lack notes or dependencies, creating future vulnerabilities or misconfigurations. Weak access controls could let cybercriminals inject malicious code into these repositories. It can also be easy to download a software package without a crucial security feature.
Project Dependency Managers
After downloading software from a repository, developers and users often use project dependency managers (PDMs) to manage it. These tools, or package managers, are programs that automate installation, updating, or configuration tasks.
PDMs save a lot of time and money in the software supply chain. However, this convenience also makes it easy to over-apply them. PDMs automate a lot, but they don’t modify the software and can’t check it for reliability issues or other vulnerabilities. As a result, teams may overestimate what these tools can do and miss critical security checks in the process.
Vulnerability Databases
Because modern programs are often the result of dozens to thousands of software packages, it’s almost impossible to keep track of all dependencies and vulnerabilities manually. In light of those risks, developers turn to vulnerability databases like the Common Vulnerabilities and Exposures program and the National Vulnerability Database program.
These databases contain common vulnerabilities in open-source software and processes for finding and addressing them. However, this phase in the supply chain can introduce risks of its own. These databases need help to keep up with the rapidly changing world of cybercrime, so their records may need to be completed or made more accurate. Consequently, teams relying on them may need to comprehend their vulnerability landscape.
End-User Practices
The final step in the supply chain is using the software. Just as you can crash a car you’ve bought to no fault of the manufacturer, software end-users can find or introduce new vulnerabilities as they use a program.
User error at least plays a role in most security incidents. However, if damaging user errors are manageable, you could argue that it’s a design flaw and that developers should make it harder to mess up.
In open-source software supply chains, end-users can also be crucial in addressing vulnerabilities. They can discover flaws and report them to developers so they can patch them and update notes in repositories, creating a cycle of supply chain security improvements.
Supply Chain Vulnerabilities in Open Source
While open-source software offers the security advantage of having multiple contributors to find vulnerabilities, it also introduces some unique risks. Most notably, malicious code has more chances to enter the supply chain because so many people can contribute to repositories. Because open-source tools spread so widely, an attack on one storage or database could affect many parties down the line.
In one instance in 2021, an attacker compromised an open-source scripting language server to push two malicious updates in the repository. Later that same year, an attacker inserted password-stealing malware into two packages for a popular open-source PDM. One of these packages saw 14 million weekly downloads, so this one attack could’ve affected tens of millions of projects.
Statista reports that in 2022, there was a 742 percent year-over-year increase in open-source software (OSS) supply chain attacks aimed at exploiting any weaknesses in upstream open-source ecosystems, such as JavaScript, Java, . NET, and Python. In the previous year, the figure was 650 percent. This growth is easy to understand, as a single open-source supply chain attack can have far-reaching consequences, and this software has become an industry standard. These supply chains make ideal targets for cybercriminals looking to inflict significant damage with minimal effort.
Security Concerns for the Open-Source Software Supply Chain and How to Address Them
Many businesses still overlook open-source software security because these vulnerabilities are easy to miss when focusing on internal processes. Teams are concerned about ensuring their workflows and in-house programs are secure, taking attention away from threats earlier in the supply chain, where attacks are far more accessible.
Open-source software’s collaborative nature makes it easy for cybercriminals to insert malicious code in various parts of the supply chain. However, that same collaboration is also the key to better open-source security. The industry should encourage all supply chain parties, from initial developers to end users, to share their findings, discuss vulnerabilities, and collaborate to label and review repositories effectively. That way, the community can benefit from others’ experience and expertise.
Following the NIST’s secure software development framework and engaging in security best practices is also essential. If more teams adopt these principles and standards, the software supply chain will become more standardized, enabling more helpful collaboration.
Supply Chain Security Best Practices
While every development cycle is unique, some best practices apply to every software supply chain. That starts with a risk assessment. Map out your supply chain to see all your dependencies, revealing where vulnerabilities can arise. Once you know where you’re most likely to encounter security issues, you can address them appropriately.
Next, modernize your processes. Outdated technology can create data silos, making it difficult to spot potential issues, creating more room for human error, and taking too long to respond to security alerts efficiently. Modern tools like automation, encryption, data consolidation, and file and access monitoring are crucial to spotting and preventing supply chain threats.
You should also review and update your permissions throughout the supply chain. Most companies should give supply chain partners less access. Restrict permissions throughout the supply chain so everyone can only access what they need, and use strict identification and verification tools to enforce these policies.
Be sure to verify every bit of code before deploying it. Scan everything before using it in the development process. If you find a vulnerability or bit of malicious code, alert others in the open-source community. Proactively hunting threats will ensure others’ oversight doesn’t affect you.
Final Thoughts on Improving Open-Source Software Supply Chain Security
Open-source software is a massive boon to the development cycle, but it makes supply chain risks more of a concern. When you know where and how these threats arise, you can create actionable tactics to stop them. If developers, managers, and end-users work together, open-source software can be just as — if not more secure — than proprietary alternatives.