Skip to content
UPSTREAM
SBOM

What is an SBOM and what must it contain?

Last updated: · ALVPHA Tech GmbH

What an SBOM contains

For each component, an SBOM describes what it is and where it comes from. The seven minimum elements defined by the US NTIA are the baseline; the German technical guideline BSI TR-03183-2 goes further, for example with licence information and cryptographic hashes.

  • component name and version
  • supplier or origin
  • a unique identifier, for example a package URL (purl)
  • dependency relationships
  • licence information
  • hashes identifying the artefacts
  • author and timestamp of the SBOM

SPDX and CycloneDX

Two formats have become established: SPDX, standardised as ISO/IEC 5962, and CycloneDX, standardised as ECMA-424. Both are machine-readable and produced by common tools. Version 2.1.0 of BSI TR-03183-2 sets CycloneDX 1.6 and SPDX 3.0.1 as minimum versions.

Depth and meaningfulness

An SBOM is only as good as its coverage. What matters is the source it was generated from (source code, build system or finished binary), whether transitive dependencies are included and whether it matches the shipped release. An SBOM that does not belong to the release does not answer the key question.

  • one SBOM per shipped release, not per repository
  • generated automatically in the build, not by hand
  • document known gaps, such as statically linked or vendored components

What the Cyber Resilience Act requires

Under Annex I, Part II, point 1 of Regulation (EU) 2024/2847, manufacturers must identify and document components, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies. The SBOM is part of the technical documentation; it does not have to be published but must be provided to market surveillance authorities on reasoned request. The requirements apply in full from 11 December 2027.

Frequently asked questions

Is an SBOM automatically complete?

No. Its usefulness depends on the source, the generation process and the artefacts covered. Known coverage gaps should be documented explicitly.

Does the SBOM have to be published?

Not under the Cyber Resilience Act. It is part of the technical documentation and must be provided to authorities on reasoned request. Many customers now require it contractually.

SPDX or CycloneDX?

Both are established. The choice usually depends on tools and customer requirements; currency, release scope and coverage matter more than the format.

SOURCES

This article provides technical orientation and is not legal advice. The linked primary sources in their current version are authoritative.

Where does your team stand?

The free Trust Check classifies your self-assessment across seven dimensions, from component inventory to evidence capability. For specific cases, we arrange an introductory call.

Start your free Trust Check Book an introductory call

Related service: Open-source governance and SBOM management

More articles

All articles →
TRIAGE

Vulnerability triage: from CVE report to decision.

Triage means assessing a vulnerability finding in a structured way: is our product actually affected, how urgent is it, and what do we decide? Severity (CVSS) alone is not enough; likelihood of exploitation (EPSS), evidence of exploitation (KEV) and how the component is actually used in the product all matter. The outcome is documented traceably, for example as a VEX statement.

Read article GOVERNANCE

Open-source governance: rules, licences, ownership.

Open-source governance defines how an organisation selects, uses, documents and maintains open source. It combines licence compliance, security processes and clear ownership. The aim is not to slow open source down but to make its use traceable and accountable.

Read article CRA

Cyber Resilience Act: what manufacturers should know about open source.

The Cyber Resilience Act (Regulation (EU) 2024/2847) sets cybersecurity requirements for products with digital elements made available in the EU. For manufacturers this means, among other things: document components (SBOM), handle vulnerabilities, provide security updates and report actively exploited vulnerabilities on time. The reporting duties have applied since 11 September 2026, the remaining requirements apply from 11 December 2027.

Read article CRA REPORTING

CRA reporting obligations since 11 September 2026: what manufacturers must report now.

Since 11 September 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents (Article 14 CRA). Reports go through ENISA's single reporting platform simultaneously to the CSIRT designated as coordinator and to ENISA: early warning within 24 hours, notification within 72 hours, then a final report. The obligation also covers products placed on the market before 11 December 2027.

Read article