The Complete Guide to Software Supply Chain Security

Secure Development Practices

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.

1. 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.
2. 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.
3. Use lockfiles
   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.
4. Set up reproducible builds
   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.
5. Always try to validate checksums of any software that you use
   This includes developer tools.
6. 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.
7. Reserve package name/namespace to protect against dependency confusion
   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.
8. Embrace automation
   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.

‍

Automated Security Testing Tools

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.

1. Software composition analysis (SCA)
   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.
2. 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.
3. 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).

‍

Software Bill of Materials (SBOM)

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.

1. Producing 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
   ‍
2. Consuming SBOMs
   ∙ 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

‍

Evaluating Proprietary Software Vendors

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.

‍