The State of SBOMs in 2022

It’s been nearly nine months since our post on the premise, the promise, and the peril of software bills of material (SBOMs), and while there have been many developments since then, the actual state of affairs has not changed as much as many people had expected. In today’s post, we’ll be discussing what’s happened during 2021 and 2022 with respect to the state of SBOMs.

May 2021 – Improving the Nation’s Cybersecurity

President Biden issued Executive Order (EO) 14028, Improving the Nation’s Cybersecurity in May of 2021. This order mandated the establishment of supply chain security minimum standards for all software that is consumed by the US government; in other words, it directed federal agencies to adopt and use SBOMs to improve the security of the federal government’s software supply chain. The order’s primary purpose is to improve transparency, enhance security, improve management and ensure compliance by requiring software developers to produce an SBOM for each product or to publish it on a public website. We previously discussed how machine readable metadata, like the data contained within SBOMs, has the potential to revolutionize many areas of modern business, though we noted that there are inherent limitations to the use of SBOMs as a standalone solution.

July 2021 – Minimum Elements for SBOMs

The US Department of Commerce (USDOC) published the Minimum Elements for an SBOM in July of 2021 to provide guidance on what should be included in an SBOM to ensure that it is comprehensive and useful for identifying and managing software security risks; they echoed our sentiment, as they also explicitly noted the limitations of using SBOMs as a “catchall” solution.

The USDOC’s statement on the Minimum Elements for an SBOM is intended to provide a baseline for the information that should be included in an SBOM, and it is expected that future efforts will incorporate more detail and technical advances as the capabilities for transparency in the software supply chain improve and evolve.

The statement identified three categories of elements that should be included in an SBOM:

  • Data fields
  • Automation support
  • Practices and processes

Data Fields

Data fields are the core of an SBOM and include baseline information about each component of the software. These data fields are used to enable sufficient identification of the components in order to track them across the software supply chain and map them to other sources of data, such as vulnerability databases or license databases. The baseline data fields should include:

  • Supplier name
  • Component name and version
  • Other Unique identifiers
  • Dependency relationship
  • Author of SBOM data
  • Timestamp

Automation Support

Automation support refers to the tools and formats that are used to encode the data fields in an SBOM. This includes tools and formats that enable the automated processing and analysis of SBOM data, as well as those that enable the integration of SBOM data with other systems and tools.

Practices and Processes

Practices and processes refer to the guidelines and protocols that are followed when creating and maintaining an SBOM. This includes guidelines for how to collect and organize data, as well as protocols for how to update and maintain the SBOM over time.

February 2022 – NIST Guidance

The EO mandated that the National Institute of Standards and Technology (NIST) create a set of guidelines addressing practices to enhance the security of the software supply chain. In February 2022, NIST delivered the Software Supply Chain Security Guidance on Attestation and the Secure Software Development Framework (SSDF) in response to this mandate.

Software Supply Chain Security Guidance: Attestation

NIST developed a set of recommendations to address how federal agencies address artifacts, attestation, and conformity with secure software development. While this guidance is directed specifically to federal agencies, it provides useful guidance for anyone who is looking to develop robust software acquisition processes.

NIST outlined the following minimum recommendations:

  • Software producers should use the terminology and structure of the Secure Software Development Framework (SSDF, discussed in the next section) to communicate about their secure software development practices to federal agencies.
  • Agencies should request attestation of secure software development practices used throughout the software life cycle, including post-release practices.
  • Agencies should accept self-attestation of this conformity unless a risk-based assessment suggests that second- or third-party attestations are more appropriate.
  • Agencies should request high-level artifacts of conformance, rather than low-level artifacts.

Secure Software Development Framework

The SSDF is published in NIST Special Publication 800-218; it focuses on the ends, rather than the means, so it does not include prescriptive implementation guidance. The framework outlines recommended secure development practices in four main categories:

  • Organizational preparation
  • Software protection
  • Secure software production
  • Vulnerability response

