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 offer increased transparency, provenance, and speed at which vulnerabilities^[2] can be identified and remediated by federal departments and agencies. SBOMs can also indicate a developer or supplier’s application of secure software development practices across the SDLC. Figure 2 illustrates an example of how an SBOM may be assembled across the SDLC.

When applicable to a procurement action, federal agencies should require their suppliers of software products and services to provide access to machine-readable 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 only the first key step in a process that will mature over time. As SBOMs mature, agencies should ensure that they do not deprioritize existing C-SCRM capabilities (e.g., vulnerability management practices, vendor risk assessments). SBOMs are meant to complement those capabilities rather than replace them. 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. Federal acquirers should continue using the risk-based approaches outlined in SP 800-161r1 and SP 800-218 to guide their implementation of SBOMs over this period of rapid transition.

In this context, federal agencies should evaluate whether and to what extent software providers can satisfy the following recommended SBOM capabilities.

Foundational SBOM Capabilities

• Ensure that SBOMs received from third-party suppliers conform to industry standard formats to enable the automated ingestion and monitoring of versions. According to the NTIA, acceptable standard formats currently include SPDX, CycloneDX, and SWID.
• Confirm that SBOMs received from third-party suppliers meet the NTIA’s Recommended Minimum Elements, including a catalog of the supplier’s integration of open-source software components.
• Catalog SBOMs for all classes of software across the acquiring entities’ enterprise — including purchased software, open-source software, and in-house software — by requiring sub-tier software suppliers to produce, maintain, and provide SBOMs whenever practical.
• Require software producers to maintain readily accessible and digitally signed SBOM repositories and to share SBOMs with software purchasers directly or by publishing them on a public website.

Sustaining Capabilities

• Contextualize SBOMs received from third-party suppliers with additional data elements (e.g., plug-ins, hardware components, organizational controls, and other community-provided components^[3])that inform the risk posture of the acquiring entity. 
• Confirm that SBOMs received from third-party suppliers detail the supplier’s integration of commercial software components.
• Integrate vulnerability detection capabilities with the acquiring entity’s SBOM repositories to enable automated alerting for applicable cybersecurity risks throughout the supply chain.^[4]

Enhancing Capabilities

• Ensure that third-party suppliers continuously enrich SBOM data with a VAR.
• Acquiring entities should develop risk management and measurement capabilities to dynamically monitor the impacts of SBOM-related VARs. Acquiring organizations should align with asset inventories for further risk exposure and criticality calculations.[5]
• Perform binary decomposition of software installation packages to generate SBOMs if 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)