Software Security in Supply Chains: Software Bill of Materials (SBOM)

Section 10(j) of EO 14028 defines an SBOM as a “formal record containing the details and supply chain relationships of various components used in building software,[1]” similar to food ingredient labels on packaging. SBOMs hold the potential to provide increased transparency, provenance, and speed at which vulnerabilities[2] can be identified and remediated by federal departments and agencies. SBOMs can also be indicative of a developer or suppliers’ application of secure software development practices across the SDLC. Figure F-1 illustrates an example of how an SBOM may be assembled across the SDLC.

Federal agencies should ensure that their suppliers of software products and services are able to produce SBOMs in conformance with the EO and NTIA’s The Minimum Elements For a Software Bill of Materials (SBOM) by containing:

• Data Fields: Documenting baseline information about each component that should be tracked
• Automation Support: Allowing for scaling across the software ecosystem through automatic generation and machine readability
• Practices and Processes: Defining the operations of SBOM requests, generation, and use

NTIA’s guidance acknowledges that SBOM capabilities are currently nascent for federal acquirers and that the minimum elements are but “a key, initial step in the SBOM process that will advance and mature over time”. As SBOMs mature, agencies should ensure they do not deprioritize existing C-SCRM capabilities (e.g., vulnerability management practices, vendor risk assessments) under the mistaken assumption that SBOM replaces these activities. SBOMs and the improved transparency that they are meant to provide for federal acquirers are a complementary, not substitutive, capability. Federal acquirers that are unable to appropriately ingest, analyze, and act on the data that SBOMs provide will likely not improve their overall C-SCRM posture.

Federal acquirers should further consider that effectively implemented SBOMs are still subject to operational constraints. For example, SBOMs that are retroactively generated may not be able to produce the same list of dependencies used at build-time. Though this constraint may diminish over time, federal acquirers should continue using the risk-based approaches outlined in SP 800-161 Rev. 1 and SP 800-218 to guide their implementation of SBOMs over this rapid period of transition.

In his context, federal agencies should consider, where possible and applicable, the following recommended SBOM capabilities:

Foundational Capabilities

• Ensure that SBOMs conform to industry standard formats to enable the automated ingestion and monitoring of versions. According to the National Telecommunications and Information Administration, acceptable standard formats currently include SPDX, CycloneDX, and SWID.
• Provide SBOMs that meet the NTIA’s Recommended Minimum Elements, including a catalog of the supplier’s integration of open source software components.
• Ensure that SBOMs are available for all classes of software – including purchased software, open source software, and in-house software – by requiring sub-tier software suppliers to produce, maintain, and provide SBOMs whenever practical.
• Maintain readily accessible and digitally signed SBOM repositories, and share SBOMs with software purchasers directly or by publishing them on a public website.

Sustaining Capabilities

• Contextualize SBOM data with additional data elements that inform the risk posture of the acquiring entity. Additional data elements include plug-ins, hardware components, organizational controls, and other community-provided components.[3]
• Integrate vulnerability detection with SBOM repositories to enable automated alerting for applicable cybersecurity risks throughout the supply chain.[4]
• Ensure that current SBOMs detail the supplier’s integration of commercial software components.
• Maintain vendor vulnerability disclosure reports at the SBOM component level.

Enhancing Capabilities

• Develop risk management and measurement capabilities to dynamically monitor the impact of SBOMs’ vulnerability disclosures on the acquiring organization. Align with asset inventories for further risk exposure and criticality calculations.[5]
• Perform binary decomposition of software installation packages to generate SBOMs when no vendor-supplied SBOM is available (e.g., legacy software), when technically and legally feasible.[6]

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)