Within each category, NIST provides suggestions for specific practices that should be followed, tasks required to complete the practice, implementation examples, and references to best practices (including governmental and industry standards).

Following the publication of these guidelines, the federal government must only use software developed by providers who can attest to the compliance with these practices.

July 2022 – National Defense Authorization Act (NDAA) – Attempt #1

We’ll include a TLDR disclosure here: the information below did not make it into the NDAA that was approved by the Senate. We’re including the information below to give context to the shift in regulatory response to SBOM requirements.

The version of the National Defense Authorization Act for Fiscal Year 2023 that passed in the U.S. House of Representatives in July 2022 included a section requiring the Secretary of Homeland Security to issue guidance on software supply chain risk management for new and existing covered contracts (namely for software or information and communications services for the Department of Homeland Security). New contracts would require contractors to submit a planned SBOM and certification and notifications as a condition of contract award. Existing contracts would require contractors to submit the SBOM and certification and notifications upon request from the relevant officer. In the event of changes to the information in the SBOM, contractors would be required to submit updates in a timely manner. The required certification and notifications would include a certification that all items listed in the bill of materials are free from known vulnerabilities or defects, that notification would be provided for any vulnerabilities or defects that were identified, and a plan to mitigate, repair, or resolve these vulnerabilities or defects would be developed and communicated.

September 2022 – OMB Software Supply Chain Memorandum

In September of 2022, the Office of Management and Budget (OMB) published M-22-18 (Memorandum on: Enhancing the Security of the Software Supply Chain through Secure Software Development Practices), in the memorandum it states that federal agencies must follow the NIST attestation guidance (as we covered in the Software Supply Chain Security Guidance: Attestation section). Agencies may also request artifacts from software producers that demonstrate conformance to secure development practices, including an SBOM that complies with the USDOC guidance that we previously discussed. In some cases, agencies may require a Plan of Action & Milestones (POA&M) from software producers in order to address any practices to which they cannot attest. The agency must retain all documentation related to self-attestation and artifacts, unless they are publicly posted by the software producer and a link to the posting is provided to the agency.

The memo included timelines for these requirements, both for “critical software” and for all other software; regardless, by September 2023 we expect to see federal agencies starting to require additional information from their software vendors.

December 2022 – National Defense Authorization Act for Fiscal Year 2023 (H.R. 7776)

The NDAA is back, but this time it’s bicameral! If you think back to the last time we mentioned the NDAA a few paragraphs ago…you can forget all of that. It’s all gone. There’s literally no mention of SBOMs anywhere in the bill.

You may be asking yourself what happened between July and December. Lobbying, it turns out.

The Alliance for Digital Innovation (ADI) trade group, which includes numerous well-known companies like Amazon Web Services (AWS), Google Cloud Platform (GCP), and others, successfully lobbied to have all language related to SBOMs removed from the FY 2023 NDAA. The basis of their argument seemed to be that while they agreed with the spirit of the EO and strengthening software supply chain security, SBOMs were not the best way to accomplish this.

A Ticking Time (S)BOM?

So where do all of these developments (or lack thereof) leave SBOMs? While the enacted version of the NDAA took SBOM requirements off the table, it’s possible that we’ll see them addressed in a standalone bill, subsequent defense bills, or in discretionary spending funds to address SBOMs.

Securing the Software Supply Chain

It’s broadly accepted that SBOMs by themselves will not secure the supply chain – they’re an important element, but there are other processes and technologies that can bolster the overall security of the software supply chain.

Given the explosive growth of data and the related increase in the number and complexity of machine learning models, additional measures should be undertaken to establish provenance of data and models. In prior posts, we introduced the idea of data bills of materials (DBOMs) and emphasized the importance of maintaining good data provenance for training machine learning models. In our SCA post we noted that combining source composition analysis with static code analysis yields better results than use of either alone.

While we’re interested in seeing how the regulatory oversight of SBOMs turns out, we’ll continue to espouse the importance of layering your tools, techniques, and processes to ensure secure software development and supply chains.