Under the EU Cyber Resilience Act (CRA), having a clear view of what’s inside your software is essential, and that’s exactly what an SBOM provides.
What’s an SBOM?
A Software Bill of Materials (SBOM), also called a software inventory or component transparency record, is like an ingredient list for your software. It includes:
- All third-party libraries (open source or not)
- Their versions and dependencies
- The relationships between components
Think of it as a structured map of everything that makes your product run.
What Does the CRA Say?
The CRA makes SBOMs a core part of the vulnerability management process. Specifically, Annex I, Part II, point (1) requires manufacturers to:
- Document components and vulnerabilities
- Maintain an up-to-date SBOM
- Use it to detect, assess, and handle security risks
The SBOM also helps authorities assess your product’s risk and is part of the technical documentation you’ll need to provide (Article 13(7), Article 31, and Annex VII).
Why It Matters
You can’t fix what you don’t know you’re using. An SBOM:
- Identifies known vulnerabilities in open source and third-party components
- Accelerates incident response and patching workflows
- Enables transparent cyber risk management for internal teams and external auditors
- Is a key expectation for regulators, security-conscious customers, and CRA assessments
- Supports secure supply chain management by making dependencies visible
The CRA doesn’t specify an exact format (yet), but structured, machine-readable SBOMs are recommended. Expect future guidance or harmonised standards to point toward formats like CycloneDX or SPDX.
If you’re not generating SBOMs already, participate in the forum to swap tips, tools, and workflows for building CRA-compliant SBOMs.