What an SBOM is

The US authority CISA describes a software bill of materials as a "nested inventory": a list of the ingredients a piece of software is assembled from, including the components that sit inside other components [1]. This does not mean prose documentation, but a machine readable document.

The two formats

Two formats have established themselves for this: SPDX, standardised as ISO/IEC 5962 since 2021 [2], and CycloneDX, which has been standardised as ECMA-424 since June 2024. The second edition, published in December 2025, describes CycloneDX 1.7 in JSON format [3, 7].

Which of the two formats you choose is rarely a matter of principle. SPDX comes from licence compliance and transports provenance and licence information alongside security information [2].

CycloneDX is designed as a modular object model that maps services and dependency relationships in addition to software components [3]. In practice, what your toolchain and your recipients require usually decides; tools such as Syft can convert between the formats [5].

What has to be in it at minimum

What belongs in it at minimum is described by the NTIA in its report on the "Minimum Elements": data fields such as supplier, component name, version, unique identifiers and dependency relationships, plus requirements for automation and for the processes around generation and distribution [4].

Generate: in the build, not afterwards

An SBOM should be generated alongside the shipped artifact. The build is a suitable starting point: base images, resolved dependencies and system packages can be recorded here and tied to the release. Completeness depends on the data sources and tools used.

An example of a tool at this point is Syft, a CLI tool that generates SBOMs from container images and file systems and outputs them as SPDX or CycloneDX JSON, among other formats [5].

In practice this means: one additional step in the pipeline directly after the image build, which stores the SBOM as an artifact next to the image. The unique mapping matters: every SBOM belongs to exactly one artifact in exactly one version, otherwise it is later impossible to say which answer applies to which release.

The most common mistake

A common mistake is scanning only the source repository. An image scan also captures base-image packages, but does not guarantee that all dependencies are detected. Source, build and image analysis complement each other; missing components may need to be added from build or supplier data. The essential requirement is a clear mapping to the shipped artifact [9].

Verify: matching against vulnerability data

An SBOM is a snapshot of the composition, not a statement about security. Its value emerges in the matching: tools such as Grype, which builds on Syft [5], match the component list against vulnerability databases and report which entries are affected.

Two conditions for a usable result

First, the identifiers. Only when components are named unambiguously does the matching hit, which is exactly why unique identifiers are among the NTIA minimum elements [4].

Second, the repetition. New vulnerabilities affect old artifacts. The matching therefore has to run regularly against the SBOMs of releases that shipped long ago, otherwise you only learn about an affected component at the next deployment.

An example. A vulnerability becomes known in a widely used library. The question that then has to be answered within hours is not whether you are affected, but in which shipped versions. With SBOMs per release, that is a query across the stored documents: which releases contain the component in an affected version. Without them, a search through build logs and repositories begins while the question hangs in the air. The difference does not lie in the scanner, but in the answer already being there before anyone asks.

Who does the work

The matching also produces work that wants to be organised. A hit in the SBOM initially means: the component is present. Whether the vulnerability is reachable in the concrete deployment has to be assessed by a person or a downstream process.

That is why the SBOM matching belongs connected to the existing vulnerability management, with the same paths for prioritisation and follow-up, instead of a separate report nobody reads.

Retain and share

Retention is the unspectacular part on which the ability to give answers depends. What has proven itself: one SBOM per release, stored versioned next to the artifact, for example in the registry or the artifact store, so that for every productive version you can look up what is inside.

This includes regulated access: internally for security and operations teams, externally on request for customers who demand an SBOM for your software. The same applies in reverse: whoever buys software should request SBOMs from the supplier and include them in their own review, instead of reconstructing the composition themselves.

For sharing, the format discipline from the first section pays off: an SBOM in standard-conformant SPDX or CycloneDX can be loaded by the recipient directly into their tools, a spreadsheet cannot.

For how long

Also clarify early how long you keep SBOMs. As long as a version runs in production somewhere or support commitments exist, the corresponding SBOM has to be retrievable, and with long-lived enterprise software that quickly becomes a question of years.

For products within the scope of the Cyber Resilience Act, manufacturers must generally create a machine-readable SBOM covering at least the top-level dependencies from 11 December 2027 [8]. Germany's federal cyber security authority BSI sets out concrete SBOM requirements in Technical Guideline TR-03183 part 2 in preparation for it, including a mapping of data fields to SPDX and CycloneDX [6].

Key takeaway

An SBOM that is created by hand once a year is documentation. An SBOM that every build generates, that runs recurringly against vulnerability data and that stays findable per release, is a tool.

What you can decide afterwards

  • At which point in your pipeline SBOMs are generated and in which format, SPDX or CycloneDX.
  • How the recurring matching against vulnerability data connects to your existing vulnerability management.
  • Where SBOMs are stored per release, who gets access and how long they are kept.

Frequently asked questions

Is the SBOM from the source code scan enough?

Not necessarily. For containers, a source-only scan misses base-image packages, for example. An additional image scan improves coverage but does not guarantee completeness either. Supplement it with build and supplier data as needed and link the SBOM to the shipped artifact.

SPDX or CycloneDX?

Rarely a matter of principle. What your toolchain and your recipients require decides, and tools such as Syft convert between the two formats. What matters more is that the SBOM is generated automatically in the build.

Are we obliged to provide an SBOM as a manufacturer?

For products within the scope of the Cyber Resilience Act, the requirement to create a machine-readable SBOM generally applies from 11 December 2027. It must cover at least the top-level dependencies. Check whether your product is in scope and which transitional rules apply. This does not establish a blanket requirement to publish the SBOM publicly [8].

Sources

Read on

Service Cybersecurity Service Platform Engineering Insights Terraform for teams Insights MCP Security