Software Security in Supply Chains: Open Source Software Controls

As stated in the EO, “ensuring and attesting, to the extent practicable, to the integrity and provenance of open source software components used within any portion of a product[1]” is a central driver behind many flagship initiatives like the SBOM. Though organizations should enforce formal baseline software supply chain security controls regardless of where and how code is developed, the risks of using open source or community-developed software are unique. Open source projects are diverse, numerous, and use a wide range of operating models. Many of these projects’ provenance, integrity, support maintenance, and other underlying functions are not well understood or easy to discover and vary from one project to the next.

Open source software components are pervasive, and federal agencies should understand their suppliers’ usage of open source software components by considering the capabilities recommended below.

Foundational Capabilities

• Utilize Protect the Software (PS) and Respond to Vulnerabilities (RV) guidance in SSDF V1.1 to identify any publicly known vulnerabilities of supplied open source software components (e.g., Software Composition Analysis [SCA]).
• Apply procedural and technical controls to ensure that open source software components are acquired via secure channels from trustworthy repositories.[2]

Sustaining Capabilities

• Supplement SCA source code-based reviews with binary software composition analyses to identify vulnerable components in supplied binaries or images that could have been introduced during build and run activities to ascertain whether (e.g., newly discovered) vulnerabilities are applicable to the end product and to verify the contents of the end product (including verifying the applied compiler options) prior to “shipping.” These tools can also be utilized to determine whether in-house developed codebases leverage vulnerable open source software components.[3]
• Set up and maintain one or more repositories and/or libraries of open source software components that developers may utilize as part of a robust continuous integration continuous delivery (CI/CD) pipeline, in accordance with SSDF V1.1. This can include a repository to host sanctioned and vetted open source components.

Enhancing Capabilities

• Prioritize the use of programming languages and frameworks that have built-in guardrails to proactively mitigate common types of vulnerabilities.[4]
• Automate the pipeline of collecting, storing, and scanning open source software components to designated, hardened internal repositories and/or sandboxes prior to introduction into development environments.

Content:

• Introduction

• Guidance, Purpose, Scope, and Audience

• EO-Critical Software and Security Measures for EO-Critical Software

• Software Cybersecurity for Producers and Users

  • Attesting to Conformity with Secure Software Development Practices

• Software Verification

• Evolving Standards, Tools, and Recommended Practices

  • Software Bill of Materials (SBOM)

  • Enhanced Vendor Risk Assessments

  • Open Source Software Controls

  • Vulnerability Management

• Additional Existing Industry Standards, Tools, and Recommended Practices

• Frequently Asked Questions (FAQs)