How to Generate and Host an SBOM

Generating and Hosting SBOMs

The first step to securing your software is knowing what is in your software. Generating a Software Bill of Materials (SBOM) for your builds can limit the impact of critical vulnerabilities like Log4J by driving actions to update software or prevent the deployment of vulnerable artifacts.

SBOMs have been getting increased attention since the US President’s executive order mandated that organizations selling into the U.S. federal government are required to provide SBOMs. The National Telecommunications and Information Administration (NTIA) published the minimum elements for an SBOM for the US government and described use cases for greater transparency in the supply chain. The OpenSSF team released their 10-point Mobilization Plan, which included a plan to improve SBOM tooling and training to drive adoption.

Open source tooling, including Sigstore, CycloneDX, Syft, Grype, and Trivy, help to automate SBOM workflows and integrate them into software pipelines.

Cloudsmith's artifact repository integrates with Sigstore's Cosign tooling which allows you to host SBOMs in an OCI registry and will be staying closely aligned to all the package ecosystems as they evolve their tooling to support SBOMs.

Today, I’ll go through:

An overview of SBOMs.
How and when to generate an SBOM, including a list of open-source software (OSS) tooling to help you.
Hosting your SBOM.
Other SBOM considerations.

My next article will detail tools to analyze SBOMs for vulnerabilities, and how Cloudsmith can then quarantine your images if the vulnerability is above a certain vulnerability threshold.

SBOM Overview

The SBOM lists all components, including licenses and dependencies contained in a software product and other data, including version, supplier, identifiers e.g PURL and author. The software end-user can use the SBOM to perform vulnerability and license analysis of their software packages, which can help evaluate a software product's risk. SBOMs are designed to be machine-readable, and available in either JSON or XML formats.

An SBOM in a known format can help drive automation and trigger security alerts. The two major formats of SBOMs are SPDX and CycloneDX.

To understand more about SBOMs and their use cases, check out this curated list of sbom tools and resources or discover some resources that the NTIA has published.

You can also read Cloudsmith’s blog on Understanding and Implementing a Software Bill of Materials

How and When to Generate an SBOM

The NTIA recommends generating an SBOM for every new release of a component. This SBOM can be generated on the source code, at build-time, at runtime, on the binary, or on a container image.

Indeed. There is no perfect way to create an SBOM. Producing them at build time, at runtime, or during forensics all have different advantages and trade offs. It’s best to understand the target audience for the SBOM, type of data, and choose one or more approaches that deliver.
— Steve Springett (@stevespringett) March 21, 2022

no perfect way to create an SBOM

SBOMs generated during various phases of the build process are beneficial depending on the audiences, purposes, or if you are dealing with legacy code. That being said, in NTIA's paper Framing Software Component Transparency and CNCF's paper on Software Supply Chain Best Practices, they recommend generating SBOMs at build-time. Build-time generators are more complete and accurate, especially regarding dependencies but it is not always possible to generate an SBOM at build-time.

Let's go through the different stages of the build lifecycle an SBOM can be generated and the tools to help you with an emphasis on OSS tools - I’ve included:

Software Composition Analysis (SCA) and Binary analysis tools.
Build-time tools.
Container SCA tools.
Runtime tools.

Software Composition Analysis (SCA) and Binary Analysis Tools

Source or binary tools will generate the SBOM by inspection of the artifacts and any associated sources like manifests, metadata, and lockfiles. SCA tools scan the software and its manifest files to identify the included components. Binary Analysis tools use metadata and knowledge about the built artifact type to identify components and can be the only option for identifying components in legacy software.

SCA tools are easy to use, align with ‘shift left’ security principles, integrate into your CI/CD, and output in standard formats. An SBOM created at the source code stage can be used with a vulnerability analyzer to alert you to vulnerabilities early and automatically in the development lifecycle.

SCA and binary tools include:

CycloneDX has developed a lot of tooling for generating SBOMs for each package format at different stages of the build process.
It-Depends is a tool to automatically build a dependency graph and Software Bill of Materials (SBoM) for Go, JavaScript, Rust, Python, and C/C++ projects.
There are a number of proprietary tools including Fossa, Black Duck, AppSonar, Cybellum, and Fortress.

The downside to SCA and binary SBOM generators:

A big disadvantage is that the SBOM generated is not as complete and may not have definitive information on dependencies.
SCA SBOMs may include components only used in dev or testing mode.
It may detail unused software components in the deployed product. As a result, many vulnerability scanners on that SBOM can show a lot of false positives.
If the dependencies are unpinned, SCA SBOMs can’t categorically know what dependency was in the final binary as the package manager has the logic to resolve this.
They are unlikely to generate transitive dependencies.

Build-time

Build-time SBOMs are generated during the compilation of the source code or the software packaging process. NTIA’s paper on software supplier's SBOM production and provision states “Build-time creation of SBOMs typically involves invoking a tool that works natively with the build system being used.....Most development ecosystems have an optional method for creating SBOMs through the use of build plug-ins. These plug-ins integrate with the underlying build and dependency management systems to produce one of the supported SBOM formats.”

