Several recent, high-profile cyber incidents have heightened organizations’ awareness of cybersecurity risks. Experts’ careful examination indicate that increased transparency into software components could help mitigate these risks, including using a software bill of materials, or SBOM. However, three faulty assumptions about SBOMs are creating a rush in Washington to codify a tool that is not yet ready.
What Is an SBOM?
An SBOM is a way for a software vendor to deliver information about what’s in its software. As with other information, it is the process of using an SBOM that creates value. At BSA, we support the development of SBOMs and, importantly, the associated tooling, standards, and automation (collectively, the “supporting materials”) necessary to convert an SBOM into concrete cybersecurity improvements.
The cybersecurity community fully expects laws and policies requiring SBOMs in the future. However, the discourse on the current readiness and value of SBOMs has become disconnected from the realities of the complex and global software supply chain.
Too many policymakers incorrectly assume that 1) SBOMs and supporting materials are ready for use, if policymakers incentivize a vendor to provide one; 2) organizations, including US Government agencies, are prepared to effectively use SBOMs they receive from vendors; and 3) an SBOM would solve a majority, if not all, of today’s cybersecurity challenges.
These three assumptions are creating a rush to codify the requirement for a vendor to deliver an SBOM in the United States — specifically, as proposed in Section 6722 of the FY23 NDAA. Yet such a requirement would undermine the considerable progress being made among the software industry, government, and other stakeholders to develop SBOMs and supporting materials that are effective.
SBOMs Are Not Ready Today — But They Will Be Soon
In July 2021, following President Biden’s Executive Order on Improving the Nation’s Cybersecurity, the National Telecommunications and Information Administration (NTIA) published The Minimum Elements for a Software Bill of Materials (SBOM). In it, the NTIA identifies seven minimum elements of an SBOM and several gaps in developing SBOMs that need to be resolved. The gaps include:
- Frequency of delivery
- Access control
- Depth (including the exploitability of a known vulnerability)
- Known Unknowns
- Distribution and Delivery
- Accommodation of Mistakes
More recently, in July of this year, the Department of Homeland Security released the Cyber Safety Review Board’s Review of the December 2021 Log4j Event, echoing that there are issues with SBOMs that need addressing. The report states that “today, SBOMs are limited, for example by variances in field descriptions and lack of version information about catalogued components, and lack of automation on the consumption end due to these variances.”
Additionally, CISA has launched a series of listening sessions across four workstreams to help address and overcome many of these hurdles, building on rapid progress to plug the gaps in developing SBOMs. In short, experts agree that critical issues still need to be resolved before vendors can realistically be required to provide an SBOM to a customer.
Even Once Ready, SBOMs Will Not Be a Silver Bullet
Even once an SBOM and supporting materials are ready, an SBOM will not address most, let alone all, of the daily cyber risks an organization faces.
For example, an SBOM will provide limited value in procurement decisions for multiple reasons, including that vendors will likely update SBOMs so frequently that the SBOM will be outdated by the time a procurement decision is made.
What an SBOM will significantly improve, however, is an organization’s response to and recovery from a cyber incident, for example, by expediting an organization’s determination about whether it is using software with a known vulnerability and if that vulnerability is exploitable.
Recommendations to Congress: SBOMs in the FY23 NDAA
As Congress resumes, lawmakers should remove Section 6722 of H.R. 7900, the FY23 NDAA, which would require a vendor to deliver an SBOM to a US Government agency as part of its contract. While well-intentioned, the section would fragment the ongoing implementation of the Executive Order on Improving the Nation’s Cybersecurity and threaten to get out ahead of the ongoing, collaborative efforts of the software industry, government, and other stakeholders to develop effective SBOMs. Congress should not risk the rapid progress being made on SBOMS. Instead, Congress should strike Section 6722 and allow the current work to conclude.
Another fruitful path would be for Congress to consider refining the proposed Senate Amendment to the FY23 NDAA contained in Section 1627 Requirement for Software Bill of Materials. This amendment directs the Department of Defense, “in consultation with industry, [to] develop an approach for commercial software in use by the Department and future acquisitions of commercial software that provides, to the maximum extent practicable, policies and processes for operationalizing software bills of materials.” Congress could improve this amendment by, among other things, refining the scope and definitions.
When fully realized, SBOMs and supporting materials will be an effective risk management tool resulting in concrete cybersecurity improvements. But if codified before collaborative efforts mature, there is a significant risk that SBOMs will generate information that is neither valuable nor actionable. Congress has the opportunity to support the considerable progress the US government is making in collaboration with the software industry to develop SBOMs and supporting material that are useful and effective. At BSA, we look forward to continuing to work with elected officials and other stakeholders to improve cybersecurity risk management.
