Objlab
// Software security

SBOM: the bill of materials for your software.

An SBOM lists what is inside your software: libraries, versions, licences. It answers in minutes the question that eventually arrives — «does this new vulnerability affect us?» — and lately it is also required by law.

What it is really for

The legal obligation came later. The practical reasons were already there.

  • Answering in minutes rather than days when a vulnerability lands on a widely used library.
  • Knowing which open source licences you inherited, before the customer’s legal team finds out.
  • Answering vendor questionnaires without rebuilding everything by hand each time.
  • Meeting what the Cyber Resilience Act requires, which names it explicitly.

What it contains

Components and versions
Every library with its exact version. Without precise versions an SBOM does not answer the question it exists for.
Identifiers
PURL or CPE — names a machine can match against vulnerability databases. That is what makes the list usable.
Licences
The declared licence of each component: the least technical and most treacherous side of the supply chain.
Relationships
Who depends on what. It separates a direct dependency you control from a transitive one you inherited.
Provenance
Who generated it, when, and from which build. An SBOM without context goes stale unnoticed.

CycloneDX or SPDX

Two standard formats, both accepted. The choice matters less than people fear.

  • CycloneDX comes from the security world and pairs most directly with vulnerability data.
  • SPDX comes from the licensing world and has a longer tradition on the legal side.
  • Converters exist between them: the choice is not a door that closes.
  • What matters far more is that the SBOM is generated on every build rather than written once by hand.

How to produce one

The single rule that matters: generated by the build, not compiled by hand.

  1. Generate the SBOM as part of the pipeline, like any other release artefact.
  2. Take dependencies from the project’s package manager, not from a list kept on the side: the second always drifts.
  3. Include transitive dependencies: they are most of the components and most of the vulnerabilities.
  4. Store it alongside the released version: you need to say what was inside a two-year-old release, not only today’s.
  5. Match it regularly against vulnerability databases, otherwise it is a snapshot that warns you of nothing.

Three wrong beliefs

«We will make one when asked»

Reconstructing the dependencies of a past release costs far more than generating it at the time — and sometimes is no longer possible.

«Direct packages are enough»

The vulnerabilities that make the news almost always sit in a transitive dependency nobody consciously chose.

«It is a formality»

It is the only tool that answers «does this affect us?» in useful time. Those who have one close in half an hour what others close in a week.

If you are preparing SBOMs for your products and do not know where to start, let us look at a real project together.

Book an assessment

Page updated 10 August 2026.