Understanding and Implementing a Software Bill of Materials

Software programs today can be likened to a complex stew, with multiple ingredients sourced from disparate places. In software, open-source tools are a major ingredient.  According to the 2020 Open Source Security and Risk Analysis (OSSRA) report produced by the Synopsys Cybersecurity Research Center, 99 percent of the codebases contain at least one open source component, with open source comprising 70 percent of the code overall.

A critical component of DevSecOps is maintaining and monitoring the growing number of third-party components (open source and proprietary) that make up modern software. Increasingly, engineering teams are using a software bill of materials (SBOM) to help them with this work.

Although the concept of a Software Bill of Materials (SBOM) is not new, it has recently come into prominence due to several key events. First, a number of attacks on companies’ software supply chains including Solarwinds and Codecov revealed the importance of having full visibility into a software’s supply chain. This year has also seen an increase in attacks on public repositories (e.g., NPM registry and PyPi).

Next, is the May, 2021 U.S. Presidential Executive Order on Improving the Nation’s Cybersecurity. The order contains a provision that requires software vendors to the U.S. federal government to provide SBOMs. The Solarwinds hack was one of the cited reasons for the SBOM provision in the executive order.

In this article, we’ll explain:

• What an SBOM is
• Which organizations need an SBOM
• Benefits of creating and using an SBOM
• Misconceptions about SBOMs
• The importance of SBOMs in package management

What is a software bill of materials (SBOM)?

So, exactly what is an SBOM? In brief, an SBOM is a list that contains all of the components and dependencies in a piece of software. The Nation Telecommunications and Information Administration (NTIA), the U.S. government agency tasked with developing federal standards from SBOMs, defines them as,  “a formal, machine-readable inventory of software components and dependencies, information about those components, and their hierarchical relationships.”

SBOMs should include open source and proprietary software and should explicitly state if there are any missing elements to the inventory.

Watch our very own Dan McKinney discuss what SBOMs are in depth, and what SBOMs should looks like for your applications in our webinar with Security Weekly.

Minimum required elements of an SBOM

Following the release of the executive order, NTIA published the following minimum required elements of an SBOM. Note, that these guidelines currently only apply to vendors of the U.S. federal government, but they are a helpful reference for any organization interested in developing an SBOM.

Read on for a list of the minimum elements of SBOMs:

1. Data fields

Data fields contain baseline component information about each element of the software that should be tracked and maintained. This information includes:

• Supplier name
• Component name
• Version of the component
• Other unique identifiers
• Dependency relationship
• Author of SBOM data
• Timestamp

2. Automation support

This section of the minimum requirements document stresses the need for tooling that “allows the ability to scale across the software ecosystem, particularly across organizational boundaries.” The federal government requires vendors to use one of the following formats to generate SBOMs:

• Software Package Data eXchange (SPDX)
• CycloneDX
• Software Identification (SWID) tags

Note, these are not the only formats to create SBOMs. We will go into more detail about these and others in a later section.

3. Practices and processes

The following “practices and processes” outline how and when updated SBOMs should be delivered:

• Frequency - A new SBOM must be created to reflect a new build or release of a software component.
• Depth - An SBOM should include all primary components with their dependencies listed.
• Known unknowns - The SBOM author should explicitly state when the presence of dependencies is unknown and differentiate that from a component that has no dependencies.
• Distribution and delivery - SBOMs should be made available to those who need them in a timely fashion.
• Access control If an organization chooses to keep an SBOM private, it must specify terms of access control and accommodate integrating SBOM data into a user’s security tools.
• Accommodation of mistakes - Consumers of SBOMs are advised to be tolerant of mistakes and errors, as this standardization process is still new.

SBOM formats, specifications, and delivery

As mentioned previously, there are currently three SBOM formats approved by the federal government to deliver SBOMs:

• Software Identification (SWID) Tagging
• Software Package Data Exchange (SPDX)
• Cyclone Dx

Processes and integrations are also emerging as a result of increased adoption of SBOM, and a growing list of tools both open source and commercial are being developed and used.

Who needs an SBOM?

Any organization that produces, purchases, or operates software will benefit from an SBOM. Common use cases include:

• Regulatory compliance In addition to the U.S. federal government, heavily regulated industries like healthcare and financial services require software vendors with secure products. Many may require an SBOM as a part of the purchasing process.
• Merger and acquisition due diligence - An acquisition target can use an SBOM to demonstrate sound architecture and technical proficiency. This can also help the buyer better understand the software of their target.
• Vulnerability remediation - Engineers can use SBOMs to monitor vulnerabilities across their company’s software. Upon receiving a notification about a vulnerability, a developer can then use the SBOM to find all instances of the affected software and patch the problem.

Learn more about what SBOMs look like for an organization’s applications in our webinar with SecurityWeekly.

SBOM misconceptions

One new or unfamiliar to the concept of SBOMs might be justifiably concerned that SBOMs might be an avenue for hackers to see into their infrastructure. On the surface, an SBOM may seem like a public-facing document that tells unwanted parties everything they need to know about your tools and software components.

These are both common misconceptions. First, nefarious actors do not require SBOMs to stage attacks. For example, botnets used to stage DDoS attacks are broad and take advantage of the probability that some IoT devices will be unsecured or lack up-to-date firmware. The SBOM is really a defensive document that gives you the ability to counter attacks and correct vulnerabilities as quickly as possible. Secondly, an SBOM does not need to be made available to the general public. You may need to provide an SBOM to a customer, but this can be done directly, avoiding the exposure of a public website.

Why use an SBOM?

While an obvious benefit of creating and using an SBOM is reducing the chance of a supply chain attack like the Solarwinds hack, there are some additional benefits of creating an SBOM including:

• Generating customer loyalty by providing increased visibility into the tools that you use.
• Better license management; more visibility into the software reduces risk of using non-compliant software.
• Reducing business disruption during audits.
• More easily identifying redundant or excessive coding, reducing code bloat.
• Reducing operational costs by preventing developers from manually searching for vulnerabilities.

The importance of SBOMs in package management

Package managers in and of themselves are not SBOMs. However, they do contain a large amount of information including third-party applications and some dependencies that will eventually be in the SBOM. The CycloneDX SBOM specification (mentioned earlier) has tools to enable engineers to generate SBOMs from package manager manifests.

Cloudsmith is also an important tool for engineering teams securing their supply chain and staying in compliance with an increasing number of regulations. As a single source of truth for all your software assets, Cloudsmith is the only cloud-native, universal package management solution, allowing your organization to create, store and share packages in any format, to any place, with total confidence.

If you or your organization are looking for a cloud-native, universal package repository solution, contact us at Cloudsmith and we’d be more than happy to help.

If you’d rather try out the Cloudsmith platform for yourself first, we offer a 14-day free trial, with detailed documentation and video guides on the Cloudsmith YouTube channel to help you get started!

Liked this article? Don\'t be selfish (:-), share with others:   Tweet