SBOMs Are Useful but Often Highly Complex
Today’s typical software product contains a vast list of components, including diverse modules and libraries called by other code or even stand-alone programs that are used in conjunction with other programs. Keeping track of all these components and their provenance is where the SBOM comes in: It is a formal record containing details and supply chain relationships of all the components used in building software. These components can be open-source or proprietary, freely available or paid, widely available or restricted.
The information present in an SBOM is valuable and can be used in a variety of ways, including helping to answer various contractual, legal or technical queries about the software. SBOM data can also flag vulnerable, insecure or exploitable components circulating in the global software supply chain. Such threats are far from hypothetical; consulting firm Gartner predicts that by 2025, 45 percent of organizations will have experienced such an attack.
The problem is that an SBOM’s use can only be maximized if organizations can consume and analyze all the information contained in one. This is easier said than done when you consider that the average SBOM can run thousands of lines.
While some forward-thinking agencies have chosen to proactively work on better integrating SBOM insights into the software development lifecycle, this is now compulsory under the executive order on cybersecurity, which advises U.S. government agencies to start requiring SBOMs for any software products they acquire. The good news is that ongoing innovation cycles around tool sets and open standards for working with SBOMs are making the job of leveraging and incorporating them easier.
Putting SBOMs to Use in the Enterprise
Deft use of SBOMs can reduce an agency’s window of exposure to flaws or security gaps in existing software. SBOMs also can help assess products prior to acquisition and during the contracting phase, allowing agencies to proactively avoid risks and ensure they will get the most value from the software investment. To reap these benefits, agencies must align systems and tools to optimally consume and operationalize SBOMs.
One key strategy is to leverage a range of open standards and frameworks designed to facilitate management of SBOM information. For instance, the International Organization for Standardization-ratified Software Package Data Exchange is an international standard that can be used to generate SBOM documents while software is being built or retroactively by analyzing existing software.
There is also the Open Worldwide Application Security Project CycloneDX standard for using SBOM data to manage advanced supply chain capabilities and cyber risk reduction.
A number of extract, transform and load; vulnerability management; asset databases; and other systems can use open standards like SPDX and CycloneDX to help interpret SBOM documents and isolate the most salient SBOM data for any particular application or human analyst.
Software developers also can leverage a framework known as the Vulnerability Exploitability eXchange to evaluate specific vulnerabilities in a particular product, either within the SBOM or as a real-time query. These and other combined tools and standards are key to unlocking value from SBOMs and the wealth of information contained in them.
SBOMs are transforming how agencies secure and manage their software assets, and documentation continues to grow in support of SBOM use across government. This includes related best practices from the Cybersecurity and Infrastructure Security Agency and the Department of Defense’s Enduring Security Framework guidance for customers, suppliers and developers.
As agencies incorporate SBOMs more fully into their acquisition, deployment, maintenance, security operations and development workflows, they stand to reap major gains on behalf of taxpayers and constituents in the form of better supply chain and operational risk management.