A Brief Overview of Software Security Resources Supporting the Supply Chain Security Discussion
By Steve Lipner
Software assurance was traditionally the kind of boring security discipline relegated to technical journals while cybersecurity threats grabbed headlines. But over the last decade, a risk intertwined with software assurance practices started to grab end-user attention, especially in government hallways – supply chain security. Used to describe not only the more technical need to address the security of both the final product and all of the components that comprise it, but the concept of supply chain security also encompasses some of our worst fears about foreign interference in trusted technology solutions.
There has been much discussion of the security of information technology supply chains driven by end-user organizations – especially government organizations – who seek assurance that the products they are buying meet their security requirements. But the broad scope of risks grouped under the umbrella of supply chain security often makes it difficult to identify the specific implications for each of the many activities associated with the IT supply chain. This lack of clarity often leads to confusion for both suppliers and end-users.
As global technology leaders, SAFECode members are frequently drawn into these discussions and have a key role to play in managing the security of the supply chains used to deliver commercial products. As such, we thought it would be helpful to take a step back and help drive more clarity around the role of software security in the software supply chain discussion. This is not meant to solve the problem, but rather to highlight the areas of supply chain security that touch SAFECode’s software security mission, as well as to identify some of the work being done across the industry to support both suppliers looking to improve their supply chain security practices and customers seeking to evaluate and manage their own risks.
What’s a Supply Chain?
A supply chain is the set of organizations that contribute to a product. For an end-user who buys a computer system, the supply chain includes the manufacturer of the computer that’s delivered to the loading dock as well as the organizations that create the software that comes pre-loaded on the computer and the suppliers of parts and subsystems that the manufacturer builds into the finished computer system. It’s clear that both hardware and software components may have their own suppliers, so the supply chain can have many layers “upstream” from the end-user, starting with the manufacturer and ending with suppliers of individual electronic components (for hardware), or the people who write individual lines of code (for software).
What’s Supply Chain Security?
Supply chain security encompasses four high-level considerations:
- Trustworthy supplier – the designer and manufacturer of any given product or component are trusted not to take malicious actions that would compromise the security of the final product.
- Product integrity – the product and its components must be protected from outside attempts at malicious tampering (modifications) or counterfeiting (substitutions) that would undermine the security of the final product (intentional malicious modifications by the developing organization are addressed by consideration 1 above).
- Product security – the product must be designed and manufactured to be secure: the developer and manufacturer must follow security engineering best practices.
- Upstream security and integrity – the designer and manufacturer of every product or component must be assured that their upstream supply chain follows the four practices in this list.
How Can Users Gain Confidence in Supply Chain Security
SAFECode and other organizations have created guidance documents that are intended to help developers achieve supply chain security, and to help customers gain confidence in the security of their supply chains. At a high level, all of these documents seek to enable customers to assure themselves that their suppliers are implementing the practices listed above.
The newly released National Institute of Standards and Technology (NIST) Secure Software Development Framework (SSDF) white paper includes practices and tasks that address the need for supply chain security. The SSDF not only addresses issues of secure design and development (practice 3 above), but also incorporates considerations that directly speak to the other practices listed above. For example, SSDF practices PS.1 and PS.2 address protection from counterfeiting and tampering (practice 2 above), and practice PW.3 addresses the security of the upstream supply chain (practice 4 above). It is likely that the SSDF will become an influential resource for customers that seek assurance about the security of their supply chains.
SAFECode has also released documents that address the issues of supply chain security including the recent “Managing Security Risks Inherent in the Use of Third-Party Components” and the older but still useful “Overview of Software Integrity Controls” and “Framework for Software Supply Chain Integrity” as well as “Principles for Product Assurance Assessment” which is more specifically focused on customer assessment of suppliers’ secure development practices.
The Financial Services Information Sharing and Analysis Center (FS-ISAC) published guidance meant to improve information protection capabilities when using third-party services and products in the supply chain for financial institutions’ customers and employees by identifying control types to incorporate with vendor governance programs. Many of the controls in its 2015 whitepaper are still relevant today and the white paper aligns with SAFECode’s secure development guidance.
About Open Source Software
Today, Open Source Software (OSS) comprises a significant fraction of the software that individuals and organizations use. Thus, OSS is a major component of many products’ supply chains. In one sense, OSS is “just a part of the supply chain,” but organizations that consume OSS may have less control over the supplier of OSS than would be the case for commercial software.
OSS products or components may be developed by large corporations, individuals working alone and without compensation or a variety of organizational models in between those two extremes. The high-level practices listed above must still apply to OSS, but given the variation in OSS development organizations’ practices and resources, downstream product or component developers or even end-users may be required to take up more of the burden of supply chain security assurance.
The SAFECode paper on the security of third party components provides guidance that applies to developers who consume OSS, and SAFECode continues to be actively involved in initiatives aimed at improving the security of OSS that becomes part of the software supply chain. One of the most important of these initiatives is the newly formed Open Source Security Foundation (OpenSSF) being led by the Linux Foundation. The OpenSSF is a cross-industry collaboration that brings together organizations and individuals who seek to improve the security of OSS by building a broad community that will cooperate on targeted initiatives and creation of best practices. The OpenSSF brings together the industry’s most important open source security initiatives and the individuals and companies that support them, including the Linux Foundation’s Core Infrastructure Initiative (CII), founded in response to the 2014 Heartbleed bug, and the Open Source Security Coalition, founded by the GitHub Security Lab.
As a member of the OpenSSF, SAFECode will be contributing the experience and insights of our combined membership to help make OSS more trusted and useful while preserving the other benefits that have made OSS such an important part of today’s software supply chain.
Summary of Key Software Supply Chain Security Resources
Secure Software Development Framework (SSDF)
This white paper recommends a core set of high-level secure software development practices called a secure software development framework (SSDF) to be integrated within each SDLC implementation. The paper facilitates communications about secure software development practices among business owners, software developers, project managers and leads, and cybersecurity professionals within an organization.
Managing Security Risks Inherent in the Use of Third-Party Components
The use of third-party components (TPCs), including open-source software (OSS) or commercial off-the-shelf (COTS) components, has become defacto standard in software development. This paper breaks down the process and procedures developers need in order to test, improve, and quantify the security of third party components.
Framework for Software Supply Chain Integrity
Provides an industry-driven framework for analyzing and describing the efforts of software suppliers to mitigate the potential that software could be intentionally compromised during its sourcing, development or distribution.
Overview of Software Integrity Controls
This white paper provides an Assurance-Based Approach to Minimizing Risks in the Software Supply Chain and includes actionable recommendations for minimizing the risk of vulnerabilities being inserted into a software product during its sourcing, development and distribution.
Principles for Product Assurance Assessment
This paper provides a framework for examining the secure development process of commercial technology providers It is designed to help readers select the most appropriate assessment method for their needs, and provides guidance to help them develop a process-based assessment for use in cases when an appropriate international standard does not apply.
Open Source Security Foundation (OpenSSF)
The OpenSSF is a cross-industry collaboration that brings together leaders to improve the security of open source software (OSS) by building a broader community, targeted initiatives, and best practices. It aims to bring together open source security initiatives under one foundation to accelerate work through cross-industry support. This is beginning with the Core Infrastructure Initiative and the Open Source Security Coalition, and will include new working groups that address vulnerability disclosures, security tooling and more.
Appropriate Software Security Control Types for Third-Party Service and Product Providers
This paper identifies control types to incorporate with vendor governance programs in order to improve information protection capabilities when using third-party services and products in the supply chain for financial institutions’ customers and employees.