The Complete Guide to Software Supply Chain Security
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.
Event-stream The npm package event-stream was compromised when a project maintainer added and later modified a dependency (flatMap Stream) with malicious code. If you updated your event-stream package or any of your dependencies and you had a version range defined for flatMap Stream, it would pull in the malicious version.
SolarWinds Orion Hackers gained access to the SolarWinds Orion Platform, which many large organizations used for infrastructure monitoring. The Orion Platform was considered a single, trusted resource — if a user downloaded from SolarWinds, they expected the payload to come from SolarWinds. But once that payload was maliciously updated, many SolarWinds users, including Intel, Microsoft, Cisco, and federal government agencies, were affected.
Codecov Bash Uploader Codecov, a code coverage tool that integrates into your CI environment, was compromised when bad actors accessed credentials following an issue with the company’s Docker image creation process. The attackers were then able to change Codecov documentation and modify the script (which was included in the documentation) used to install the tool in CI environments. Twilio, GoDaddy, and many other Codecov users were impacted.
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.
Apply principles of least privilege
Access to resources across the supply chain should be granted on an as-needed basis. This includes source code repositories, development tools, and a wide variety of other software systems. Also, it’s a good idea to periodically revisit permission levels to ensure the continuous application of least-privilege principles.
Require multi-factor authentication
Although multi-factor authentication isn't a foolproof way to prevent compromised credentials, it does add another layer of security to sensitive systems and data. Ideally, open source project contributors should also use MFA, but a recent report suggests that’s often not the case.
Lockfiles will pin the versions of every package in your dependency graph, and often they will be pinned to a specific registry. This means that even if a new version is published and your semver range specification allows your code to use it, the lockfile will not be changed unless you explicitly update it. Additionally, most lockfiles include hashes that can detect man-in-the-middle attacks where the package payload has changed.
Builds are reproducible when they give the exact same output no matter when or where they’re run. This allows organizations to identify any unwanted changes, including those that may be malicious. Reproducible builds are also part of SLSA, a Google-created framework for software supply chain integrity.
Always try to validate checksums of any software that you use
This includes developer tools.
Vendor dependencies into your source control
Don’t just install from a repository every time you want to install your dependencies. When you actually vendor in your dependencies, you’re guaranteed nothing will change unless you change it.
Dependency confusion attacks are software supply chain exploits that occur because of a quirk in certain package managers. (Certain package managers check public registries for a package before private registries. So, if a package exists in a private registry, an attacker could register a malicious package with the same name in the public registry.) By reserving the namespace (in npm), or the public package name (in PyPI and others), you ensure that only approved users are able to publish under your organization’s name.
We’ll discuss this more in the next section, but given the complexity of modern applications, automated tooling has become an essential part of supply chain security. Automation can be used to detect and remediate known vulnerabilities in open source code, to scan container images, to test running applications, and much more. Where and when possible, these tools should be integrated into software development workflows, ideally as early in the SDLC as possible.
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.
SCA solutions identify and provide remediation guidance for known vulnerabilities in open source code. This is an important part of security tech stacks given the popularity of OSS in modern software development — it’s estimated that open source comprises 85-90% of the average application. We often find that organizations integrate SCA tools like FOSSA into their CI/CD pipeline so any time a new change is committed and a build is triggered, a new scan happens.
Static application security testing (SAST)
Like SCA, SAST tools are used relatively early in the software development lifecycle (and are intended to find issues in source code as opposed to running applications). The main difference is that SAST analyzes your organization’s proprietary code (i.e. the code an organization creates), while SCA assesses open source components.
Dynamic application security testing (DAST)
While SCA and SAST are static code testing solutions, DAST looks for security issues in running applications. DAST tools find errors like SQL injections, OS injections, and cross-site scripting (CWE-79), and more. In contrast to SAST and SCA, DAST does not have a language dependency because it tests the running app, however you compile it. Also, DAST takes into account context of how the application works: It tests the running application with bad inputs to see how the application behaves.
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.
Makes it easier for organizations to monitor components in their applications for vulnerabilities
Supports the creation of approved/non-approved lists for software components
Helps organizations identify and replace components nearing end-of-life
Saves engineering and security team time on identifying and reviewing code
Enables organizations to quickly determine whether they are impacted by newly reported vulnerabilities
Helps teams proactively address issues that might arise from end-of-life components
Supports accurate assessments of an organization’s risk posture and allows for more informed risk mitigation
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:
Does the supplier have personnel and/or professional ties (including its officers, directors, or similar officials, employees, consultants, or contractors) with any foreign government?
Can the supplier provide a list of who they procure hardware and software from that is utilized in the performance of the contract?
Does the supplier safeguard key program information that may be exposed through interactions with other suppliers?
Does the supplier have procedures for secure maintenance and upgrades following deployment?
Does the supplier use, record, and track risk mitigation activities throughout the life cycle of the product, system, or service?
Does the supplier align its SDLC to a secure software development standard (e.g., Microsoft Security Development Life Cycle)?
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.