CRA SBOM and component records
Sytance · Updated
The CRA uses component visibility as part of vulnerability handling. Annex I requires manufacturers to identify and document vulnerabilities and components, including by drawing up a software bill of materials.
Annex I requirement
identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products;
Regulation (EU) 2024/2847, Annex I, Part II, point (1)
The SBOM is part of a wider component record. It helps the manufacturer understand which components are contained in the product and which vulnerabilities can affect those components.
What to distinguish
SBOM
A machine-readable software component record. Annex I requires at least top-level dependencies.
Integrated component
A component contained in the product can create vulnerability handling duties for the finished product.
Third-party component
Article 13 requires due diligence when third-party components are integrated into the product.
Authority access
Annex VII includes SBOM access on reasoned request when needed to check Annex I compliance.
Example: a traceable component record
The following fictional record describes a direct software dependency in a controller firmware release. It illustrates useful engineering information; the fields are not an additional CRA-mandated schema.
- Product: controller firmware 1.2.0, release build 120; inventory created from the released build and its dependency data.
- Component: example-parser 2.4.0, supplied by the fictional Example Components project; direct dependency of the firmware.
- Identity and origin: the package identifier, exact source revision or supplier reference, and an actual digest from the supplied artefact.
- Use: the component parses a configuration file uploaded through an authenticated maintenance interface. Record relevant build options and the calling component.
- Evidence: link the machine-readable SBOM and the build or supplier records used to verify this entry. Preserve the earlier release’s inventory when the component changes.
A component name and version can help find candidate vulnerabilities. Product affectedness needs further analysis: whether the vulnerable code is included, whether the affected function runs, the input an attacker can reach, and any relevant controls. An unresolved match remains under investigation; it is not evidence that the product is unaffected.
A statement such as “not affected” should identify the product version, vulnerability, technical reason and supporting evidence. Recheck it when a build option, component version, interface or deployment assumption changes.
Technical documentation link
Annex VII places component and SBOM information in the technical documentation. It also asks for vulnerability-handling process information, the coordinated vulnerability disclosure policy, the reporting contact, and secure update distribution.
The process side is explained in Vulnerability Handling Records and prEN 40000-1-3 Vulnerability Handling.
Format status
Annex I requires a commonly used, machine-readable SBOM covering at least top-level dependencies. Article 13(24) also allows the Commission to specify its format and elements by implementing act, taking European or international standards and best practices into account. Format choices therefore need to distinguish the Regulation’s baseline from any applicable implementing requirements.
- A PDF component list does not meet the machine-readable format requirement for an SBOM.
- The SBOM identifies components; vulnerability handling also requires impact analysis, remediation and communication.
- Annex VII provides for SBOM access on an authority request; it does not create a general duty to publish the SBOM.