4 Ways to Generate an SBOM

SBOMs (software bill of materials) are quickly becoming commonplace in software security and compliance. They help organizations maintain visibility into potential software supply chain security threats, and they play essential roles in enabling compliance with regulatory mandates like the Cyber Resilience Act, PCI DSS, DORA, and many others.

But while the growing need for SBOMs is clear, the best strategy for generating an SBOM isn’t always as evident. There are different types of SBOM tools and processes that are built for different types of software artifacts.

In this blog, we’ll explore four ways of generating SBOMs: from source code, from a binary, from an ecosystem-specific plugin, and from a container. We’ll also walk you through examples of using popular tools to produce each type of SBOM.

Try FOSSA SBOM Management: Request FOSSA Demo

1. Generating an SBOM from Source Code

There are multiple tools that can generate SBOMs based on source code analysis. These include nearly all major software composition analysis platforms, plus several open source options. (However, when generating an SBOM from source, we would strongly recommend that you pay close attention to whether your preferred tool/process supports your application’s programming languages.)

For the purpose of this blog, we’ll walk you through a source code SBOM generation workflow using FOSSA. We’re obviously biased, but FOSSA’s combination of language coverage, component identification accuracy, integration options, and ease-of-use make it a good fit for many generation initiatives.

Using FOSSA to Generate an SBOM from Source Code

Create your free account: Visit app.fossa.com to get started.

Integrate FOSSA with your project: Install the CLI to scan locally or in CI pipelines. Or, connect your GitHub, GitLab, or Bitbucket repo to FOSSA.

Scan the project: FOSSA scans your project for open source components, licenses, and known vulnerabilities.

Generate an SBOM: In the FOSSA UI, go to your project and select "Generate SBOM Report." Or, if you’re using the FOSSA CLI, use the command fossa report attribution --format cyclonedx-json.

Configure contents: Choose the format (CycloneDX, SPDX, or others), data fields, and dependency metadata.

Download or share: Export the SBOM or host it via FOSSA for continuous updates.

2. Generating an SBOM from a Binary File

Although it’s not as common a use case as generating an SBOM from source code, there are times when teams may need to generate an SBOM from a binary file. This tends to be the case when teams purchase software from a supplier that does not provide source code access. (Even if the supplier provides an SBOM to accompany the software, the purchaser may want to produce an SBOM from the binary file for the purposes of SBOM comparison and validation.)

There are fewer options for teams looking to produce binary SBOMs than source code SBOMs — you’ll need to find something that can decompose the actual content of the binary, which can be difficult — but there is still a mix of free and commercial tools. This includes FOSSA (which can generate SBOMs from source code, containers, and binaries), Reversing Labs, and Blint (an OWASP open source project with binary SBOM capabilities).

Here, we’ll walk you through producing an SBOM from a binary file with the Blint tool.

Using Blint to Generate an SBOM from a Binary

Blint supports Android (apk and aab), ELF (GNU and musl), PE (exe and dll) and Mach-O (x64, arm64) file formats.

Install blint: You can install it using pip:

pip install blint

Scan a binary: To generate an SBOM from a binary, run:

blint sbom -i /directory/with/apk/aab \
  -o bom.json

This command scans the binary, attempts to infer its dependencies, and outputs a CycloneDX SBOM in JSON format.

Additional options: You can enhance the analysis by specifying architecture or using the GitHub action to automate scans in CI/CD pipelines.

You can check out Blint’s repo and view its README for more detailed instructions and context.

3. Generating an SBOM from an Ecosystem-Specific Tool

Teams that produce single-language or single-ecosystem applications may be well served to generate an SBOM with environment-specific tools. The Yocto Project is one such example. It’s widely used in embedded Linux development and supports native SBOM generation using the SPDX format during image builds. (Other ecosystem-specific tools include the CycloneDX Maven Plugin for Maven projects and the npm-sbom command for npm projects.)

Here’s how you can use Yocto to produce an SBOM. (You can also reference Yocto’s docs page for more complete context.)

Using Yocto to Generate an SBOM

Enable SBOM generation: Note this step is not necessary if you use the Poky reference distribution, which has SBOM generation pre-enabled. If you don’t use Poky — in your Yocto layer’s local.conf, add:

INHERIT += "create-spdx"

Run the build task: Generate the SBOM by running:

bitbake -c create_spdx <image-name>

Retrieve the SBOM: After build, Yocto outputs SPDX files like:

my-image.spdx.json: Full image SBOM
my-image.spdx.index.json: Index of component SBOMs
my-image.spdx.tar.zst: Archive of all SPDX documents

Yocto generates SBOMs at the build/release phase of the SDLC, making it ideal for embedded vendors who need to document all shipped components for security and compliance.

Enriching Ecosystem-Specific SBOMs

The default SBOM coming from tool-specific generators such as Yocto may require enrichment to meet regulatory requirements. These SBOMs may lack certain data fields, such as license information, suppliers, support status, or vulnerabilities. Importing an incomplete SBOM into a tool like FOSSA enables the enrichment of your SBOM with these critical missing attributes, while relying on the build tool for package resolution.

4. Generating a Container SBOM

There are several tools and strategies that can be used to generate an SBOM from a container. These include FOSSA, Microsoft’s SBOM tool, Syft, the docker scout sbom command, and more. For our container SBOM walkthrough, we’ll use cdxgen, an open source CLI tool that generates CycloneDX SBOMs for a variety of programming languages and project types, including containers.

Generating a Container SBOM with cdxgen

Install cdxgen: Use your package manager of choice:

$ brew install cdxgen

Run the tool on a container image: To generate an SBOM from a container image, use:

cdxgen <image-name> \
  -o bom.json \
  -t docker

Replace <image-name> with the name of your local or remote Docker image (e.g., node:18-alpine). If a tag is not supplied, the `latest` will be pulled. This command will scan the image layers and generate a CycloneDX SBOM (bom.json) in the current directory.

Customize output: You can change the output file name or specification version:

cdxgen <image-name> \
  -o bom.json \
  --spec-version 1.5 \
  -t docker

Use the SBOM: The resulting SBOM can be reviewed, stored for compliance purposes, or uploaded to security tools for vulnerability analysis.

What’s the Best Way to Generate an SBOM?

As SBOMs have gained in popularity, more and more options have become available for teams looking to generate documents from source code, containers, and native ecosystems. Our view is that the “best” way to generate an SBOM is an approach that allows you to create the SBOM during build time for each phase (dev/qa/prod etc.) of your deployment, since this allows for the most accurate dependency inventory including relationships.

Beyond that, the right strategy for generating an SBOM will depend on factors like whether you have access to source code, whether you’re building a single-language application or a polyglot application, whether you have budget for an enterprise SBOM tool, and more.

As you work to refine your SBOM strategy, we hope this blog gives you a useful starting point for how you might go about generating different types of SBOMs. Feel free to get in touch with our team with questions or to get a demo of FOSSA's SBOM solution.