OBL-ART13-05Binding

Exercise due diligence over software components (SBOM and supply chain)

S'applique à
Manufacturer
Citations sources
Art. 13(5)Annex I Part I §2Annex VII
Classes de produits
default, important-class-i, important-class-ii, critical
Last reviewed

Langage clair

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

  1. 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)
  2. Component vetting — review third-party components for known vulnerabilities before inclusion
  3. CVE/EUVD monitoring — continuously monitor components for newly disclosed vulnerabilities throughout the support period
  4. Contractual flow-down — where a component supplier is itself a PDE manufacturer, ensure vulnerability handling information flows up to you
  5. 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
Exercise due diligence over software components (SBOM and supply chain) — Hub Conformité CRA