Creating the SBOM at build-time with a tool that taps into the build system has the most accurate knowledge of what goes into a binary, including transitive and unpinned dependencies.

Build-time generators:

SPDX SBOM CLI supported by the Linux Foundation lets you generate SBOM information, including components, licenses, copyrights, and security references of your software using SPDX v2.2 specification and aligning with the current known minimum elements from NTIA. It supports a number of package managers including GoMod (go), Cargo, (Rust), Composer (PHP), DotNet (.NET), Maven (Java), NPM (Node.js) and PIP (Python)
This Github action for OWASP's Dependency-Track-Check generates a BoM (Bill Of Materials) of your project and uploads it to an OWASP Dependency Track instance to perform a vulnerability check- Giving you a full workflow in one github action.
The CycloneDX Maven plugin generates CycloneDX Software Bill of Materials (SBOM), containing the aggregate of all direct and transitive dependencies of a project.
CycloneDX (NuGet) SBOM creates an aggregate of all dependencies and transitive dependencies of a project and creates a valid CycloneDX bill-of-material document from the results.
@cyclonedx/bom - npm creates a valid CycloneDX Software Bill-of-Materials (SBOM) containing an aggregate of all project dependencies.
A library for producing CycloneDX SBOM files

The downside to build-time SBOM generators:

The tooling may not be available for your package manager or build system.
Set up and maintenance are more complex than tools at other stages.
It may not be possible to generate a build-time SBOM for legacy products or if you don’t use a package manager to get your dependencies.
It may detail unused software components in the deployed product. As a result, many vulnerability scanners on that SBOM can show a lot of false positives.

SCA tool for Container Images

OCI artifact tools for generating SBOMs currently work on the built image. These tools generate an SBOM by knowing the structure of the layers in OCI images, all the files installed, and the image metadata, and by working with package managers. They can gather the dependencies and transitive dependencies of software installed on a container image for the formats they support.

Docker is working on adding SBOM functionality to ‘docker build’ using BuildKit’s extensibility, allowing these tools to work at build-time.

Container Images generators:

Anchore’s OSS Syft is a CLI tool and Go library for generating a Software Bill of Materials (SBOM) from container images and filesystems. You can also use Syft via the experimental docker sbom command.

The SBOM output of Syft can be used by Anchore’s other OSS SBOM tooling Grype for vulnerability scanning. I’ve forked Dan Luhring’s code from Syft to show how to use Syft, Grype (their SBOM analyzer), Cosign, and Cloudsmith to use SBOMs in an actionable way.
Aqua’s OSS Trivy tool is a simple and comprehensive vulnerability/misconfiguration/secret scanner for containers and other artifacts. One of its many functions is generating SBOMs in Cyclone DX or SPDX for images, filesystems, github repositories, or archives.
Tern is a software package inspection tool that can create a Software Bill of Materials (SBOM) for containers.

The downside to SBOM SCA tools for Containers:

Currently, tools work on a built container image, but Docker is working on adding SBOM functionality to ‘docker build’ using BuildKit’s extensibility.
SCA tools for Containers support many different language ecosystems but not all.
It may detail unused software components in the deployed product. As a result, many vulnerability scanners on that SBOM can show a lot of false positives.

Runtime Tools

Runtime SBOM captures the exact libraries used by the application, in the platform, app server, plugins, or anywhere else. This approach can also include details of services invoked, ports/URIs/geographies the app is accessing, and which libraries are active.

Runtime tools include:

https://github.com/Contrast-Security-OSS/jbom
SCA generators can be run on running containers to generate a runtime SBOM.
https://github.com/deepfence/ThreatMapper/wiki/Generating-runtime-Software-Bills-of-Materials-(SBOMs)

The downside to run time SBOM generators:

The tooling is not widely available.
The workflow for automatically merging it back or updating it to the original SBOM is unclear (I talk later on about how to merge SBOMs).

How to Host SBOMs

How do you host SBOMs, link them to the actual artifact, compare different versions, or track changes in your SBOMs?

Sigstore, cosign, and container registries

Sigstore’s Cosign tooling supports container signing, verification, and storage in an OCI registry. Cosign allows you to attach SBOMs to your container images hosted in container registries.

Cloudsmith’s artifact repository integrates with Cosign, and Cloudsmith’s help docs will show you how to:

Host an SBOM alongside your image by attaching a signed in-toto attribution with the SBOM as the predicate.
Attach an unsigned SBoM to your container image.
Verify the signature of a signed SBOM in an attestation.

This Github Actions workflow forked Dan Luhring’s code from Syft shows how to use Syft, Grype (their SBOM analyzer), Cosign, and Cloudsmith to use SBOMs in an actionable way.

Non-OCI artifacts

The best way to host SBOMs for non-OCI artifacts is not fully understood. There is no standard way, like cosign above, for non-OCI images to store your SBOM alongside your artifact.

