Generating and maintaining a complete and accurate Software Bill of Materials (SBOM) can be a challenge considering the ubiquity of third-party and open-source code in software development. But did you know the Cybersecurity and Infrastructure Security Agency (CISA) has defined six types of SBOMs that can be produced for any given software application? For the most part, you will notice each SBOM type coincides with a specific phase of the software development lifecycle (SDLC).
Each SBOM type has its advantages, disadvantages, and situations in which one may be more appropriate than another. You may very well find multiple SBOMs are relevant to your organization. The answer depends on the questions you need your SBOM to address and risks you are prioritizing.
Before digging into the different types of SBOMs, it’s important to remember the minimum content of an SBOM as defined by the National Telecommunications and Information Administration (NTIA) applies to each of them.
Design SBOM
A Design SBOM an “SBOM of intended design of included components (some of which may not exist) for a new software artifact.” It is typically derived from a software solution architecture specification, request for proposal (RFP), or another initial concept.
A Design SBOM can highlight incompatible components ahead of licensing purchase or acquisition. It can also define approved or recommended software components for developer use.
However, a Design SBOM may be very difficult to generate, and it is unlikely to identify as much detail as found in other SBOM types.
There are tools available that specialize in generating SBOMs for the design phase, enabling organizations to plan and document software components early in the development lifecycle.
Source SBOM
A Source SBOM is described by CISA as an “SBOM created directly from the development environment, source files, and included dependencies used to build a product artifact.” A Source SBOM is typically generated from Software Composition Analysis (SCA) tooling with manual clarifications. This manual activity is also called an audit.
A Source SBOM provides visibility without access to the Build process. It can facilitate remediation of vulnerabilities at the source. It can also provide a view into the dependency hierarchy of the included components, also known as Dependency Analysis. These dependencies may be direct or transient (dependencies of the dependencies).
It’s important to keep in mind that a Source SBOM can highlight components (which might have vulnerabilities) that never run or are compiled out in deployed code. Depending on language/ecosystem, a Source SBOM may not include runtime, plugin, or dynamic components, like application server or platform libraries. They may require references to other SBOMs for completeness. Ensure your SCA tooling can easily ingest supplier/vendor SBOMs so you can consolidate and generate a complete Source SBOM.
FossID can generate Source SBOMs that include all of an application’s third-party commercial, open source, and proprietary libraries; and can import/export standard formats like SPDX, SPDX-Lite, and CycloneDX.
Build SBOM
CISA describes a Build SBOM as an “SBOM generated through the analysis of artifacts (e.g., executables, packages, containers, and virtual machine images) after its Build, and such analysis generally requires a variety of heuristics. In some contexts, this may also be referred to as a “3rd party” SBOM.”
The Build SBOM is typically generated as part of a Build process, and it may consist of integrated intermediate Build and Source SBOMs for a final release artifact SBOM.
This type of SBOM provides greater confidence that the SBOM representation of the product artifact is accurate due to information available during the Build and/or Continuous Integration/Continuous Deployment (CI/CD) processes. A Build SBOM provides visibility into more components than just source code. Another advantage to automating Build SBOM creation as part of software delivery workflows is the ability to digitally sign your SBOM to establish trust with your clients by confidently attesting to what’s in your software.
On the flip side, an organization may potentially have to change the build process to generate this SBOM as it is highly dependent on the build environment in which the build is executed. It may be difficult to capture indirect (aka “transient”) and/or runtime dependencies. Also, it may not contain the correct versions of dynamically linked dependencies (as they may be replaced at runtime depending on language/ecosystem).
FossID integrates with CI/CD workflows to generate Build SBOMs as well.
Analyzed SBOM
The Analyzed SBOM is “generated through analysis of artifacts (i.e. Executables, packages, containers, and virtual machine images) after its build. Such analysis generally requires a variety of heuristics. In some contexts, this may also be referred to as a “3rd party” SBOM.” This type is typically generated through analysis of artifacts by 3rd party tooling.
An Analyzed SBOM provides visibility without an active development environment, such as legacy firmware artifacts. It does not need access to the build process. It can help verify SBOM data from other sources, and it may find hidden dependencies missed by other SBOM type creation tools.
If the tool is unable to decompose or recognize the software components precisely, the Analyzed SBOM may be prone to omissions, errors, or approximations. As a result, it may depend on heuristics or context-specific risk factors.
Deployed SBOM
A Deployed SBOM “provides an inventory of software that is present on a system. This may be an assembly of other SBOMs that combines analysis of configuration options, and examination of execution behavior in a (potentially simulated) deployment environment.” This type is typically generated by recording the SBOMs and configuration information of artifacts installed on systems.
A Deployed SBOM highlights software components installed on a system, including other configurations and system components used to run an application.
Therefore, it may require changing install and deploy processes to generate. Also, it may not accurately reflect the software’s runtime environment, as components may reside in inaccessible code.
Runtime SBOM
Lastly, the Runtime SBOM is defined as an “SBOM generated through instrumenting the system running the software, to capture only components present in the system, as well as external call-outs or dynamically loaded components. In some contexts, this may also be referred to as an “Instrumented” or “Dynamic” SBOM.”
You’ll find this SBOM type is typically generated from tooling interacting with a system to record the artifacts present in a running environment and/or that have been executed.
A Runtime SBOM provides visibility to understand what’s in use when the system is running, including dynamically loaded components and external connections. It can include detailed information about whether components are active and what parts are used. This may be very useful in reducing noise for application security management, but would be a hindrance for copyright and license compliance management.
Be aware that a Runtime SBOM requires the system to be analyzed while running, which may require additional overhead. Some detailed information may be available only after the system has run for a period until the complete functionality is exercised.
Cloud Security Posture Management (CSPM) products tend to offer Runtime SBOMs.
Choose the SBOM Type That is Right for You
Easier said than done, perhaps. At any rate, it’s important to consider your specific requirements, your development and maintenance process, and what level of detailed information fits your organization’s risk profile.
In cases where completeness and accuracy are critical – M&A tech due diligence, protection of enterprise intellectual property, on-premises or embedded systems – consider Source and/or Build SBOMs along with open source audit support.
