Last month, we wrote about how companies are using Software Bill of Materials (SBOMs), even if they are not legally required to because they do not sell to the US federal government. According to the 2022 Synopsys Open Source Security and Risk Analysis Report, 97% of the more than 2400 codebases they evaluated contained open source. Synopsys states that “code owners aren’t even aware of the open source components in their own software.”

Companies that create and maintain SBOMs discover exactly which components are in their software, allowing them to:

• Respond better to security risks by patching or avoiding vulnerable components
• Plan and replace components that are reaching end-of-life
• Remediate bugs faster
• Comply with third-party component licensing
• Provide a superior customer experience, including downstream developers in the supply chain
• Reduce the effort of the developers who build and maintain the applications

If code owners are possibly not aware of every open source component hidden in the thousands of lines of code of their applications, how do organizations get started creating and updating their SBOM? Is it possible to build your own SBOM solution? What should you look for in an SBOM tool?

SBOM standards

There are three SBOM standards: SPDX, SWID, and CycloneDX. Organizations should work in one standard to reduce rework across teams and companies.

The Software Package Data Exchange (SPDX) is an open source project hosted by the Linux Foundation. According to Gartner, SPDX is the most widely adopted standard. SPDX Specification 1.0 was initially released in 2010, long before the current focus on SBOMs. As of August 2021, it is recognized as an international open standard for security, license compliance, and other software supply chain artifacts as ISO/IEC 5962:2021. Examples of SPDX formatted SBOMs can be found in the GitHub repository.

Software Identification (SWID) tags, defined by the ISO/IEC 19770-2:2015 standard, support the automation of software inventory as part of a software asset management process. SWID is supported by the National Institute of Standards and Technology (NIST). SWID tools and examples can be found in NIST’s GitHub repository.

The third standard, CycloneDX, started in 2017 as part of OWASP. Learn how to consume and create CycloneDX SBOMs with the tools in their GitHub repository.

SBOM Tool Requirements

Whether you create your own SBOM or buy a solution off the shelf, you should look for the following capabilities:

1. Does it support the SBOM standard you have chosen from above?
2. Does it capture all of the data fields that are required? Along with the component names, SBOMs should include the supplier name, version information, license information, time stamp, author of the SBOM data, and any known vulnerabilities of all included components.
3. Does it support automation? It should support the automatic generation of SBOMs to update the SBOM with every new version of each artifact. Last month, we discussed how software composition analysis (SCA) tools can scan codebases to help prevent developers from missing a component in the code. It also needs to be machine-readable to support automation and consumption by other SBOM tools up and downstream from your application.
4. Is it human-readable?

SBOM: Build or Buy?

There are several open-source and commercial SBOM tools on the market.

Here are just two of the tools that ReleaseTEAM can help you evaluate and implement:

JFrog Xray supports both SPDX and CycloneDX standard formats, provides SCA capabilities, and is machine-readable. It also boasts a Jira integration that alerts developers when Xray discovers a vulnerability.

Sonatype Nexus Lifecycle supports SPDX and CycloneDX standards and provides SCA capabilities. Sonatype even has a free SBOM generator that uses the Nexus Vulnerability Scanner.