Selecting the Right SBOM for Your Enterprise

If you’re asking, “What is an SBOM?” you’ll need to catch up fast. A software bill of materials is the first line of defense against software vulnerabilities that can lie in wait, like unlocked back doors into your network, ready to let in hackers.

An SBOM, like any bill of materials, lists the components of the finished product, so in case of trouble, developers can zero in on the cause and address it with as little disruption as possible. SBOMs are the keystone of supply chain security, enabling more secure DevOps and better threat intelligence to maintain more resilient networks.

Two years after a ransomware gang hobbled U.S. fuel deliveries by attacking a pipeline operator, supply chain attacks remain a prime irritant to security professionals. In the wake of the attack and the discovery of the Log4J vulnerability, SBOMs have gone mainstream as security pros struggle to prevent future attacks.

The Ascendancy of SBOMs and Federal Guidance

SBOMs are having a moment. During the recent RSA conference, the federal government’s Cybersecurity and Infrastructure Security Agency (CISA) released guidance on the different types of SBOMs available and their use.

CISA has been a promoter of the use of SBOMs, particularly since Executive Order 14028 and the Office of Management and Budget’s memo M-22-18 which required the development of a reporting form for software developers serving the federal government. CISA holds SBOM-a-Rama meetings that bring together industry types to support CBOM development.

The CISA document resulted from a group effort started in 2018, and like many group efforts, it can grow unwieldy. The document’s intro acknowledges as much, stating, “Given the disparate ways SBOM data can be collected, tool outputs may vary and provide value in different use cases.” With that in mind, it’s worthwhile to break down the types of SBOMs available and some potential use cases to help clarify which can be most useful for an organization.

Decoding the 6 Main Types of SBOMs

There are six main types of SBOMs in use today as they move along the stages of the software development life cycle:

• • Design: An SBOM of this kind is created for prospective or planned software and includes components that may or may not exist. It usually is developed based on an RFP, concept, or specifications. While theoretically possible, it’s hard to picture how this could help and how it could generate a machine-readable document that would meet the standards the federal government is backing.

  One possible use case for this kind of SBOM is to alert the developers of licensing issues that might arise when considering using certain components that would affect the intellectual property or distribution of the finished product. This SBOM can help the development team identify incompatible elements before they are purchased and define a list of approved and recommended components. This type of SBOM can also enable the team to source the best open-source components from a business perspective.

• • Source: Very similar to the build-type SBOM, this one is generated in the development environment and includes all the source files and dependencies required to build an artifact but excludes the build tool from the process. It is usually produced by the software composition analysis (SCA) tool, with some clarifications added manually.

  It’s hard to see the use case for this type instead of the more common build-type SBOM. Still, this SBOM can spot vulnerable components that are never run after deployment, giving the team a view into the dependency tree of the included components. Hence, it enables the remediation of known vulnerabilities at the source early in the development process.

  On the downside, it may lack some of the detail of other kinds of SBOMs, including runtime, plugin, or dynamic components, such as app server libraries.

• • Build: The most commonly used kind of SBOM, this is a more complete inventory generated as part of the process of building the software that will run the final artifact. This approach uses data such as source files, dependencies, built components, build process ephemeral data, and previous design and source SBOMs. It relies on resolving all dependencies in the build system and scanning them on the build machine.

  Because the actual files are scanned, this kind of SBOM creates a more complete record with rich data about each file, such as its hash and source. Providing more visibility beyond what’s available from the source code builds trust that the SBOM accurately represents the development process. This trust stems from integrating the SBOM and the finished product into the same workflow.

  On the downside, this SBOM is very dependent on the build environment, which sometimes may need to change in order to produce the SBOM.

• • Analyzed: This is sometimes referred to as a “Third-Party SBOM” or binary SCA. It relies on scanning the artifact as delivered to work out its components; and uses third-party tools to analyze artifacts such as packages, containers, and virtual machine images. It doesn’t need access to the build environment and can double-check SBOM data from other sources to find hidden dependencies SBOM creation tools missed.

  Since it essentially reverse-engineers the components of the artifact, it can be a useful tool for software consumers who don’t have an SBOM available or can corroborate an existing SBOM.

  On the downside, this type of SBOM often relies on looser heuristics or risk factors based on context to test the components. So testing may produce some false-positive results. But it’s also more likely to find libraries linked in from the environment without the development team realizing it, such as OpenSSL libc, or others that build SBOMs often miss.

• • Deployed: As its name suggests, this is an inventory of the software deployed in the system, usually generated by compiling the SBOMs and configuration information of installed artifacts. It can combine analysis of configuration options and examination of execution behavior in a deployed environment. Examining software components, including the other configurations and system components that run an application, is useful.

  Generating this kind of SBOM may require changing install and deploy processes, and it may not always reflect the artifact’s runtime environment since some components may not be accessible. But the wide scope of this type of SBOM makes it an appealing option.

• • Runtime: Sometimes called an “Instrumented” or “Dynamic” SBOM, this type solves the blind spot in deployed SBOMs. In this case, tools interact with the system and record artifacts utilized in a running environment and those loaded into memory during execution. This process aids in avoiding false positives from unused components.

  This kind of SBOM gives developers visibility into dynamically loaded components and external connections and can give them details on what components are active and what parts of which are in use. It does add to the network’s overhead because the system has to be analyzed while running. Because it has to be running for some time to use its complete functionality, it may take some time to gather detailed information.

Final Thoughts on Selecting SBOMs

Considering these details, selecting the right type or combination of SBOMs to serve your organization’s needs involves more consideration than merely opting for the first SBOM-generating tool available for compliance purposes.

Given the federal government’s support, the SBOM is undoubtedly here to stay, and it can establish a solid foundation, introducing order into the occasionally chaotic process of securing software products.