Exercise due diligence over software components (SBOM and supply chain)
- Se aplica a
- Manufacturer
- Citas de fuentes
- Art. 13(5)Annex I Part I §2Annex VII
- Clases de productos
- default, important-class-i, important-class-ii, critical
Lenguaje claro
If your product uses code you did not write — like open-source libraries or vendor SDKs — you are still on the hook for its security. Make a list of all the parts you use. This list is called an SBOM. Check each part for known bugs before you ship. Keep the list up to date.
Legal text
Article 13(5) of Regulation (EU) 2024/2847 requires that manufacturers shall ensure that, in cases where a software component incorporated in a product with digital elements is not developed by that manufacturer, the manufacturer is able to fulfil its obligations under this Regulation as regards such software component.
This is reinforced by Annex I Part I §2, which requires manufacturers to identify and document components, and to address vulnerabilities in third-party components without undue delay.
Annex VII explicitly requires the technical documentation to contain an SBOM — a machine-readable inventory of all software components.
Key requirements
- SBOM — produce and maintain a software bill of materials in a recognised format (CycloneDX or SPDX are the industry-standard formats aligned with ENISA guidance)
- Component vetting — review third-party components for known vulnerabilities before inclusion
- CVE/EUVD monitoring — continuously monitor components for newly disclosed vulnerabilities throughout the support period
- Contractual flow-down — where a component supplier is itself a PDE manufacturer, ensure vulnerability handling information flows up to you
- No knowingly vulnerable components — do not ship components with known exploitable vulnerabilities (see also OBL-ART13-06 on delivery-time checks)
SBOM minimum content
Per ENISA guidance and CRA Annex VII, the SBOM should include:
- Component name and supplier
- Version identifier
- Component hash (for integrity verification)
- Dependency relationships
- Known licence
Evidence you may need
- SBOM in CycloneDX or SPDX format, version-controlled
- Software composition analysis (SCA) scan results
- Records of component vulnerability assessments
- Contractual provisions with component suppliers covering vulnerability disclosure
- CVE monitoring records and patch/update history for third-party components