SBOM explained: software bill of materials and new obligations
In short
An SBOM (software bill of materials) is a machine-readable list of all components of a piece of software, including versions and licences. Common formats are CycloneDX and SPDX. The EU Cyber Resilience Act requires an SBOM from manufacturers of digital products; NIS2 demands supply-chain security.
01
What an SBOM contains
Name, version and origin of every library, dependencies between them, licences and a checksum. When a new vulnerability appears, you can tell in minutes which applications are affected.
02
CRA and NIS2
The Cyber Resilience Act gradually obliges manufacturers of products with digital elements to manage vulnerabilities and provide an SBOM. NIS2 requires in-scope companies to manage supply-chain risks. Check legally whether and when you are affected.
03
Generating SBOMs automatically
SBOMs are best created in the build pipeline, signed together with the artefact and checked continuously against vulnerability databases. MAKONIS sets this up as part of supply-chain security.
04
Check completeness and artefact linkage
A formally valid SBOM can still miss components. Scanning a source repository, for example, does not necessarily capture every operating-system package in the shipped container or extensions loaded at runtime.
Link each SBOM to an immutable artefact using its digest and document the scan boundaries. Flag unknown versions and missing licence information as unresolved data-quality issues rather than treating them as clean results.
- 1Identify dependencies from build metadata and lockfiles.
- 2Also scan the finished package or container image.
- 3Check format validity, component identifiers and dependency relationships.
- 4Compare the results and investigate missing or conflicting components.
- 5Store the SBOM, tool version and scan configuration together with the artefact digest.
05
Combine tools according to their task
Generation, inventory management and vulnerability assessment are different tasks. Choose tools based on the ecosystems they support and test data exchange with your actual artefacts.
| Task | Open-source examples | What to check |
|---|---|---|
| Generate SBOMs | Syft, cdxgen | Coverage of the languages and package types in use |
| Match vulnerabilities | Grype, Trivy | Freshness of data sources and matching quality |
| Monitor inventories | Dependency-Track | Import support and mapping to product versions |
06
Example: assessing a new vulnerability advisory
Example: A new security advisory is published for a library, and the inventory system flags several affected product versions. The responsible team first checks which artefacts were actually shipped and whether the vulnerable functionality is present and reachable in them.
Document the assessment with evidence, ownership and a review date; a machine-readable VEX document can additionally communicate the affected status. VEX replaces neither the SBOM nor remediation and must be reviewed when configuration changes or new evidence emerges.
Frequently asked questions
Both are established. CycloneDX focuses more on security, SPDX on licences. What matters is that your tools can read the format.
Innovation from Munich.Active worldwide.
Talk to us about your cloud, DevOps and AI initiatives — no obligation, directly with our engineers.