What is an SBOM and why is it important?
If you’re new to the word “SBOM” and every time you hear it think, “What bill? I don’t want to pay a bill!” then this article is for you!
A “SBOM” or “Software Bill of Materials” is an inventory of the components that make up a piece of software. It records the list of software libraries, code snippets, dependencies, and other types of assets that are used to construct the software, including the versions of each component that were used. It can also include additional information, such as licensing and copyright details, about the components.
Another way to think of an SBOM is like a list of ingredients in a cake recipe or materials and food needed for a barbeque. The SBOM lists all the things needed to make the software, the same way a cook lists the ingredients of a cake, or the items needed to host a barbeque, and how they go together. The SBOM tells you what is inside the software and how it was built. A good SBOM can even tell you who invented the software and where they got their special ingredients from, in the event that the ingredient is outdated (or “expired”) or a better ingredient is now available to use.
With the increasing use of open source software in every product, SBOMs are becoming more and more essential tools for software composition analysis (SCA), security analysis, and compliance requirements to ensure the product is safe and secure for the customer. By providing comprehensive information about the software’s composition and its components, an SBOM can help organizations develop and deliver secure, reliable, and compliant software to their customers.
In the event that something in a product needs to be fixed or replaced, an SBOM is a vital first-step and roadmap to tracking down exactly what needs to be done and how.
What is in an SBOM and how is CISA helping to standardize SBOMs?
In response to the Executive Order 14028 on improving the nation’s cybersecurity, the National Telecommunications and Information Administration (NTIA) established a now widely-used definition of what an SBOM should contain at minimum. However even with this “minimum ingredients” definition, no two SBOMs are alike and the type of data included in an SBOM can vary depending on what tool generated it and for what purpose.
Since the start of the new year, CISA has worked with the open source cybersecurity community to address this variance by defining and explaining the main types of SBOMs that industry tools can create, what information is generally packaged inside of each of these SBOM types, and the benefits and limitations of each type of SBOM.
Their document identifies six primary SBOM types and compositions: Design, Source, Build, Analyzed, Deployed, and Runtime SBOMs.
1. Design SBOMs
According to the CISA “Types of Software Bill of Material (SBOM) Documents,” a Design SBOM is an “SBOM of intended design of included components (some of which may not exist) for a new software artifact.” These SBOMs usually come from a design specification, a Request for Proposal (RFP), or an initial concept and are quick ways to highlight any incompatible components prior to purchasing licensing for them or fully acquiring them.
Think of a Design SBOM as the plans to host a barbeque: it lists the different food you, friends, and family plan on bringing and making, and the drinks, utensils, and cooking materials that might be needed based on your past barbequing experience and your expectations for the barbeque itself and where it will be hosted. Design SBOMs can also list recommended components for developers to use. However, Design SBOMs are unlikely to go as in-depth as other SBOM types and can be very difficult to generate based on the available tools.
Although design SBOMs do not represent the final list of components that are present in the software, it can be a good starting point for analyzing dependencies and vulnerabilities. When the design SBOM is in a standardized format, it can also be ingested and handled by different SBOM tools early in the development process.
Vigiles is a vulnerability and SBOM management tool designed by Timesys that can ingest SBOMs of all types, including Design SBOMs, and export SBOMs in industry-standard formats such as CycloneDX, SPDX, and SPDX-lite.
2. Source SBOMs
A Source SBOM is akin to what it sounds like – it is “created directly from the development environment, source files, and included dependencies used to build a product artifact.” Most commonly generated by a software composition analysis (SCA) tool, with manual clarifications, Source SBOMs provide great visibility, without direct access, to the build process and a complete picture of the software components used in the product.
Another way of looking at Source SBOMs is after you’ve made plans to host a barbeque and presented the items potentially needed, all the ingredients and materials are gathered and collected. At this point, you can realize that one of the condiments has expired or that particular brand is no longer available, so you grab a different one.
Source SBOMs are beneficial in that they can help facilitate the remediation of a vulnerability, provide a view into the dependency tree or hierarchy of the included components, but a Source SBOM might also highlight vulnerabilities from components that will never run because they aren’t included in the final build. This can result in an inaccurate SBOM and false positives of vulnerabilities.
However, depending on the language the Source SBOMs is generated in and the ecosystem it came from, it may not include runtime, plugins, or even dynamic components like platform libraries and appserver. For a complete picture, you may need to reference other SBOMs.
SCA tools that depend on Source SBOMs have been popular for analyzing open source code usage, but suffer from a lack of metadata and other information that is visible at the build system level. Properly identifying the open source library versions and Common Platform Enumeration (CPE) names has also proven to be challenging, which makes efficient use of the source SBOM information tricky. Correctly matching packages to vulnerabilities is a major challenge of creating and using SBOMs for vulnerability analysis.
To this end, Timesys continues to enhance and improve Vigiles in order to provide more accurate SBOMs and associated vulnerabilities and risks, and is working on expanding the number of feeds that Vigiles SBOMs reference.
3. Build SBOMs
As the name implies, Build SBOMs are generated as part of the process of building the software to create a releasable artifact (such as an executable or package) from data such as source files, dependencies, built components, build process ephemeral data, and other SBOMs.
The build process may consist of integrated intermediate Build and Source SBOMs for a final release artifact SBOM. This type of SBOM increases confidence in the accuracy of the SBOM representation of the product artifact due to the information available during the build or Continuous Integration/Continuous Deployment (CI/CD) processes.
It can also provide visibility into more components than just source code, and enables signing of the SBOM and product artifact by the same build workflow, thereby increasing trust.
However, generating Build SBOMs may require changes to the build process and is highly dependent on the build environment in which the build is executed. Additionally, it may be difficult to capture indirect and/or runtime dependencies, and may not contain the correct versions of dynamically linked dependencies (as they may be replaced at runtime depending on language or ecosystem).
In other words, the food and meal of the barbeque is the final “artifact” and while the barbeque is being set up and you’re cooking the food, someone makes a list, or “inventory,” or the ingredients and materials that are being used in the process to create the final meal. With everyone at the barbeque, this is when you find out that nobody wants the cilantro you brought, so you don’t need it and set it aside.
For more accurate SBOM generation, Vigiles is an SBOM management tool with build system plugins to support all major Linux build system integrations including Yocto, Buildroot, OpenWrt, and Timesys Factory. You can automatically scan your SBOM against a curated vulnerabilities database and track and manage your SBOMs across various products and releases.
4. Analyzed SBOMs
As with the other SBOM types, Analyzed SBOMs can be identified by their name: they are generated by third-party tooling through analysis of artifacts such as executables, packages, containers, and virtual machine images and require a variety of heuristics. Because of how they are generated, Analyzed SBOMs may also be referred to as a “third-party SBOM.”
Analyzed SBOMs are great for products without an active development environment, such as with legacy firmware artifacts. They don’t need access to the build process, can help verify SBOM data from other sources, and may even find hidden dependencies missed by other SBOM-type creation tools.
Even so, Analyzed SBOMs can be prone to omissions, errors, or approximations if the tool that generated the SBOM is unable to decompose or recognize the software components precisely.
More simply, when you’re done cooking the food for the barbeque, a friend of the family decides to make a list of all the ingredients that were used and the materials present. Because they weren’t involved in the whole process, they just got there, and they’re evaluating things at this stage of the barbeque, they might miss some details.
5. Deployed SBOMs
Deployed SBOMs provide an inventory of the software that is present on a system and are created by recording the SBOMs and configuration information of artifacts that have been installed on systems. This type of SBOM offers a comprehensive picture of the software components that are installed on a system, including other configurations and system components used to run an application.
However, in order to generate a Deployed SBOM, you may need to incorporate changes into the installation and deployment processes. Additionally, Deployed SBOMs may not accurately reflect the software’s runtime environment as some components may be inside of inaccessible code. An equivalent of this SBOM is once you’re done cooking and while you’re setting the barbeque food out, you decide to also make a list of all the ingredients present, but doing so distracts you from the task of putting all the food on the table.
Still, the Deployed SBOM provides important information about the software components that are actually present on a system, making it a valuable tool for understanding and managing the software landscape in a deployed environment.
6. Runtime SBOMs
The final SBOM type classified by CISA is the Runtime SBOM. These SBOMs are “generated through instrumenting the system running the software, to capture only what is loaded and executing in memory, as well as external call-outs or dynamically loaded components.” Because of their functions, Runtime SBOMs are sometimes also called “Instrumented SBOMs” or “Dynamic SBOMs.”
The important thing to note about Runtime SBOMs is that they are generated by tools interacting with a system in a running environment. Since it requires the system to be analyzed while running, Runtime SBOMs may invoke additional overhead.
That said, Runtime SBOMs provide great visibility into what is in use when the system is running, from dynamically loaded components to external connections, and can even include detailed information about what components are active and in use. To get that detailed of a report, some Runtime SBOMs might require that the system be run for a certain period of time to ensure the functionality has been fully exercised.
So you finished barbequing all the food and setting the table. Now while you’re eating, the family friend makes a list of the ingredients again but can only take stock of the finished food. There are no receipts for them to reference and no cooking information is available.
This is always when you go to sit down and realize you’re missing a chair.
Is there a tool that produces all of these different SBOM types?
Not yet. There are currently many different tooling types and methods to create each of the above SBOM types and there are ways to centralize them into a singular customized dashboard.
While it may seem like a good idea to be able to create every type of SBOM, you should examine what your specific requirements are to ensure you are getting what you need. Each SBOM type comes up at a different stage of the development and maintenance process, and provides different amounts of information and, as we can see with barbequing, different challenges.
If you are working with a legacy system with no build assets available, then you could be stuck with the last three options. If development hasn’t started yet on your project, then you can only use a Design SBOM. But now, you know what your options are and where they fit into the stages of the development lifecycle, and the first step to better security practices is understanding security requirements and your particular security needs.
Vigiles is a best-in-class vulnerability monitoring and remediation tool that combines a curated CVE (Common Vulnerabilities and Exposures) database, continuous security feed based on your SBOM, powerful filtering, and easy triage tools so you don’t get blindsided by vulnerabilities. With Vigiles, you can generate SBOMs in industry-standard formats such as SPDX, SPDX-lite, and CycloneDX, view, compare, import, export, and validate SBOMs in a user-friendly easy-to-digest interface, and more. By combining SBOM management with a curated CVE database, Vigiles enables you to stay on top of relevant vulnerabilities without having to shift through thousands of different emails or news articles.
Best of all, you can try out a free version of Vigiles and if it fits your needs, unlock additional features and customize it for your company. Get started with Vigiles by registering here and if you are a Yocto or Buildroot user, you can download meta-timesys or vigiles-buildroot to get started.
For a guide on how to pick the best tool for your product needs, download our free SCA for Embedded Tool Evaluation Checklist.