How to Prevent Software Supply Chain Attacks

One of the greatest security threats to organizations today isn’t the software they develop themselves, but rather software that is supplied to them by third parties. That software could be open source libraries, modules or other dependencies that developers integrate into their codebase. It may also take the form of commercial software purchased from third-party vendors.

Either way, risks in third-party components can translate into risks for the businesses that depend on them. Organizations that focus security strategies only on securing the code and systems that they develop in-house, while blindly trusting resources obtained from third parties, are at high risk of breaches that originate from external sources.

Visualizing supply chain attacks.

Indeed, although software supply chain risks have existed for years, major supply chain attacks in 2021 involving vendors like SolarWinds and Kaseya have underscored the paramount importance of identifying and addressing supply chain risks. So has the U.S. federal government’s introduction of requirements involving the creation of a Software Bill of Materials (SBOM) for software used by U.S. federal agencies. Although that mandate currently applies only to vendors who do business with the U.S. government, it sets a precedent for supply chain security standards that are likely to be adopted across the software industry.

Based on the state of software supply chain risks, this article offers guidance on steps that businesses can take to defend their supply chains and ensure that “upstream” security vulnerabilities don’t turn into breaches in their own systems.

Best practices for preventing supply chain attacks

No matter what your software supply chain looks like — or whether you use commercial components, open source components or both — the following steps will help you defend against supply chain risks.

Set security standards

A basic best practice for managing software supply chain risks is to define security standards that your suppliers and vendors need to meet. For example, you could adopt a compliance framework based on the NIST secure software development standards or the European Union’s ENISA policies.

By requiring your suppliers to conform with the guidelines set forth in a security standard, you establish a baseline for protecting against software risks that originate from poor coding or design practices in third-party software. Security standards alone won’t prevent supply chain risks, but they are a first step toward mitigating them.

Validate suppliers

Vetting software suppliers from the perspective of security is another basic best practice for mitigating supply chain risks. In addition to considering factors like the cost and functionality of software, make the security of the vendor a top priority when you decide whether to use that vendor’s product.

When validating a software supplier, consider points such as whether the supplier has disclosed security breaches in the past, which steps the supplier takes to mitigate risks in its code and which audit reports are available to demonstrate the supplier’s commitment to security best practices.

Scan your software

No matter how much you trust your software suppliers, you must also scan your software yourself to determine if it contains components known to be vulnerable. You can do this using a vulnerability scanner like JFrog Xray, which automatically identifies third-party components within both application source code and binaries, then alerts you to vulnerabilities associated with those components.

Vulnerability analysis using JFrog Xray.

Continuously scanning your software — including software obtained from outside vendors or open source projects — helps to ensure that risks that your suppliers failed to address won’t turn into breaches for you.

Software scanners also allow you to compile an SBOM for software that you use. As noted above, SBOMs, which systematically track the components of software systems, are becoming a requirement for vendors who do business with U.S. federal agencies. They may become standard for organizations outside of the government sector as well.

Be proactive about vulnerable components

When vulnerability scanning reveals risks within your software, be proactive by mitigating the risks as quickly as possible.

If a patch for the vulnerability is available, make sure you apply the patch or upgrade to the latest version of the affected component. If an update is not possible, look for ways to mitigate the vulnerability. For example, you could isolate the vulnerable component, or modify its configuration in order to prevent the conditions that enable the vulnerability to be exploited.

Keep in mind that it sometimes takes years for developers to fix security issues within software — especially in the case of open source projects where there is no financial incentive to ensure rapid resolution of security issues. If you can’t expect the software supplier to fix a vulnerability in a reasonable amount of time, you’ll likely need to switch to a different component entirely by, for example, finding an alternative open source library to use within your codebase.