01Formats: CycloneDX (ECMA-424) and SPDX (ISO/IEC 5962)
Two open formats dominate in practice. CycloneDX originates from the OWASP community and is standardized internationally through the Ecma committee TC54: version 1.6 was published in June 2024 as ECMA-424 (1st edition), and version 1.7, released in October 2025, was published in December 2025 as ECMA-424 (2nd edition) – with extended modeling for, among other things, cryptographic artifacts and ML models. SPDX is developed under the umbrella of the Linux Foundation; ISO/IEC 5962:2021 standardizes version 2.2.1, while the current specification 3.0.1 (December 2024) is going through the ISO process as ISO/IEC DIS 5962. SPDX has its roots in license compliance, whereas CycloneDX is more strongly geared toward security use cases – both satisfy the CRA requirement of a "commonly used and machine-readable format".
02Minimum contents: from the NTIA Minimum Elements to the CISA Elements 2026
In 2021, the NTIA first defined the minimum constituents of an SBOM in three categories: data fields (including supplier, component name, version, unique identifiers, dependency relationships, SBOM author and timestamp), automation support and accompanying processes. In July 2026, CISA, NSA, FBI and international partner agencies published the "2026 Minimum Elements for a SBOM", which supersede the NTIA version. New additions include component hashes, license information, the name of the generation tool and the generation context; existing fields were refined and named more consistently. The minimum contents are explicitly a floor – depending on the use case, additional information is advisable.
03Generation at build time instead of after-the-fact analysis
The most reliable point for SBOM generation is the build: at that moment, all resolved dependencies including exact versions are known – something neither pure source code analysis nor subsequent binary analysis can fully reconstruct. In practice, this is handled by plugins for package managers and build systems or by generators such as cdxgen and Syft, embedded as a fixed step in the CI/CD pipeline. Each release state thus receives its own versioned SBOM, which is stored alongside the build artifacts and ideally signed. The generation context required by the CISA Elements 2026 additionally makes transparent in which lifecycle phase an SBOM was created.
04Usage: vulnerability correlation with VEX and CSAF
An SBOM only delivers its value through continuous correlation with vulnerability data from sources such as NVD, OSV or GitHub Advisories – enabling an immediate answer, when a new CVE emerges, as to which products contain affected components. Since a vulnerable component does not automatically mean a vulnerable product, VEX (Vulnerability Exploitability eXchange) complements the SBOM with machine-readable vendor statements about actual exploitability; CISA published minimum requirements for this in April 2023. The Common Security Advisory Framework (CSAF 2.0, an OASIS standard since November 2022, with its own VEX profile) and CycloneDX with embedded VEX serve as exchange formats. Used correctly, this combination significantly reduces false positives and focuses remediation on vulnerabilities that are actually exploitable.
05Regulatory obligations: CRA Annex I and BSI TR-03183-2
The Cyber Resilience Act (Regulation (EU) 2024/2847, in force since 10 December 2024) makes the SBOM mandatory: Annex I Part II requires manufacturers to document vulnerabilities and components, including a software bill of materials in a commonly used, machine-readable format that covers at least the top-level dependencies. The SBOM is part of the technical documentation and must be provided to market surveillance authorities upon request; there is no obligation to publish it. The main obligations apply from 11 December 2027, reporting obligations already from 11 September 2026. The BSI substantiates the requirements in Technical Guideline TR-03183 Part 2 (version 2.1.0, August 2025) with formal and subject-matter specifications per data field – including mapping recommendations to SPDX and CycloneDX and, since version 2.1.0, the treatment of virtual and referenced components.
06Operating pattern: OWASP Dependency-Track as an SBOM consumer
For ongoing operations, the pattern of a central SBOM platform has become established, with OWASP Dependency-Track as its best-known open-source example. The platform consumes and produces CycloneDX SBOMs and VEX documents, inventories components across all projects and versions, and continuously matches them against vulnerability sources such as NVD, OSV, GitHub Advisories or Snyk. A policy engine automatically enforces security, license and operational policies; the API-first design enables direct integration with CI/CD pipelines. The decisive point is the paradigm shift: instead of point-in-time scans, the entire portfolio is automatically re-evaluated with every new vulnerability disclosure.
