Back to glossary
S
Definition

SBOM IT definition

Software Bill of Materials: a detailed, structured inventory of every software component making up an application, including versions and licenses.

An SBOM (Software Bill of Materials) is a detailed, structured inventory of every software component making up an application: open-source libraries, dependencies, versions, licenses, and their relationships. It is the software equivalent of an industrial bill of materials: for every product, you list all sub-components, their origin, and version.

SBOM has become strategic with the rise of software supply-chain attacks (Log4Shell in 2021, SolarWinds in 2020, xz-utils in 2024) and with the European Cyber Resilience Act (2025-2027) and DORA / NIS2 requiring software-component traceability.

Why SBOM matters

A modern application typically relies on hundreds to thousands of open-source components. Without SBOM:

  • When a vulnerability like Log4Shell is announced, it is impossible to know quickly which applications are impacted (which contain which vulnerable log4j version).
  • During a compliance audit, impossible to prove compliance with open-source licenses (GPL, AGPL, MIT, Apache).
  • In a supply-chain attack (a malicious maintainer injecting malicious code into a popular dependency), impossible to detect contamination fast.

SBOM transforms the opaque "it uses X and Y, I think" into "here is the exhaustive auditable list".

SBOM standards

Three formats coexist:

  • CycloneDX: (OWASP, 2017): JSON or XML format, security-oriented, supports software, hardware, services, data.
  • SPDX: (Linux Foundation, 2010): ISO/IEC 5962:2021 standard, text or JSON, strong focus on licenses.
  • SWID Tags: (ISO/IEC 19770-2): XML format, rather oriented toward ITAM and installation inventory.

CycloneDX and SPDX are the most used in practice. Modern tools emit both.

SBOM contents

A complete SBOM contains:

  • Components: name, version, supplier, cryptographic hash (SHA-256).
  • Relationships: "this component depends on", "is included in".
  • Licenses: SPDX ID of applicable licenses.
  • Known vulnerabilities: CVE references (may live in an associated VEX).
  • Metadata: author, generation date, scope (full application, container, package).

SBOM and CRA (Cyber Resilience Act)

The European Cyber Resilience Act, in progressive application 2025-2027, imposes on manufacturers of products with digital components:

  • An up-to-date SBOM for every product placed on the European market.
  • Publication of identified vulnerabilities within 24 hours.
  • Free patches for at least 5 years after market placement.

SBOM therefore becomes a mandatory regulatory deliverable, not just a best practice.

SBOM and VEX

The VEX (Vulnerability Exploitability eXchange) complements SBOM. Where SBOM says "my app contains log4j 2.14", VEX says "and here is whether the Log4Shell vulnerability is exploitable in my context" (e.g. "no, because the vulnerable function is never called").

VEX avoids unnecessary panic: the mere presence of a vulnerable component does not equal an exploitable risk.

How to produce an SBOM

Several tooling levels:

  • CI/CD integrated: Syft, CycloneDX CLI, Microsoft sbom-tool automatically generate the SBOM at build time.
  • Container image scan: Trivy, Grype, Snyk inspect Docker images.
  • Binary scan: Anchore, Black Duck analyze binaries without source access.
  • Governance platforms: Sonatype, JFrog Xray, Mend, Snyk manage SBOM + vulnerabilities + licenses at scale.

For a complete program, the SBOM must be:

  • Generated automatically at every build (not once a year).
  • Cryptographically signed: (Sigstore).
  • Stored: and versioned as a release deliverable.
  • Continuously matched: against vulnerability databases (CVE, GitHub Security Advisories, OSV).

SBOM and application mapping

SBOM is at the application scale. Application mapping is at the IT-estate scale. The two complement each other:

  • Mapping identifies "which applications I have".
  • SBOM identifies "which components compose each application".

The challenge for a CIO is to federate the SBOMs of all applications into a single IT-estate graph, exploitable for compliance (NIS2, DORA, CRA) and incident response ("which apps are impacted by this CVE?"). Kabeen automatically aggregates SBOMs of all known applications to give the CIO a consolidated risk view.

Frequently asked questions

What is an SBOM?

+

An SBOM (Software Bill of Materials) is the detailed, structured inventory of every software component making up an application: open-source libraries, dependencies, versions, licenses, and relationships. It's the software equivalent of an industrial bill of materials. Without SBOM, it's impossible to know quickly which applications are affected when a vulnerability like Log4Shell is announced.

What are SBOM standards?

+

Three standards coexist: CycloneDX (OWASP, 2017, JSON/XML, security-oriented), SPDX (Linux Foundation, 2010, ISO/IEC 5962:2021 standard, license-focused), and SWID Tags (ISO/IEC 19770-2, XML, ITAM-oriented). CycloneDX and SPDX are the most used. Modern tools (Syft, Trivy, Snyk) emit both formats.

Is SBOM mandatory?

+

Yes in several cases: the European Cyber Resilience Act (in force 2025-2027) requires an up-to-date SBOM for every digital product placed on the European market. DORA and NIS2 require software component traceability. In the US, Executive Order 14028 (2021) requires SBOM for any federal-government vendor. SBOM becomes a mandatory regulatory deliverable, not just a best practice.

What is the difference between SBOM and VEX?

+

SBOM says what is in an application ("my app contains log4j 2.14"). VEX (Vulnerability Exploitability eXchange) says whether a known vulnerability is actually exploitable in the usage context ("no, because the vulnerable function is never called"). VEX avoids unnecessary panic: the presence of a vulnerable component does not equal an actually exploitable risk.

Need help mapping your IT landscape?

Kabeen helps you inventory, analyze and optimize your application portfolio.

Try for free