Understanding software supply chain security

Sometimes, the greatest software security risks facing an organization don’t lie in code written by its own developers. Instead, they take the form of vulnerabilities and other security flaws introduced by third-party code that the organization has incorporated into its applications and CI/CD pipeline. For this reason, properly securing applications requires the ability to manage risks in third-party software components and get ahead of supply chain risks.

Keep reading for a deep dive into software supply chain security, including what it means, why it’s important, and which tools and best practices can help protect your organization’s software supply chains against vulnerabilities and other risks.

What is software supply chain security?

Software supply chain security is the practice of detecting and remediating cybersecurity risks within an organization’s software supply chain, meaning any code that the organization leverages for application development and deployment but does not write itself.

To understand fully what software supply chain security means, let’s step back and discuss the role of third-party software in modern software development. Today, it’s rare for developers to write their full codebase entirely from scratch. Instead, they make use of third-party software components  – such as open source libraries, modules, and packages – to help implement the functionality they are building and satisfy application dependencies. 

From an efficiency standpoint, the practice of leveraging pre-written code from external sources is valuable. It saves developers time because they no longer have to reinvent the wheel for every requirement. And it’s not only the work involved in writing that code, but maintaining and building new features as well. Indeed, given the hundreds of thousands of open source code repositories that are publicly available, it’s no surprise that 90 percent of Fortune 500 businesses rely on third-party open source code to help power their software development operations.

However, from a security standpoint, borrowing code from external sources means that any security flaws within that code will impact organizations that use the code. Software supply chain security best practices help mitigate this risk, ensuring that businesses can use third-party software without allowing it to become a weak link in their environment.

Common software supply chain risks

Third-party software is not inherently less secure than code that in-house developers write for a business. Code can be subject to vulnerabilities and other risks whether it’s developed internally or externally.

That said, the third-party code that forms a business’s software supply chain does pose special risks in the sense that because the organization doesn’t have control over the code’s development, meaning that no individual organization can enforce their security standards and controls over that code to mitigate risks.

Additionally, threat actors can carry out attacks by targeting software supply chains, which offer an efficient means of breaching the IT estates of multiple organizations that use vulnerable third-party code – as opposed to finding a flaw in the code written and used by just one organization.

For these reasons, software supply chains are often subject to the following risks:

• Known vulnerabilities: Third-party libraries, modules, and other software components may contain code that is known to be vulnerable to attack. In most cases, known vulnerabilities are recorded in CVE databases, such as the National Vulnerability Database (NVD).

• Unknown vulnerabilities: Third-party code may also be subject to vulnerabilities that have been discovered by threat actors but have not been publicized (i.e., zero day threats). These unknown vulnerabilities are especially threatening because organizations often don’t learn about them until threat actors have already exploited them. Because third-party code is often open source and publicly viewable, it can be easier for attackers to discover flaws in it than it would be for them to find previously unknown vulnerabilities in a company’s internal code.

• Compromised code: In some cases, attackers can infiltrate the open source projects or codebases that businesses include within their software supply chains, and then inject malicious code into them. This is an especially prevalent risk for open source projects that lack active maintainers or stringent code review processes.

• Dependency confusion: Dependency confusion is a technique in which threat actors distribute a malicious version of a software component that is designed to look like a legitimate one. The goal is to “trick” organizations that depend on third-party components into downloading and using the vulnerable component instead of the “real” one.

• Package hallucination: Package hallucination, a new twist on dependency confusion attacks, involves distributing malicious packages whose names match those of dependencies that are “hallucinated” when AI models generate code. Developers who rely on AI-assisted coding tools without carefully reviewing their code may find that the code causes applications to import dependencies that don’t exist in legitimate form, but do exist in the form of malicious packages published by threat actors.

The importance of securing the software supply chain

Managing software supply chain risks like those described above is important because, again, any risk that originates within a supply chain can lead to a breach, just as vulnerable internal code could open the door to an attack.

Indeed, in some respects, securing the supply chain is even more important than managing internal code security (although that’s critical, too). As we mentioned, targeting supply chains is an especially efficient way for threat actors to carry out attacks because finding (or injecting) and exploiting just one vulnerability within a software component that is used by multiple organizations provides a means of breaching all of those organizations. In this sense, supply chain attacks offer high ROI from the perspective of threat actors who are seeking to infiltrate as many businesses as possible with as little effort as possible.

Given this, it’s no surprise that software supply chain attacks have surged by triple-digit rates in recent years. The SolarWinds and Log4J software supply chain attacks of the early 2020s – which garnered many headlines and placed software supply chain security onto many companies’ radars for the first time – were merely some of the first notable incidents in what has snowballed into a widespread security risk for organizations of all types.

Best practices for mitigating software supply chain risks

Because software supply chain risks come in multiple forms, there is no single best practice that can mitigate all of them. Instead, securing the software supply chain hinges on adopting a multi-pronged approach based on the following practices and solutions:

SBOM Generation

A Software Bill of Materials, or SBOM, is a comprehensive inventory of the software components that exist within an application, including details such as where they originated and their version numbers. With this information, teams can quickly determine whether any third-party software components within their applications are subject to known vulnerabilities.

While it’s possible to generate an SBOM after developing an application or on a one-off basis, a best practice is to create an SBOM automatically during the development process as a part of your CI/CD process. Any code borrowed from third parties should be attested within an SBOM to guarantee comprehensive, real-time visibility into the software supply chain.

Code Signing

Code signing is a process that generates a digital attestation of the origins of software. By generating code signatures using tools like those available from Sigstore, developers can verify that third-party code they use actually originated where they believe it originated.

In this way, code signing helps to mitigate the risk of dependency confusion attacks. If the code signature of a module or package doesn’t match the signature published by legitimate developers, it’s a sign that the code has been tampered with and may be insecure (this is why Chainguard signs its artifacts with Sigstore to guarantee their authenticity).

Software Source Governance

Organizations can reduce their risk of supply chain security problems by establishing clear governance rules about which third-party sources their developers may use. For example, they could create governance policies that prevent the use of open source code from repositories that are not actively maintained or that have historically experienced a high rate of security vulnerabilities.

Software Scanning

Scanning software applications and their dependencies can identify certain types of software supply chain risks. The most important type of scan in this regard is known as Software Composition Analysis, or SCA. SCA tools automatically analyze application source code and/or binaries to check for third-party components, and then flag any components known to be vulnerable.

SCA scans alone can’t identify all types of risks, largely due to the fact that they typically focus only on known packages and other components. However, they are one helpful tool in mitigating software supply chain risks.

Securing the software supply chain with Chainguard

By providing minimal, zero-CVE versions of popular open-source software components with an SLA for remediation, Chainguard helps organizations harden their software supply chains and start building from a secure base. With Chainguard, you can be confident that the third-party code your developers incorporate into their applications is safe – which means you can take full advantage of the benefits of open source software to accelerate software development without compromising security and compliance.

Read about our Chainguard Containers product to learn more.