Software Supply Chain Security
In recent years, the mega-trends of application containerization and the rise of open-source software components have accelerated the velocity of software delivery. This evolution, while offering significant benefits, has also introduced complexity and challenges to traditional software supply chain security.
If you’re looking to get a better understanding of how software supply chains operate, where the risks lie, and best practices on how to manage the risks, then keep reading.
An overview of software supply chains
Before you can understand how to secure the software supply chain, it’s important to understand what the software supply chain is in the first place. In short, a software supply chain is all of the individual software components that make up a software application.
Software supply chains are similar to physical supply chains. When you purchase an iPhone, all you see is the finished product. But behind the final product is a complex web of component suppliers that are assembled to produce that iPhone. Displays and camera lenses from a Japanese company, CPUs from Arizona, modems from San Diego, lithium-ion batteries from a Canadian mine; all of these pieces come together in a Shenzhen assembly plant to create a final product that is then shipped straight to your door.
In the same way that an iPhone is made up of a screen, a camera, a CPU, a modem, and a battery, modern applications are composed of individual software components (i.e., dependencies) that are bundled together to create the finished product.
An increasingly complex supply chain
With the rise of open source software, most of these components are open source frameworks, libraries, and operating systems. Specifically, 70-90% of modern applications are built utilizing open source software components.
Before the ascent of open source software, applications were typically developed with proprietary, in-house code without a large and diverse set of software “suppliers.” In this environment, company employees comprised the “supply chain.” The move to Cloud Native and DevSecOps design patterns dramatically sped up the delivery of software, but at the expense of simplicity. Coordinating all of the open source software suppliers significantly increased complexity.
This shift in the way that software is developed impacts essentially all modern software. This means that all businesses and government agencies are waking up to the realization that they are building a software supply chain, whether they want to or not.
One of the ways this new supply chain complexity is being tamed is with the software bill of materials (SBOM). A software bill of materials (SBOM) is a structured list of software components, modules, and libraries that are included in a given piece of software. Similar to the nutrition labels on the back of the foods that you buy, SBOMs are a list of ingredients that go into the software that your applications consume.
What is software supply chain security?
In short, software supply chain security is the practice of identifying and preventing vulnerabilities in third-party components from compromising the applications that rely on them.
Let’s briefly return to our iPhone metaphor. In the same way that an attacker could target one of the iPhone suppliers to modify a component before the iPhone is assembled, a software supply chain threat actor could do the same by targeting an open source package that is then built into a commercial application.
Given the size and prevalence of open source software components in modern applications, the supply chain is only as secure as its weakest link.
Think of your application as a pyramid, and the open source software components as its building blocks. Your application’s supply chain is all of the open source components that your proprietary business logic is built on top of. The catch is that every component you use also has its own pyramid of dependencies. The foundation of your app might look solid, but there is always the potential that if you follow the dependency chain far enough down, you will find a vulnerability that could topple the entire structure.
This gives adversaries their opening. A single compromised package allows attackers to manipulate all of the packages “downstream” of their entry point.
This reality was viscerally felt by the software industry (and all industries that rely on the software industry, meaning all industries) during the Log4j incident.
Common software supply chain risks
Software development is a multifaceted process, encompassing various components and stages. From the initial lines of code to the final deployment in a production environment, each step throughout the software development lifecycle (SDLC) presents potential risks for vulnerabilities to creep in. As organizations increasingly integrate third-party components and open-source libraries into their applications, understanding the risks associated with the software supply chain becomes paramount. This section delves into the common risks that permeate the software supply chain, offering insights into their origins and implications.
Source code
Supply chain risks start with the code itself. Below are the most common risks associated with a software supply chain when generating custom first-party code:
1. Insecure first-party code
Custom code is the first place to be aware of the risk in the supply chain. If the code written by your developers isn’t secure, then your application will be vulnerable at its foundation. Insecure code is any application logic that can be manipulated to perform a function that wasn’t originally intended by the developer.
For example, a developer might write a function that checks whether a username and password match what’s in the user database. But if an attacker can craft a payload that causes the function to delete the entire database instead, that’s a case of insecure code.
2. Source code management (SCM) compromise
Source code is typically stored in a centralized code repository so that all members of your development team can collaborate on the same codebase. An SCM is software that can potentially be vulnerable, in the same way as your first-party code. If an adversary gains access to your SCM — either by exploiting software vulnerabilities, bypassing authentication mechanisms, or using social engineering — they can manipulate your source code at the foundation.
3. Developer environments
Developer environments are powerful productivity tools for your engineers, but they are another potential source of risk for an organization. Most integrated developer environments come with a plug-in system so that developers can customize their workflows for maximum efficiency. These plug-in systems typically also have a marketplace associated with them. In the same way that a malicious Chrome browser plug-in can compromise a user’s laptop, a malicious developer plug-in can gain access to a “trusted” engineer’s development system and piggyback on this trusted access to manipulate the source code of an application.
3rd-party dependencies (open source or otherwise)
Third-party software is really just first-party software written by someone else, the same way that the cloud is just servers run by someone else. Third-party software dependencies are potentially vulnerable to all of the same risks associated with your own first-party code in the above section. But since it isn’t your code, you have to deal with the risks in a different way. Below we lay out the two risks associated with this software supply chain risk:
4. Known vulnerabilities (CVEs, etc)
Known vulnerabilities are insecure or malicious code that have been identified in a third-party dependency. Typically, the maintainer of a third-party dependency will fix their insecure code when they are notified and publish an update. Sometimes, if the vulnerability isn’t a priority, they won’t address it for a long time (if ever). If your developers rely on this dependency for your application, then you have to assume the risk.
5. Unknown vulnerabilities (zero-days)
Unknown vulnerabilities are insecure or malicious code that hasn’t been discovered. These vulnerabilities can lie dormant in a codebase for months, years, or even decades. When they are finally uncovered and announced, there is typically a scramble across the world by any business using software (i.e., almost all businesses) to figure out whether they utilize this dependency and how to protect themselves. Attackers are in a scramble themselves to determine who is using the vulnerable software and crafting exploits to take advantage of businesses that are slow to react. Security teams must act quickly to identify affected systems and apply mitigation measures.
Build pipeline & artifact repository
6. Build pipeline compromise
A software build pipeline is a system that pulls the original source code from an SCM, gathers third-party dependencies from their source repositories, and then builds and optimizes the code into a binary stored in an artifact repository. Like an SCM, it’s made up of both first- and third-party code, so it carries many of the same risks related to source code and software dependencies.
Organizations deal with these risks differently from the developers of the build systems because they do not control this code. Instead, the risks are around managing who has access to the build system, what permissions they have, and what they can do with their access (if you haven’t already, read up on the principle of least privilege). Risks range from modifying where the build system is pulling source code from to modifying the build instructions to inject malicious or vulnerable code into previously secure sources.
7. Artifact registry compromise
An artifact registry is a centralized repository of the fully built applications (typically in the form of a container or container image) that a deployment orchestrator would pull the software from to run in a production environment. It is also software similar to a build pipeline or SCM and has the same associated risks as mentioned before.
Typically, the risks of registries are managed through how trust is managed between the registry and the build system or any other system/person that has access to it. Risks range from an attacker poisoning the registry with an untrusted container or an attacker gaining privileged access to the repository and modifying a container in place.
Production
8. Deployment orchestrator compromises
A deployment orchestrator is a system that pulls pre-built software binaries and runs the applications on servers. It is another type of software system similar to a build pipeline or SCM and has the same associated risks as mentioned before.
Typically, the risks of orchestrators are managed through trust relationships between the orchestrator and the artifact registry or any other system/person that has access to it. Risks range from an attacker manipulating the orchestrator into deploying an untrusted container or an attacker gaining privileged access to the orchestrator and modifying a running container or manifest.
9. Production environment compromise
The production environment is the application running on a server that was deployed by an orchestrator. It is the software system built from the original source code that fulfills users’ requests. It is the final product that is created from the software supply chain. The risks associated with this system are different from most other systems because it typically serves users outside of the organization and has different risks associated with it, because not as much is known about external users as internal users. Runtime monitoring is critical to detect threats that bypass earlier SDLC phases.
Examples of software supply chain attacks
As reliance on third-party components and open-source libraries grows, so does the potential for vulnerabilities in the software supply chain. Several notable incidents have exposed these risks, emphasizing the need for proactive security and a deep understanding of software dependencies. In this section, we explore significant software supply chain attacks and the lessons they impart.
SolarWinds (2020)
In one of the most sophisticated supply chain attacks, malicious actors compromised the update mechanism of SolarWinds’ Orion software. This breach allowed the attackers to distribute malware to approximately 18,000 customers. The attack had far-reaching consequences, affecting numerous government agencies, private companies, and critical infrastructure.
Lessons Learned: The SolarWinds attack underscored the importance of securing software update mechanisms and highlighted the need for continuous monitoring and validation of software components.
Log4j (2021)
In late 2021, a critical vulnerability was discovered in the Log4j logging library, a widely used Java-based logging utility. Dubbed “Log4Shell,” this vulnerability allowed attackers to execute arbitrary code remotely, potentially gaining full control over vulnerable systems. Given the ubiquity of Log4j in various software applications, the potential impact was massive, prompting organizations worldwide to scramble for patches and mitigation strategies.
Lessons Learned: The Log4j incident underscored the risks associated with ubiquitous open-source components. It highlighted the importance of proactive vulnerability management, rapid response to emerging threats, and the need for organizations to maintain an updated inventory of third-party components in their software stack.
NotPetya (2017)
Originating from a compromised software update mechanism of Ukrainian accounting software, NotPetya spread rapidly across the globe with disastrous consequences. Masquerading as ransomware, its primary intent was data destruction. Major corporations, including Maersk, FedEx, and Merck, faced disruptions, leading to financial losses amounting to billions.
Lessons Learned: NotPetya highlighted the dangers of nation-state cyber warfare and the need for robust cybersecurity measures, even in seemingly unrelated software components.
Node.js Packages coa and rc
In July 2021, two widely used npm packages, coa and rc, were compromised. Malicious versions of these packages were published to the npm registry, attempting to run a script to access sensitive information from users’ .npmrc files. The compromised versions were downloaded thousands of times before being identified and removed.
Lessons Learned: This incident emphasized the vulnerabilities in open-source repositories and the importance of continuous monitoring of dependencies. It also highlighted the need for developers and organizations to verify the integrity of packages before installation and to be wary of unexpected package updates.
JuiceStealer Malware
JuiceStealer is a malware spread through a technique known as typosquatting on the PyPI (Python Package Index). Malicious packages were seeded on PyPI, intending to infect users with the JuiceStealer malware, designed to steal sensitive browser data. The attack involved a complex chain, including phishing emails to PyPI developers.
Lessons Learned: JuiceStealer showcased the risks of typosquatting in package repositories and the importance of verifying package names and sources. It also underscored the need for repository maintainers to have robust security measures in place to detect and remove malicious packages promptly.
Node.js Packages colors and faker
In January 2022, the developer behind popular npm libraries colors and faker intentionally sabotaged both packages in an act of “protestware.” This move affected thousands of applications, leading to broken builds and potential security risks. The compromised versions were swiftly removed from the npm registry.
Lessons Learned: This incident highlighted the potential security issues associated with relying heavily on open-source libraries and the actions of individual developers. It underscored the importance of diversifying dependencies, having backup plans, and the need for the open-source community to address developer grievances constructively.
Trends in software supply chain security
Each year, Anchore releases our annual Software Supply Chain Security Report. Our latest edition found that 40% of organizations reported software supply chain attacks in the previous 12 months, down from the 62% of respondents reporting attacks in 2022 in the wake of SolarWinds. This positive trend could be a result of increased focus on risks in the software supply chain—the study also found a 200% increase in organizations making software supply chain security a top priority from 2023 to 2024.
For an update on 2025 trends and beyond, follow Anchore on LinkedIn.
Standards and best practices for preventing attacks
There are a number of different initiatives to define best practices for software supply chain security. Organizations ranging from the National Institute of Standards and Technology (NIST) to the Cloud Native Computing Foundation (CNCF) to Open Source Security Foundation (OpenSSF) have created fantastically detailed documentation on their recommendations to achieve an optimally secure supply chain.
Choosing any of the standards defined is better than choosing none or even cherry-picking from each of the standards to create a program that is best tailored to the risk profile of your organization. If you’d prefer to stick to one for simplicity’s sake and need some help deciding, Anchore has detailed our thoughts on the pros and cons of each software supply chain standard here.
Below is a concise summary of each of the major standards to help get you started:
National Institute of Standards and Technology (NIST)
NIST has a few different standards that are worth noting. We’ve ordered them from the broadest to the most specific and, coincidentally, chronologically, as well.
NIST SP 800-53, “Security and Privacy Controls for Information Systems and Organizations”
NIST 800-53, aka the Control Catalog, is the granddaddy of NIST security standards. It has had a long life and evolved alongside the security landscape. Typically paired with NIST 800-37, the Risk Management Framework or RMF, this pair of standards creates a one-two punch that not only produces a highly secure environment for protecting classified and confidential information but sets up organizations to more easily achieve federal compliance standards like FedRAMP.
Software supply chain security (SSCS) topics first began filtering into NIST 800-53 in 2013, but it wasn’t until 2020 that the Control Catalog was updated to break out software supply chain security into its own section. If your goal is to get up and running with software supply chain security as quickly as possible, this standard will be overkill. If your goal is to build toward NIST 800-53 and FedRAMP compliance as well as build a secure software development process, then this standard is for you. If you’re looking for something more specific, consider one of the next two standards.
If you need a comprehensive guide to NIST 800-53 or its spiritual sibling, NIST 800-37, we have put together both. You can find a detailed but comprehensible guide to the Control Catalog here and the same plain english, deep-dive into NIST 800-37 here.
NIST SP 800-161, “Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations”
NIST 800-161 is an interesting application of both the RMF and the Control Catalog for supply chain security, specifically. The controls in NIST 800-161 take the base controls from NIST 800-53 and provide guidance on how to achieve more specific outcomes for the controls. For the framework, NIST 800-161 takes the generic RMF and creates a version that is tailored to software supply chain security.
NIST 800-161 is a comprehensive standard that will guide your organization to create a development process with its primary output being highly secure software and systems.
NIST SP 800-218, “Secure Software Development Framework (SSDF)”
NIST 800-218, the SSDF, is an even more refined standard than NIST 800-161. The SSDF targets the software developer as the audience and gives even more tailored recommendations on how to create secure software systems.
If you’re a developer attempting to build secure software that complies with all of these standards, we have an ongoing blog series that breaks down the individual controls that are part of the SSDF.
NIST SP 800-204D, “Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines”
Focused specifically on Cloud-native architectures and Continuous Integration/Continuous Delivery (CI/CD) pipelines, NIST 800-204D is a significantly more specific standard than any of the previous standards. That being said, if the primary insertion point for software supply chain security in your organization is via the DevOps team, then this standard will have the greatest impact on your overall software supply chain security.
Also, it is important to note that this standard is still a draft and will likely change as it is finalized.
Open Source Security Foundation (OpenSSF)
A project of the Linux Foundation, the Open Source Security Foundation is a cross-industry organization that focuses on the security of the open source ecosystem. Since most 3rd-party dependencies are open source, they carry a lot of weight in the software supply chain security domain.
Supply-chain Levels for Software Artifacts (SLSA)
If an SBOM is an ingredients label for a product, then the SLSA (pronounced ‘salsa’) is the food safety handling guidelines of the factory where they are produced. It focuses primarily on updating traditional DevOps workflows with signed attestations around the quality of the software that is produced.
Google originally donated the framework and has been using an internal version of SLSA since 2013, which it requires for all of its production workloads.
You can view the entire framework on its dedicated website here
Secure Supply Chain Consumption Framework (S2C2F)
The S2C2F is similar to SLSA but much broader in its scope. It gives recommendations around the security of the entire software supply chain using traditional security practices such as scanning containers for for vulnerabilities. It touches on signed attestations but not at the same level of depth as the SLSA.
The S2C2F was built and donated by Microsoft, where it has been used and refined internally since 2019.
You can view the entire list of recommendations on its GitHub repository.
Cloud Native Computing Foundation (CNCF)
The CNCF is also a project of the Linux Foundation but is focused on the entire ecosystem of open-source, cloud-native software. The Security Technical Advisory Group at the CNCF has a vested interest in supply chain security because the majority of the software that is incubated and matured at the CNCF is part of the software development lifecycle.
Software Supply Chain Best Practices White Paper
The Security Technical Advisory Group at CNCF created a best practices white paper that was heralded as a huge step forward for the security of software supply chains. The document creation was led by the CTO of Docker and the Chief Open Source Officer at Isovalent. It captures over 50 recommended practices to secure the software supply chain.
You can view the full document here.
Types of Supply Chain Compromise
This document isn’t a standard or best practices, instead it is support for the best practices white paper that defines a full list of supply chain compromises.
Catalog of Supply Chain Compromises
This isn’t a standard or best practices document, as well. It is instead a detailed history of the significant supply chain breaches that have occurred over the years. Helpful for understanding this history that informed the best practices detailed in the accompanying white paper.
For help managing and maintaining best practices, consider adopting a software supply chain management platform.
How Anchore can help
Anchore is a leading software supply chain security company that has built a modern, SBOM-powered software composition analysis (SCA) platform that helps organizations incorporate many of the software supply chain best practices that are defined in the above guides.
It was founded on the belief that the legacy security solutions of the monolith era could be rebuilt to deliver on the promises of speed without sacrificing security. Anchore is trusted by Fortune 100 companies and the most exacting federal agencies across the globe because it has delivered on this promise.
As we have learned working with both large enterprises and federal agencies, including the Department of Defense, an organization’s supply chain security can only be as good as the depth of the data on their supply chain and the automation of processing the raw data into actionable insights. Anchore Enterprise provides an end-to-end software supply chain security system with total visibility, deep inspection, automated enforcement, expedited remediation and trusted reporting to deliver actionable insights to improve your overall security posture.
If you’d like to learn more about the Anchore Enterprise platform or speak with a member of our team, feel free to book a time to speak with one of our specialists.
