“The Current State of SBOMs: An Analysis of Progress and Challenges”

SBOMs: Progress, Challenges, and Analysis</h2>

Two years ago, the term “SBOM” was hardly common even in security conversations. However, since the issuance of Executive Order 14028, mandating federal contractors to maintain an SBOM, we have seen tremendous growth in awareness and adoption of the SBOM. Today, the SBOM has become an essential tool for organizations to manage their software supply chain risk by providing transparency into the software components used in an application or system. Let’s take a closer look at the progress, challenges, and analysis of the SBOM technology.

Table of Contents

The Progress of SBOMs

SBOMs are often described as an “ingredient list” for software, listing the components and their versions used in an application or system. According to a survey of 412 organizations conducted by the Linux Foundation in 2022, 82% of the organizations are familiar with the term SBOM, and 76% are actively addressing SBOM needs. Additionally, 47% of organizations are producing or consuming SBOMs, and 78% expect to produce or consume SBOMs in 2022 compared to 66% in the prior year.

The visibility provided by the SBOM is invaluable, providing organizations with the ability to aggregate multiple types of software dependency risks, including licensing issues, vulnerabilities, and end-of-life risks. This visibility has motivated many private sector organizations to require their partners to maintain SBOMs, leading to an active SBOM project among many Fortune 1000 companies.

The Challenges of SBOMs

As with any emerging technology, there are challenges associated with the SBOM. One of the main operational challenges is getting started with the basic requirements for building an SBOM. Organizations need to define their scope and understand where their critical applications are located to start analyzing them. They also need to instrument a process to scan and collect data automatically, ensuring that the SBOM is up-to-date and provides useful information.

Another challenge is enriching the SBOM with data such as common vulnerabilities and exposures (CVEs), licenses, indicators of compromise (IOCs), reputation, and other factors that provide visibility into risk. Correlating the SBOM data with threat data helps organizations identify risks and prioritize remediation efforts.

Automation is another consideration as organizations move forward with SBOMs. Creating SBOMs, mapping risk to components, prioritizing, and remediating cannot be done manually at the scale and speed in which products are developed today. Therefore, SBOMs must be coupled with automation to be used operationally.

Analysis of SBOMs

SBOMs have become an essential tool for managing software supply chain risk. Two years ago, the SBOM was relatively unknown, but today we see it discussed in organizations around the country and the world. In the future, SBOMs will likely be used as a standard by almost every organization serious about their security strategy. By managing the risks associated with the software they use, organizations can protect their reputation and improve their cybersecurity posture.

Editorial and Advice

The SBOM is an essential tool for organizations to manage their software supply chain risk. As the adoption of the SBOM becomes more widespread, organizations need to focus on operationalizing the SBOM. This includes understanding the challenges associated with building an accurate and enriched SBOM and automating the process to support scale and speed. Additionally, organizations should prioritize remediation efforts, correlating the SBOM data with threat data.

Finally, as organizations use SBOMs to manage their software risk, they need to ensure that their software development practices reflect the importance of the SBOM. They should build the SBOM into their software development process, ensuring that they create a comprehensive list of all the software components used in each application, allowing for more accurate scanning and monitoring of risks.