If you are asking, “What is SBOM?” You’ll need to catch up fast. A software bill of materials is the first line of defense against software vulnerabilities that may be lying in wait, like unlocked backdoors in your network, ready to let hackers in.
The SBOM, like any bill of materials, lists the components of the finished product, so in case of a problem, developers can zero in on the cause and address it with as little disruption as possible. SBOM is the key to supply chain security, enabling more secure DevOps and better threat intelligence to maintain a more resilient network.
Two years after a ransomware gang disrupted US fuel deliveries by attacking a pipeline operator, supply chain attacks remain a major annoyance for security professionals. In the wake of the attack and the discovery of the Log4J vulnerability, SBOMs have gone mainstream as security professionals struggle to prevent future attacks.
Dominance of SBOMs and Federal Guidance
SBOM is having a moment. During a recent RSA conference, the federal government’s Cyber Security and Infrastructure Security Agency (CISA) issued guidance on the different types of SBOMs available and their use.
CISA has specifically been a promoter of the use of SBOM since Executive Order 14028 and 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 organizes SBOM-a-Rama meetings that bring industry types together to support CBOM development.
The CISA document is the result of a group effort launched in 2018, and like many group efforts, it can be cumbersome. The document’s introduction acknowledges as much, stating, “The different ways in which SBOM data can be collected can vary tool outputs and provide value in different use cases.” With this in mind, it is worthwhile to help clarify the types of SBOMs available and some of the possible use cases that may be most useful to an organization.
Decoding the 6 Main Types of SBOM
There are six main types of SBOM in use today as they move through the stages of the software development life cycle:
-
• design: An SBOM of this type is created for future or planned software and includes components that may or may not be present. It is usually developed based on an RFP, concept or specifications. While theoretically possible, it is hard to envision how this could help and how it could generate a machine-readable document that would meet the standards endorsed by the federal government.
One possible use case for this type of SBOM is to alert developers to licensing issues that may arise when considering using certain components that will affect intellectual property or distribution of the finished product. This can help the SBOM development team identify incompatible elements prior to purchase and define a list of accepted and recommended components. This type of SBOM may also enable the team to source the best open-source components from a business perspective.
-
• Source: Similar to a build-type SBOM, it is generated in a development environment and includes all the source files and dependencies needed to build an artifact but leaves the build tools out of the process. It is usually generated by Software Composition Analysis (SCA) tools, with some annotations added manually.
It’s hard to see a use case for this type instead of the more general 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 components involved. Therefore, it enables remediation of known vulnerabilities at the source, early in the development process.
On the downside, it may lack the details of other types of SBOMs that involve runtime, plugin, or dynamic components, such as app server libraries.
-
• Construction: The most commonly used type of SBOM, it is a more complete list 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 actual files are scanned, this type of SBOM creates a more complete record with rich data about each file, such as its hash and source. Providing greater visibility beyond what is available from the source code instills confidence that the SBOM accurately represents the development process. This trust stems from integrating SBOM and finished product into a single workflow.
On the downside, it is very dependent on the SBOM build environment, which may sometimes need to be changed to build the SBOM.
-
• Analyzed: This is sometimes referred to as “third-party SBOM” or binary SCA. It relies on scanning the artifact as it is distributed to work out its components; and uses third-party tools to analyze artifacts such as packages, containers, and virtual machine images. It does not require access to the build environment and can double-check SBOM data from other sources to find hidden dependencies SBOM build tools may have missed.
Since it essentially reverse-engineers the components of the artifact, it can be a useful tool for software consumers who do not have an SBOM available or can verify an existing SBOM.
On the downside, this type of SBOM often relies on loose estimates or risk factors depending on the context to test the components. Therefore the test can give some false-positive results. But the development team is also more likely to find libraries linked to the environment without realizing it, such as the OpenSSL libc, or others that build SBOMs, are often missed.
-
• Deployed: As its name suggests, it is a list of software deployed in a system, usually generated by compiling configuration information from the SBOM and installed artifacts. It can combine the analysis of configuration options and the examination of execution behavior in a deployed environment. It is useful to investigate software components, including other configurations and system components that run applications.
Generating this type of SBOM may require changing installation and deployment procedures, and may not always reflect the runtime environment of the artifact as some components may be inaccessible. But the wide scope of this type of SBOM makes it an attractive option.
-
• Runtime: Sometimes called “instrumented” or “dynamic” SBOM, this type solves the blind spot in the deployed SBOM. In this case, the tools interact with the system and record the artifacts used in the running environment and loaded into memory during execution. This procedure helps avoid false positives from unused components.
This type of SBOM gives developers visibility into dynamically loaded components and external connections and can give them details about which components are active and which parts are in use. This adds to the overhead of the network as the analysis has to be done while the system is running. Because it has to run for some time to use its full functionality, it may take some time to gather detailed information.
Final Thoughts on Selecting the SBOM
With these details in mind, selecting the right type or combination of SBOMs to meet your organization’s needs involves more consideration than simply choosing the first SBOM-generating tool available for compliance purposes.
Given the support of the federal government, SBOM is undoubtedly here to stay, and it could establish a solid foundation while introducing order into the sometimes chaotic process of securing software products.