Software Bill of Materials (SBOM) Overview and Open Source SBOM Tools

There’s currently a lot of buzz among software industry and security professionals about software bills of materials (SBOMs). New government initiatives are requiring SBOMs and vendors are jumping at the opportunity to offer commercial tools to generate SBOMs.  

In this blog, I’ll explain what SBOMs are and how open source can be used to generate SBOMs. I’ll also cover a few aspects related to SBOMs beyond what has already been published about open source security and software supply chain attacks. 

What Is a Software Bill of Materials?

A Software Bill of Materials, or SBOM, is an inventory of software components, within an application or deployment environment, including open source software — components like frameworks, packages, and libraries. SBOMs provide transparency so that organizations can understand what is in the software they are running and assess potential risk.

The concept behind a Software Bill of Materials is not new; bills of materials (BOMs) have been present in various industries for a long time. One commonly used analogy compares SBOMs to the packaged food labels required in most countries that contain information about ingredients, the number of calories, saturated fat, sodium, and other nutrients, as well as allergen warnings. While not everyone reads nutritional labels, they provide valuable information for people with allergies and/or following specific diets. In software, having an SBOM meets a similar goal, giving organizations rapid access to the list of software components.

A closer analogy would be expiration or “use by” dates on perishable products. SBOMs include information on open source packages that are out of date or have reached end-of-life (EOL) —in other words, the “expiration date” after which open source communities do not offer any more updates to fix bugs and vulnerabilities. Do you pay attention to the expiration date of milk and over-the-counter drugs? It is a safe bet to say that most people do — and so it follows that IT teams should pay attention to outdated and end-of-life (EOL) open source software.

Another good analogy for SBOMs is the sticker label you see in the window of new cars. A global standard called the Monroney Label, named after U.S. Senator Mike Monroney, requires these stickers to list all the components of new automobiles. Unlike nutrition facts that may get ignored, if you are buying a new car, you probably take at least one look at the sticker with the inventory of components included in the car. SBOMs should be reviewed and analyzed regularly not only for EOL packages, but also for disclosed vulnerabilities and licensing information about each component.

Learn more about the relationship between SBOMs and software documentation >>

New Software Bill of Materials Requirements

Generating up-to-date SBOMs for all software is an important first step to improve the security of the software supply chain. To that end, the U.S. government has promoted various initiatives, including the Securing Open Source Software Act, to mandate the generation of SBOMs. The National Cybersecurity Strategy also highlights the SBOM generation and, for the first time, introduces liability for software vendors that do not secure their software. Another important initiative is from the U.S. Food and Drug Administration (FDA); the FDA recently issued a guideline for new medical devices requiring security monitoring and SBOMs.

Understanding the Software Supply Chain and SBOMs

Sometimes misunderstood as the software provided by vendors to perform operational or support tasks, the software supply chain is a layer below the finished software product. All software is based on other software — the “building blocks” of which are open source — and composed of many (sometimes thousands) of libraries or components as well as the overall “supply chain” of tools to develop, build, and publish software.

It is no longer in question that commercial software includes open source software. The free and open nature of open source software, with appropriate open source licenses, allows businesses of all sizes to build commercial software for an infinite number of use cases.

Organizations creating, operating, and consuming software need SBOMs across their software supply chains. With open source software, the code is available to anyone to review and even run a security scan to identify vulnerabilities; however, commercial software does not publish the source code. Therefore, it’s more important to generate and publish SBOMs reporting the components used to build the commercial software.

Going back to the Monroney label on a new car analogy, if a reported defect triggers a recall, the inventory of components on the window sticker can help you identify if your car is impacted. This applies to open source and commercial software as well; the community and vendors let users and customers know when there is a defect and provide the corresponding fix in the form of a software release or patch. An email or notification reporting a “software recall” would be a great added value by software vendors and open source communities.

Why You Need a Software Bill of Materials (SBOM)

