In October of last year, we published a blog that described the components of software supply chain security. To recap, we broke the issue up into four components:

  1. 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.
  2. 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).
  3. Product security – the product must be designed and manufactured to be secure: the developer and manufacturer must follow security engineering best practices.
  4. 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.

Since that blog was released, a very widely publicized series of intrusions has thrown a spotlight on component 2 – product integrity. An attack that appears to have targeted a major vendor’s product build environment resulted in the distribution of malicious software to thousands of that vendor’s customers, and in actual intrusions into systems operated by tens or hundreds of companies and government agencies.

The recent intrusions place added emphasis on the “other” aspects of code security. Not only must developers be concerned about secure development (i.e. preventing vulnerabilities in their code), they must also focus on protection and integrity of their code during development and distribution, and they must take steps to justify their trust in upstream suppliers. Although SAFECode has focused a majority of our efforts on secure development, we have long argued that secure development alone is not enough. Code integrity and supplier assurance are critical parts of code security. Framework for Software Supply Chain Integrity,  Overview of Software Integrity Controls.  

In the aftermath of the recent incidents, the United States Government released an executive order on cybersecurity that imposes requirements for both secure development and code integrity on vendors that wish to sell to the government. SAFECode has been actively involved in discussions of the implementation of the Executive Order and we strongly support its emphasis on practical and effective measures. We expect the detailed guidance that will be released in response to the Executive Order to build on the NIST Secure Software Development Framework (SSDF) which includes practical and effective practices for both secure development and code integrity.

Over the next few months, SAFECode members will be working together to document and share recommended measures for achieving code integrity and for assuring the trustworthiness of upstream suppliers. The measures for code integrity deal with the operation and protection of code repositories, bug tracking systems, build systems, and Continuous Integration (CI) pipelines. They emphasize requirements for authenticated and controlled access to code under development and for accountability for contributions and modifications. As with other aspects of code security, specific practices will vary as a function of product, technology, and lifecycle but there are common practices that developers can and should apply.

We will also be reviewing our paper on the use of third-party components. While the guidance in that paper remains sound and valid, we may amplify some of its recommendations on dealing with commercial suppliers and on reliance on open-source software (OSS).

We believe that our work on these important aspects of code security will be valuable to software development organizations that seek to deliver secure and trustworthy software to their customers and will help us to contribute to the U.S. Government’s creation of guidance under the Executive Order.