SBOMs Explained

Key Takeaways

• A Software Bill of Materials (SBOM) lists all of the open-source and third-party software packages used in an application
• This can be used to monitor and assess security, license compliance, and other risks from third-party software.
• There are multiple SBOM formats the most common being CycloneDX and SPDX
• SBOMs can be generated programmatically and incorporated into the software build process.

What Is an SBOM, Anyway?

Modern software is assembled using open source packages to innovate faster and focus on the unique aspects of the project. The software development process now closely resembles a traditional manufacturing process, where open source components act as parts and raw materials which are assembled into new products.

A Bill of Materials (BOM) in traditional manufacturing is a list of all raw materials, manufactured parts, and quantities that make up the final product. It’s useful for compliance, risk management, and product safety, as flawed or defective components can be identified quickly at all stages of manufacturing and distribution.

A software bill of materials (SBOM) is a list of all packages and libraries included in your application. It’s the digital equivalent of a manufacturing bill of materials. Just as a bill of materials includes all sub-assemblies, the SBOM also includes transitive dependencies or your components’ dependencies. And just like a traditional BOM, the SBOM makes it easy to see if any risky packages are included in an application.

A software bill of materials is the first step toward taking control of your projects’ dependencies and managing risk from open source components. In recent years, the number of cyberattacks targeting open source components has skyrocketed, with software supply chain attacks increasing 300% in 2021 alone. SBOM’S give you insight into your dependencies and can be used to look for vulnerabilities, license issues, and other risky components. Some vendors require an SBOM when purchasing software as a way to manage their own security. The US National Telecommunications and Information Administration jointly published guidelines for software bills of materials, laying the groundwork for requiring SBOMs from vendors in the future. These standards outline the minimum requirements for an SBOM which includes information about its use. The minimum requirements include the following:

• Data Fields – The required data fields provide general information for component identification and include Supplier Name, Component Name, Version, Dependency Relationship, Author of the SBOM, and the time the data was added to the SBOM.
• Automation Support – The SBOM must include support for automatically generating and parsing. A goal with automation support is interoperability across organizations. An SBOM from one organization should be easy to parse without needing to adopt new tools. Currently, SPDX, CycloneDX, and Software Identification Tags are accepted formats that meet this automation support.
• Practices and Processes – This section outlines requirements for using software bills of materials and offers guidance on frequency, depth, access, and documenting known unknowns.

Read NITA’s full specification here.

Why Do I Need an SBOM?

The core benefit of a software bill of materials is a consistent, readable profile of your application’s dependencies. This report can be automatically generated during your project’s build step to ensure you always have up-to-date dependency information. SBOMs also standardize the way your dependencies are listed, which makes reviewing them consistent and easy, regardless of the ecosystem. This means that for developers and security professionals, the software bill of materials is a great way to check for newly disclosed vulnerabilities. This standardization also makes automation easier. For example, Nexus Lifecycle’s InnerSource Insight feature natively only supports Java and npm without an SBOM but works with over a dozen ecosystems if there is a software bill of materials.

Standardizing dependency data also makes it possible to share this information. Providing a software bill of materials in a standard format means that your customers will know how to consume that information.

Are All SBOMs the Same?

The idea of a standardized list of libraries and software components isn’t new. Over time, various software groups have created a few different formats for a software bill of materials, each with its own aims and advantages. Here are the two most common SBOM formats:

• CycloneDX – This is the SBOM format created by the Open Web Application Security Project (OWASP) and was built with cybersecurity in mind. This is our favorite at Sonatype and the SBOM format we support in our products. The largest benefit of CycloneDX is the ability to include vulnerability information in the SBOM or link to a separate Vulnerability Exploitability Exchange (VEX) which lets you indicate false positives alongside component vulnerability information.
• SPDX (Software Package Data Exchange) – This format was developed by the Linux Foundation to make collecting and sharing package data easier. The main focus of this format is license compliance rather than security.

Both CycloneDX and SPDX meet the National Telecommunications and Information Administration’s minimum requirements for a Software Bill of Materials. Here’s an example of a CycloneDX 1.4 SBOM.

