Skip to content

SBOM

What is an SBOM?

A Software Bill of Materials (SBOM) is a detailed list of all the components that make up any kind of software. This includes open-source and proprietary libraries, transitive dependencies, and other software packages used during development, build, and deployment.

SBOMs help answer questions as: What’s in the software? Where did it come from? And what are the associated risks? SBOMs typically include metadata such as component names, versions, licenses, suppliers, and relationships between components. They can be generated at different stages of the software lifecycle — from source code, during the build process, or from deployed artifacts — each offering different levels of completeness and precision.

SBOMs can be generated and shared in standardized formats, with the most widely adopted being SPDX and CycloneDX. They were originally conceived for different use cases but as the standards evolve they are becoming more and more equivalent.

SPDX

SPDX (Software Package Data Exchange) is a mature and flexible SBOM format supported, and originally developed, by the Linux Foundation. It was firstly created to track licensing information, which remains its main area.

Strengths:

  • Rich licensing metadata support.
  • Multiple document formats (JSON, RDF/XML, tag-value, etc.).
  • Good support for SBOM composition.
  • Strong support from foundations like OpenChain and the Linux Foundation.

Limitations:

  • Complex specification (in particular in its versions 3.x).
  • Vulneribility management is not as complete as in CycloneDX.

CycloneDX

CycloneDX is a lightweight SBOM standard developed by the OWASP Foundation. It was designed with security use cases in mind and is well-aligned with DevSecOps practices.

Strengths:

  • Lightweight.
  • Created for security workflows, in particular for vulnerability management.

Limitations:

  • Less mature license metadata support compared to SPDX.
  • Excluding security use cases, it has limited flexibility.

Why generate an SBOM?

Today’s software often relies heavily on open-source and third-party components. For this reason, the main benefits of SBOM generation are:

  • Security: An SBOM enables the security team, and yourself, to quickly identify whether vulnerable components are present in your software when new security issues are disclosed. This accelerates incident response, patching, and risk mitigation, and helps defend against so-called supply chain attacks.
  • Compliance: SBOMs help ensure that all included software components comply with licensing terms and regulatory requirements. They also support audit readiness and demonstrate due diligence in managing legal obligations related to software usage.

Who should generate an SBOM?

Wherever possible, the authors of an application or service should generate the SBOM. As the developers most familiar with the codebase, they can accurately capture the software’s components, build-time dependencies, and relevant metadata.

It’s important to recognize that SBOMs present specific challenges, for example for libraries in dynamic ecosystems like Python. Library authors often declare dependency version ranges rather than fixed versions, and the actual versions used are resolved only at installation time, depending on the environment. As a result, SBOMs generated at the library level may be incomplete, ambiguous, or not reproducible across different systems. For instance, the SPDX specification does not currently support version ranges in a formal way (see SPDX issue #14), which further limits the ability to represent such SBOMs accurately using this format. Issues like this highlight how the authors of an application are the ones who can better generate SBOMs as meaningful as possible.

In case you wish to generate an SBOM for your project you can follow our dedicated docs .