Best Practices for Software Bill of Materials (SBOM) Management

Properly managing a Software Bill of Materials, or SBOM, has always been a best practice from a security and compliance point of view. However, it gained special urgency in May 2021, when the White House issued an executive order that requires software vendors who work with the federal government to provide SBOMs for their products.

Whether your business sells to U.S. government agencies or not, now is a good time to make SBOM management a core part of your process for building and shipping software. This article defines what an SBOM is, explains why it’s important and offers tips for SBOM management.

What is a Software Bill of Materials?

A Software Bill of Materials is a list of the components that form a piece of software, as well as relevant metadata (such as licensing information) about those components.

Common elements of an SBOM include:

Open source libraries that an application imports or depends on.
Plugins, extensions or other add-ons that an application uses.
Custom source code written in-house by developers.
Information about the versions, licensing status and patch status of these components.

In addition, an SBOM for a SaaS application could include information about APIs or third-party services that are required to run the SaaS application.

Why is an SBOM important?

From a security perspective, SBOMs matter because they help organizations ensure that the software they use is up-to-date and patched against known security vulnerabilities. Businesses can also use an SBOM to identify applications that place them at risk because they are subject to a known security flaw that has not yet been fixed.

In addition, the licensing information included in SBOMs can help businesses ensure that they comply with licensing requirements when using software. For example, an open source library that a software vendor incorporates into an application it sells may include licensing terms mandating that the original authors of the library receive attribution within documentation related to the library. With an SBOM, an organization that uses the library would know to include attribution information within its documentation.

The security and compliance advantages of SBOMs have always been important. However, SBOMs have become especially critical today, for two main reasons. One is the prevalence of open source software, which 72 percent of companies now use internally or as part of commercial products, according to the Linux Foundation. SBOMs help ensure that businesses use open source in a secure and compliant way.

At the same time, security risks related to the origin of software have become a major concern for businesses recently, in large part due to software supply chain attacks with massive impact such as the SolarWinds breach that was first reported in 2020. The attack, which involved the insertion by attackers of malicious code into commercial monitoring software that was widely used by government agencies and other organizations, highlighted the way in which attackers can compromise targets by gaining access to the software that the targets use. The White Houseexecutive order of 2021 was a response in part to this risk.

Watch the On-Demand Webinar: Creation of Your SBOM

WATCH ON-DEMAND WEBINAR

Best practices for Software Bill of Materials management

Again, although the executive order formally applies only to software vendors that sell to the U.S. federal government, properly creating and managing SBOMs for software that you distribute is a good idea from a security and compliance perspective regardless of whether it’s an official requirement. SBOMs are also something that more and more businesses are likely to demand from their vendors going forward, which means that SBOM management will help software companies remain competitive in the marketplace.

The following best practices can help developers create and manage SBOMs efficiently and effectively.

Use a consistent SBOM format

One basic best practice is to ensure that you follow a standard format when structuring SBOM data.

Several popular SBOM formats exist, including SPDX, SWID and CycloneDX. It’s up to you which one to use; the 2021 SBOM executive order doesn’t mandate a specific SBOM format, and to date, no industry standard has emerged.

But whatever you do, what matters is to be consistent. Your customers will derive greater value from an SBOM if you follow the same formatting conventions and include the same types of information in each SBOM.

Automate SBOM creation

Automatically generating SBOMs as part of your software delivery pipeline provides two key benefits. First, it saves developers from having to build each SBOM manually, which in turn makes it possible to achieve what the National Telecommunications and Information Administration calls “machine-speed” SBOM generation. Instant generation of SBOMs is critical if SBOMs are to become a common part of the software delivery cycle.

Second and most important, automated SBOMs that are generated as part of the CI/CD process can be cryptographically signed and verified. This allows you to prove to your users that what you list in the SBOM is what is actually in the software you deliver. Without automatic signing of pipeline components (which is a feature supported in JFrog Artifactory through Pipeinfo), SBOM authenticity would be difficult to verify, which would undercut the value of having an SBOM in the first place.

Update your SBOM with each release

It almost goes without saying that SBOMs need to be specific to each application release, and that developers should update the SBOM every time they update the application. However, because developers who create SBOMs manually may struggle to update their SBOMs with each release, it can be easy to fall into the trap of creating an SBOM once and updating it only periodically.

If you automatically generate the data that goes into an SBOM as part of the software release cycle, however, you can easily update the SBOM every time you add or remove a dependency or change the version of a component. Doing so ensures that your SBOMs are accurate, and that your customers will know definitively whether they are affected by vulnerabilities or licensing mandates associated with a specific version of your product.

Include full metadata in your SBOM

The lack of universal standards for SBOM formatting means that some SBOMs include more metadata (meaning information such as licensing and patching status) than others, because some SBOM formats require more metadata than others.

As a developer, however, you should strive to include as much metadata as possible in each SBOM. Including data about licenses and patches directly in the SBOM saves your customers from having to look up that information manually. It also positions you to update vulnerable components of your product more quickly in the event that a security flaw is announced in one of the components you ship.

Provide SBOMs for SaaS

To date, most of the discussion surrounding SBOMs has focused on applications that organizations install themselves, either on-premises or in the cloud. However, it’s a best practice to provide SBOMs for SaaS applications as well.

This may seem counterintuitive. Under a SaaS architecture, customers don’t install applications on their own infrastructure. They also aren’t typically responsible for managing licenses or patches related to the software. There might therefore seem to be little reason to create SBOMs for SaaS platforms.

Nonetheless, providing SBOMs for SaaS applications can alert customers to situations where the SaaS platform may be compromised due to a vulnerability. Even if customers don’t have to fix the vulnerability themselves, knowing about it can help them achieve their own security goals.

HOW JFROG CAN HELP
JFrog Xray’s SBOM latest capabilities support the SPDX and CycloneDX standard formats. Xray security tool creates SBOMs with a machine-readable inventory of software components and dependencies, lets you export SBOMs in both of these standard formats.