If you’re unfamiliar with the term SBOM, it’s time to catch up quickly. A Software Bill of Materials serves as a primary defense against lurking software vulnerabilities, akin to unlocked backdoors into your network that hackers can exploit.

Much like a traditional bill of materials, an SBOM itemizes the components of a finished software product. This inventory allows developers to pinpoint issues swiftly and address them with minimal disruption in case of trouble. SBOMs are the linchpin of supply chain security, enabling more secure DevOps practices and enhancing threat intelligence for maintaining robust networks.

Even two years after a ransomware attack crippled U.S. fuel deliveries by targeting a pipeline operator, supply chain attacks continue to vex security professionals. In the aftermath of this attack and the discovery of vulnerabilities like Log4J, SBOMs have entered the mainstream as security experts strive to thwart future attacks.

The Rise of SBOMs and Government Guidance SBOMs are currently in the spotlight. During the recent RSA conference, the U.S. federal government’s Cybersecurity and Infrastructure Security Agency (CISA) issued guidance on various types of SBOMs and their practical applications.

CISA has been advocating for SBOM adoption, particularly following the issuance of Executive Order 14028 and the Office of Management and Budget’s memo M-22-18, which mandated the development of a reporting form for software developers serving the federal government. CISA convenes SBOM-a-Rama meetings, bringing together industry experts to support SBOM development.

The CISA document resulted from a collaborative effort initiated in 2018, and as with many group efforts, it can become unwieldy. The document’s introduction acknowledges this by stating, ‘Given the disparate ways SBOM data can be collected, tool outputs may vary and provide value in different use cases.’ With this in mind, it’s helpful to break down the various types of SBOMs available and explore potential use cases to clarify which might be most beneficial for an organization.

Deciphering the Six Primary Types of SBOMs Currently, there are six primary types of SBOMs in use throughout the software development life cycle:

  1. Design: This SBOM is created for prospective or planned software and includes components that may or may not exist yet. It’s usually based on an RFP, concept, or specifications. While theoretically possible, it’s challenging to envision how this could be beneficial or generate a machine-readable document meeting federal standards. One potential use case is to alert developers to potential licensing issues that could affect intellectual property or product distribution, helping the development team identify incompatible elements before purchase.
  2. Source: Similar to the build-type SBOM, this one is generated in the development environment and includes all source files and dependencies required to build an artifact, excluding the build tool. It’s produced by a software composition analysis (SCA) tool, with some manual clarifications. While less common than the build-type SBOM, it can identify vulnerable components that are never run after deployment, enabling early remediation of known vulnerabilities at the source.
  3. Build: The most widely used type, this SBOM provides a comprehensive inventory generated during the software building process. It includes data like 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, offering rich data about each file. This SBOM fosters trust by integrating the SBOM and the final product into the same workflow. However, it can be dependent on the build environment, which may need adjustments to produce the SBOM.
  4. Analyzed: Also known as a “Third-Party SBOM” or binary SCA, this type scans the delivered artifact to determine its components. It employs third-party tools to analyze artifacts like packages, containers, and virtual machine images. Analyzed SBOMs don’t require access to the build environment and can corroborate existing SBOM data. They may produce some false-positive results but are adept at finding libraries linked from the environment that build-type SBOMs often miss.
  5. Deployed: As the name suggests, this SBOM inventories deployed software in the system. It’s generated by compiling SBOMs and configuration information of installed artifacts. While it offers a comprehensive view, generating this SBOM may necessitate changes in installation and deployment processes. It may not always reflect the artifact’s runtime environment.
  6. Runtime: Also called an “Instrumented” or “Dynamic” SBOM, this type addresses the blind spot in deployed SBOMs. Tools interact with the system, recording artifacts used in a running environment and those loaded into memory during execution. This SBOM provides insight into dynamically loaded components and external connections, avoiding false positives from unused components. However, it adds network overhead and may take time to gather detailed information.

In Conclusion Selecting the right type or combination of SBOMs for your organization requires careful consideration, beyond opting for the first available SBOM-generating tool for compliance purposes. With strong government support, SBOMs are undoubtedly here to stay, offering a solid foundation to bring order to the occasionally chaotic process of securing software products.