<?xml version="1.0" encoding="UTF-8"?>  
<bom xmlns="http://cyclonedx.org/schema/bom/1.4" serialNumber="urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79" version="1">  
  <metadata>  
    <component type="application" bom-ref="acme-app">
      <name>Acme Application</name>
      <version>9.1.1</version>  
    </component>  
  </metadata>  
  <components>  
    <component type="library">  
      <name>acme-library</name>   
      <version>1.0.0</version>
      <hashes>
        <hash alg="SHA-1">9188560f22e0b73070d2efce670c74af2bdf30af</hash>
        <hash alg="SHA-256">d88bc4e70bfb34d18b5542136639acbb26a8ae2429aa1e47489332fb389cc964</hash>
      </hashes>
      <cpe>cpe:/a:acme:application:9.1.1</cpe>
    </component>
    <component type="library">
      <group>com.fasterxml.jackson.core</group>
      <name>jackson-databind</name>
      <version>2.8.0</version>
      <licenses>
        <license>
          <id>Apache-2.0</id>
        </license>
      </licenses>
      <purl>pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.8.0?type=jar</purl>
    </component>
  </components>
  <vulnerabilities>
    <vulnerability>
      <id>CVE-2018-7489</id>
      <source>
        <name>NVD</name>
        <url>https://nvd.nist.gov/vuln/detail/CVE-2019-9997</url>
      </source>
      <ratings>
        <rating>
          <source>
            <name>NVD</name>
            <url>https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H&version=3.0</url>
          </source>
          <score>9.8</score>
          <severity>critical</severity>
          <method>CVSSv3</method>
          <vector>AN/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H</vector>
        </rating>
      </ratings>
      <cwes>
        <cwe>184</cwe>
        <cwe>502</cwe>
      </cwes>
      <description>FasterXML jackson-databind before 2.7.9.3, 2.8.x before 2.8.11.1 and 2.9.x before 2.9.5 allows unauthenticated remote code execution because of an incomplete fix for the CVE-2017-7525 deserialization flaw. This is exploitable by sending maliciously crafted JSON input to the readValue method of the ObjectMapper, bypassing a blacklist that is ineffective if the c3p0 libraries are available in the classpath.</description>
      <recommendation>Upgrade com.fasterxml.jackson.core:jackson-databind to version 2.6.7.5, 2.8.11.1, 2.9.5 or higher.</recommendation>
      <advisories>
        <advisory>
          <title>GitHub Commit</title>
          <url>https://github.com/FasterXML/jackson-databind/commit/6799f8f10cc78e9af6d443ed6982d00a13f2e7d2</url>
        </advisory>
      </advisories>
      <created>2021-01-01T00:00:00.000Z</created>
      <published>2021-01-01T00:00:00.000Z</published>
      <updated>2021-01-01T00:00:00.000Z</updated>
      <analysis>
        <state>not_affected</state>
        <justification>code_not_reachable</justification>
        <responses>
          <response>will_not_fix</response>
          <response>update</response>
        </responses>
        <detail>An optional explanation of why the application is not affected by the vulnerable component.</detail>
      </analysis>
      <affects>
        <target>
          <ref>pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.8.0?type=jar</ref>
        </target>
      </affects>
    </vulnerability>
  </vulnerabilities>
  <dependencies>
    <dependency ref="acme-app">
      <dependency ref="pkg:maven/org.acme/web-framework@1.0.0?type=jar" />
      <dependency ref="pkg:maven/org.acme/persistence@3.1.0?type=jar" />
    </dependency>
    <dependency ref="pkg:maven/org.acme/web-framework@1.0.0?type=jar">
      <dependency ref="pkg:maven/org.acme/common-util@3.0.0?type=jar" />
    </dependency>
    <dependency ref="pkg:maven/org.acme/persistence@3.1.0?type=jar">
      <dependency ref="pkg:maven/org.acme/common-util@3.0.0?type=jar" />
    </dependency>
    <dependency ref="pkg:maven/org.acme/common-util@3.0.0?type=jar" />
  </dependencies>
</bom>   

SBOMs for Creators

For the organizations building a project, maintaining a bill of materials is a useful way to track a project’s dependencies. Keeping track of the exact package versions in your application makes finding vulnerable components easy. By using a single standard for storing dependency information, your developers and security teams are able to use a standardized process to find vulnerable components which will be more consistent and reduce the cognitive burden of working across ecosystems.

SBOMs for Consumers

For those using, consuming, or purchasing an application, a software bill of materials is useful in two ways. The first is when assessing a product before purchasing, and the second is to monitor their organizational risk from third-party applications.

Assessment

When a customer is considering a new product, providing a software bill of materials allows your customers to be certain your product meets their internal security and architectural requirements. The insight into your product gives them additional confidence in the security of the application. It is a more transparent way to operate. Given that nearly all software leverages open source components, third-party software with an SBOM is less risky than software without because a customer is able to monitor their attack vectors. This brings us to the second use; monitoring third-party risk.

Monitoring

Customers can use the SBOM you provide to monitor their own security. Many tools, including Nexus Lifecycle, can scan an SBOM and generate a list of vulnerabilities based on the component IDs listed in the bill of materials. This allows you to manage your own security even when using proprietary third-party software.

How Do I Generate SBOMs?

Generating a software bill of materials with an automated tool is simple. Nexus Lifecycle can create SBOMs through the user interface or with an API request, and CycloneDX provides a number of tools that can programmatically generate SBOMs on demand or during your build process. Check out the CycloneDX Tool Center for more.

Nexus Lifecycle can generate an SBOM for any scanned application with the click of a button. To generate a software bill of materials with the Lifecycle UI:

• Scan an application with Nexus Lifecycle
• Follow the link in the policy evaluation (if scanning from the CLI) or navigate to the scan the report through the UI
• Click the Options dropdown in the upper right
• Click View SBOM

• To save this file, right-click anywhere on the page and select the Save as… option.

When Should I Share an SBOM?

The information in a software bill of materials contains information on the composition of your software and can be used to identify potential vulnerabilities in your application. This means that you want to use some discretion on when and how you share your SBOM. For projects where the source code is proprietary or private, we recommend making the software bill of materials available to your existing customers and to qualified leads.

Open source projects incur little risk from maintaining a publicly available software bill of materials. The dependency information for the project is already publicly available, and a public SBOM could be useful to members of the community particularly interested in security and license compliance.

As a best practice, we strongly recommend creating a public advisories page to call out false positives in your product. While this information should be included in a VEX along with your SBOM, making this information publicly available offers additional transparency and gives your users another way to monitor their safety.

Additional Resources

• Understanding the Parts of a Policy
• IQ Server and Repository Management
• Learning Course: Organization Policies in Lifecycle

Talk to Us

Have more questions or comments? Learn more at help.sonatype.com, join us in the Sonatype Community, and view our course catalog at learn.sonatype.com.

And visit my.sonatype.com for all things Sonatype.