Where SBOMs Stand Today

What a difference two years makes. Around this time in 2021, the term "SBOM" — which stands for software bill of materials — was hardly common, even in security conversations. Now, we see it discussed in organizations around the country, even around the world.

This is due to Executive Order 14028, signed by President Biden on May 12, 2021, a critical milestone in the nation's cybersecurity landscape. The main objective of EO 14028 was to establish security prerequisites for software suppliers who sell their software to the United States government, but inevitably the recommendations made in the order have also persuaded the private sector to take notice. Two years have passed since the announcement, and it's worth evaluating where we are now and where we still have improvements to make. 

Often described as an "ingredient list" for software, an SBOM is a list of components and their versions used in a software application or system. It provides transparency into the software supply chain and helps organizations manage the risk associated with the software they use. The executive order mandates federal contractors to maintain an SBOM in order to work with the US government. However, we are now seeing SBOMs used much more widely than that.

Awareness of SBOMs has grown tremendously. How much? Exact numbers are hard to come by, but a survey of 412 organizations around the globe, conducted in 2022 by the Linux Foundation, finds: 

The state of the SBOM is this: It has become an important tool for organizations to aggregate many types of software dependency risk, from licensing issues to vulnerabilities to end-of-life risks. The visibility it provides is invaluable, and this is why we are seeing more private sector organizations requiring their partners to maintain an SBOM. And why many Fortune 1000 companies now have an active SBOM project.

However, with more adoption, we are also seeing more operational challenges. The learning curve has been steep for some organizations. Security leaders have questions, such as how to maintain, share, operationalize, and keep an SBOM up to date. Operationalizing the SBOM is the straw man, and many organizations still struggle with where to get started with the basic requirements for building an SBOM.

Where the Rubber Hits the Road: Operationalizing SBOMs Two Years In

The first step in implementing an SBOM is defining your scope. Understand where your critical apps are located and the best place to start analyzing them (in dev, stage, or production). Next, it's essential to instrument a process to scan and collect data automatically. You do not want to scan once in a while, manually. Up-to-date visibility and information is key to ensuring the SBOM gives you useful information. 

The next step is to enrich 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 SBOM data with threat data helps organizations identify risks and prioritize remediation efforts.

What Are SBOMs' Challenges?

Two years in, we see more organizations using SBOMs for visibility and information — and also for vulnerability management. This includes remediation and prioritization of flaws in the environment. This can be challenging, as it requires a deep understanding of what's actually used in runtime (versus what can be deprioritized). Furthermore, organizations need to understand the dependencies between components and how they impact the software application or system. Complete software supply chain platforms need to provide these capabilities to allow their customers to prioritize remediation efforts.

Automation is another consideration as we see more organization moving forward with SBOMs. Creating SBOMs, mapping risk to components, prioritizing, and remediating can't be done manually at the scale and speed in which products are developed today. SBOMs simply can't be used operationally if they aren't coupled with automation.

The SBOM has become an essential tool for managing software supply chain risk. We have seen a significant amount of growth in awareness and adoption of the SBOM in the past two years. And two years from now, I predict we will see SBOMs used as a standard by almost every organization that is serious about their security strategy. By doing so, organizations can manage the risks associated with the software they use, protect their reputation, and improve their cybersecurity posture.