What is an SBOM — and Why Is It Not Enough?
An SBOM (Software Bill of Materials) is a software inventory: a machine-readable register of all components contained in a software product. The CRA defines it as a "formal record of the details and supply chain relationships of components" (Art. 3 No. 39).
Why is an SBOM mandatory? #
Several EU laws require the documentation of software components:
- DORA Art. 8(4-6): Inventory of all ICT assets including configuration and dependencies, regularly updated
- DORA Art. 28(3): Information register on all ICT third-party agreements
- NIS2 Art. 21(2)(d): Supply chain security as a mandatory measure — presupposes knowledge of all components
- CRA Annex I Part II No. 1: Vulnerabilities and components must be identified and documented by means of an SBOM
- CRA Art. 13(24): The SBOM must be in a common machine-readable format
- ISO 18974 (4.3.1): SBOM creation and maintenance as a continuous process with NTIA minimum elements
An SBOM is therefore not optional. It is a legal requirement.
The problem: SBOM does not equal security #
Most companies create an SBOM and believe they have thereby fulfilled their obligation. This is a dangerous misconception.
An SBOM is an inventory — not a security instrument. It shows you what is there. It does not tell you:
- Whether the components have vulnerabilities not listed in any CVE database
- Whether a project is still actively maintained or has been orphaned for months
- Whether the sole maintainer has just quit
- Whether security fixes were silently applied without any public notification
- Whether the transitive dependencies — i.e. the dependencies of your dependencies — are also secure
Transitive dependencies are particularly treacherous: your SBOM may show 200 direct components. In reality, however, your software depends on 800 or more projects because each component in turn has its own dependencies. A security problem at the fourth level affects you just as much as one at the first.
What an SBOM needs to be useful #
An SBOM only becomes a security instrument when it is:
- Continuously updated — with every change, not once a quarter (DORA Art. 8(6))
- Matched against vulnerabilities — and not only against CVE databases but also against Silent Fixes and project health data (ISO 18974, 4.1.5 No. 2)
- Accompanied by risk assessments — per component, per vulnerability (ISO 18974, 4.3.2 No. 2)
- Linked to measures — documenting what happened when something was found (ISO 18974, 4.3.2 No. 3)
What does this mean for you? #
If you have created an SBOM, you have taken the first step. But an SBOM alone fulfils neither the requirements of DORA, NIS2, nor those of the CRA. These laws require active risk management, not mere inventory. The difference between "we have an SBOM" and "we manage our open source supply chain" is the difference an auditor will examine.
Further reading #
You have created an SBOM and wonder what comes next? Have your SBOM analysed by OTTRIA.