Software supply chain security refers to the practice of identifying and addressing risks in the technologies and processes that are part of software development. The links in the software supply chain extend from development to deployment and include open source dependencies, build tools, package managers, testing tools, and plenty in between.
Supply chain threats differ from (and have the potential to be more damaging than) classic attacks because a single breach can impact hundreds or even thousands of different targets, and it can be very difficult to detect issues downstream.
Noteworthy software supply chain attacks include:
The specifics of these supply chain attacks varied — one targeted a developer tool, another an open source package, and a third proprietary software. But the common thread was that bad actors struck multiple targets by compromising a single, shared resource.
The possibility of these types of significant and widespread breaches — coupled with new regulatory guidance (such as the Biden Administration’s Executive Order) — has led many organizations to prioritize software supply chain security initiatives.
Given the large number of components in modern software supply chains, there’s no single, foolproof solution to combat all supply chain threats. But there are a variety of strategies and tools that can help. In this guide, we’ll explore four dimensions of software supply chain security: secure development strategies, automated security testing tools, SBOMs, and evaluating software vendors.
A comprehensive approach to software supply chain security includes a number of activities throughout the SDLC. Here’s a look at several best practices organizations should consider.
There are several types of automated testing tools that can help organizations strengthen software supply chain security. In this guide, we’ll focus on several popular application security testing tools: SCA, SAST, and DAST.
Static and dynamic testing tools are complementary to one another, so security teams often use them in tandem. Other popular application security tools include IAST (interactive application security testing) and RASP (run-time application security protection).
A software bill of materials (SBOM) is a list of the components (and their metadata) and the relationship between components that make up a software application. SBOMs can be used for a variety of purposes, such as satisfying customer requests, fulfilling regulatory requirements brought on by the Biden Administration’s executive order, and supporting open source license compliance.
Another, increasingly important use case is software supply chain security. Modern applications are often built with dozens of individual software components (which pull in even more transitive dependencies), which can make it difficult for entities involved with the product (manufacturers, operators, buyers) to have visibility into potential supply chain issues. SBOMs play an important role in giving organizations the information they need to mitigate risk.
There are a range of security benefits to both producing and consuming SBOMs.
No matter the size or reputation of a prospective software vendor, it’s always a good idea to conduct some form of security vetting. The SolarWinds breach was certainly a reminder of that.
As a starting point, requesting a software bill of materials can help organizations gain visibility into potential vulnerabilities — we highlighted several benefits of consuming SBOMs earlier in this guide. NIST’s publication on the minimum required elements of an SBOM offers a good baseline as to the type of data that should be included. (However, NIST’s guidance is only mandatory for organizations selling into the U.S. federal government.)
To make sure your organization gains maximum benefit, it’s particularly important that the SBOM be made available in both human- and machine-readable formats (i.e. SPDX, CycloneDX).
Additionally, it can be helpful to create a checklist or matrix to guide your evaluation of a vendor’s security practices and processes. NIST’s publication on managing cybersecurity risk throughout the supply chain (SP 800-161r1) includes an extensive list of sample questions (pages 220-227) that organizations might consider adding to their lists. These include:
Certainly, the responses to questions can only go so far in informing your evaluation. But vetting your security vendors is an important piece of the broader software supply chain security solution.