Open Source Tools to Generate SBOMs

The predominant open standards for the format of SBOMs are SPDX ISO/IEC 5962:2021 and OWASP CycloneDX. These SBOM formats include information for each identified software package, including associated open source license or copyright information, versions, dates, and known security vulnerabilities, or CVEs, in the software.

The growing awareness around open source security and SBOMs have created business opportunities for vendors offering commercial software for application security and SBOM generation. Like all areas and categories of software, there are plenty of open source software options to pick from. 

Here are some open source SBOM tools that the OpenLogic team has recently evaluated:

Dependency-Track 

This is an open source project by the OWASP Foundation. It’s an intelligent component analysis platform used for visualizing vulnerabilities across projects and graphing the top vulnerabilities. It can scan operating systems, all components, and libraries. Generates SBOMs in CycloneDX format and requires a REST API for integration.

Open Source Code: https://github.com/DependencyTrack/dependency-track

SBOM Tool

Open-sourced by Microsoft's security team, SBOM Tool generates SBOMs in the SPDX 2.2 format. Unlike Dependency-Track, it doesn't provide vulnerability information, but has very complete SBOM content, functionality, and dependency trees. It can also generate SBOMs from Docker images. However, it has limited output options compared to other tools like Syft and CycloneDX-CLI.

Open Source Code: https://github.com/microsoft/sbom-tool#Contributing

Syft and Grype

Syft is an easy-to-use open source CLI tool for generating SBOMs from container images and filesystems. Includes vulnerability detection with the Grype scanner. Syft can also convert between multiple SBOM formats. Both tools are easy to install and use in CI/CD pipelines. Syft can also send SBOMs to Dependency-Track.

Open Source Code: https://github.com/anchore/syft

CycloneDX-CLI

CycloneDX-CLI is a CLI open source tool used for generating SBOMs in CycloneDX format. It is compatible with various ecosystems and security databases, and it can be used to scan packages and containers for vulnerabilities. The tool can also convert between multiple SBOM formats and has a simple interface. However, it does not have pipeline integration capabilities like Syft and Grype.

Open Source Code: https://github.com/CycloneDX/cyclonedx-cli

OSV-Scanner

OSV-Scanner is an open source project by Google and part of the efforts for a distributed database of vulnerabilities for open source. OSV-Scanner is a frontend to the OSV database that connects a project’s list of dependencies with the vulnerabilities that affect them. Creates SBOMs with vulnerability information in a tabular or JSON format.

Open Source Code: https://github.com/google/osv-scanner

Comparison of Open Source SBOM Tools

Analysis and table by Lance Dillon, OpenLogic Support Engineer

Many more open source tools are available that focus specifically on SBOMs instead of full commercial software composition analysis (SCA) platforms, with features targeted to security teams and integration with other application security offerings such as SAST, DAST, and IAST.

Final Thoughts 

With so many free open source tools available, there is no excuse not to generate SBOMs, and request SBOMs from your software vendors. In the 2024 State of Open Source Report, we asked respondents about their organization’s level of open source maturity and one of the markers we used was SBOM generation. The report revealed that about 20% of organizations currently generate SBOMs, and the prevalence is higher in certain industries — banking/insurance/financial services and healthcare/pharma are leading the charge. Hopefully the practice of generating SBOMs will continue to become more widespread and we’ll see even greater numbers in next year’s report.   

Need Support for Your Open Source Infrastructure?

Unlock all the benefits of community open source with direct access to experienced Enterprise Architects, guaranteed SLAs, and up to 24/7/365 technical support.

Talk to OpenLogic

Additional Resources

• Blog - Creating a Software Bill of Materials
• Blog - How Does Open Source Licensing Work?
• On-Demand Webinar - Open Source Security and Compliance
• Guide - Enterprise Application Security 
• Blog - Debunking Open Source Software Security Myths
• Blog - Understanding CVEs and CVSS Scores
• Video - Open Source Software Compliance