To host your SBOM you can use a database, file store, artifact repository, Fortress or OSS tooling like OWASP’s Dependency Tracker or CycloneDx bom-repo-server. An SBOM can be easily hosted and distributed in your Cloudsmith repository as a raw file- all Cloudsmith artifact repositories are multiformat so an SBOM can sit beside the built artifact. Cloudsmith will be staying closely aligned to all the package ecosystems as they evolve their tooling to support SBOM.

Other considerations with SBOMs

Merging SBOMs

As mentioned earlier, you can generate SBOMs at different stages of the software build lifecycle. You may want to gather the information as early in your development as possible but then you want to augment that SBOM with more accurate information generated later.

Melba Lopez, senior technical staff member and lead product security architect at IBM, said it’s “not a true SBOM without analysis from different tools” during her talk at the 2022 Open Source Summit. She recommends creating and validating the accuracy of SBOMs at different parts of the software life cycle.

The CycloneDX CLI tool currently supports BOM diffing and merging as well as a host of other actions like BOM analysis, modification, format conversion, signing, and verification.

Validating SBOMs

Validating your SBOMs is important to make sure that it adheres to the format specs.

Examples of SBOM validation tools include:

SPDX Online Tool validates SPDX format SBOMs: https://tools.spdx.org/app/validate/.
CycloneDX CLI Tool and Web Tool validates CycloneDX format SBOMs: https://github.com/CycloneDX/cyclonedx-cli/ https://cyclonedx.github.io/cyclonedx-web-tool/ .

Verifying SBOMs

Verifying an artifact such as an SBOM implies verifying a cryptographic signature. Signing and verifying an SBOM ensures users know it comes from a trusted source in the software supply chain.

Cosign, mentioned earlier, provides tooling for signing and verifying SBOMs for OCI artifacts. Cosign has an experimental feature of keyless signatures using OIDC and Sigstore tooling. This will make it easier again to sign and manage keys.

SBOMs for other artifacts can fall back to generic methods for signing and verification, like GPG clearsigning. While this requires more effort at key management and is not as well-integrated as cosign, it can provide important end-to-end security guarantees showing that SBOMs were not modified in storage or transit.

Vulnerability Exploitability eXchange (VEX)

VEX which stands for Vulnerability Exploitability eXchange was developed by NTIA and is related to their work on SBOMs. VEX is a machine-readable document populated by vendors that informs consumers of their software if they are affected by a known vulnerability or not.

The NTIA explains that “In many cases, a vulnerability in an upstream component will not be ‘exploitable’ in the final product for various reasons (e.g., the affected code is not loaded by the compiler, or some inline protections exist elsewhere in the software).” VEX solves this problem by providing vulnerability status information for components in an SBOM. VEX can also provide remediation steps if a component is affected by a vulnerability.

It can be a companion artifact or have inbuilt support with your SBOM standard. The SBOM standard Cyclone DX has support for referencing or embedding VEX BOMs.

Listen to Jens Wiesner and Allan Friedman’s talk, IATC - Your critical system IS (NOT?) vulnerable: CSAF, VEX, SBOM and the future of advisories at BSides Las Vegas in 2021, for more information on VEX and its connection to SBOMs.

Tools to help generate, consume and validate VEX include Secvisogram, Grype, Fortress, and FACT.

GitBom

GitBom is a scheme based on git to help build-time tools generate precise artifact dependency graphs with zero developer effort, involvement, or awareness. It is designed to compliment SBOMs.

For this to work, package managers and other build tools will need to make changes to add GitBom functionality. Proof of concepts exist for this in LLVM, Go, Rust, and bomsh build tools. Aeva Black gave a talk on GitBom at the Cloud Native Security Con EU 2022 Talk.

Issues with SBOMs

Even with advances in SBOM tooling and adoption, important questions still remain. How do you know how complete your SBOM is? What tools and at what stage is the most accurate SBOM? If you merge 2 inaccurate SBOMs, is the result better?

Other issues limiting adoption include:

The tooling doesn’t exist for easy, accurate, and automated workflows for all ecosystems. Ecosystems that don’t have a package manager, like C, are particularly difficult.
A complete SBOM that includes transitive dependencies and external services documented is not generated by all tools and may not be possible to calculate depending on the stage in the build process you run the tool.
Creating an SBOM at the build lifecycle integration, and package manager level is the most accurate. Using SCA tools is the most common method of generating SBOMs and they can result in less accurate SBOMs.
The best practice for hosting SBOMs outside an OCI is still not well defined.

More tooling and better processes for all ecosystems are needed to make useful and accurate SBOMs everywhere possible. This is where initiatives to improve SBOM tooling and training by the Linux Foundation, NTIA, and OWASP, amongst others, will help.

Conclusion

An SBOM, at its core, answers the question, “what’s in my software?”. An accurate SBOM used with other tooling can quickly and automatically identify and neutralize critical vulnerabilities like Log4J in your software.

After generating and hosting your SBOM, the next step is analyzing SBOMs.

The next blog details open source tools to analyze SBOMs for vulnerabilities and actions like quarantining your images in Cloudsmith for vulnerability management.