Jun 29 2023

Federal Agencies Can Leverage Software Bills of Materials for Stronger Risk Management

SBOM data can be used to flag vulnerable, insecure or exploitable components in the global software supply chain as cyberattacks continue to rise.

Modern software development is incredibly complex for federal technology managers, with products typically built from many different components from a variety of global software supply chain sources. 

The intricacy of this development process will only increase as more advanced software is continually released for ever more powerful enterprise systems and demanding new use cases.

One method to help keep track of everything that goes into a software product is a software bill of materials, a critically important document that can serve as a point of reference for everyone from developers to government CIOs. The problem is that as the development of new systems becomes exponentially more complex, organizations struggle with SBOMs that can be extremely long and must be analyzed and operationalized at scale to ensure good software supply chain risk management practices.

With SBOMs becoming a software supply chain risk management provisioning requirement under President Joe Biden’s 2021 executive order on cybersecurity, these challenges are on the minds of federal technology professionals. Working successfully with SBOMs requires finding ways to better consume and operationalize data to inform software acquisition processes, IT software deployment methods, security practices and an organization’s overall risk management strategy.

Click the banner below to learn about the benefits of hybrid cloud environments.

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.

LEARN MORE: How advanced analytics is helping agencies fight fraud.

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.

gilaxia/Getty Images

Become an Insider

Unlock white papers, personalized recommendations and other premium content for an in-depth look at evolving IT