// Software securitySBOM: 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.
- Generate the SBOM as part of the pipeline, like any other release artefact.
- Take dependencies from the project’s package manager, not from a list kept on the side: the second always drifts.
- Include transitive dependencies: they are most of the components and most of the vulnerabilities.
- Store it alongside the released version: you need to say what was inside a two-year-old release, not only today’s.
- 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 assessmentPage updated 10 August 2026.