Annex I Part II: vulnerability handling and the SBOM

Know what you ship

Part II starts with identification: manufacturers must identify and document vulnerabilities and components contained in the product, 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. In practice that means CycloneDX or SPDX. The SBOM is part of the technical documentation — it does not have to be published — but market surveillance authorities may request it, and Annex II requires telling users where the SBOM can be accessed when the manufacturer chooses to provide it.

Fix fast, fix free

In relation to the risks, vulnerabilities must be addressed and remediated without delay, including by providing security updates. Where technically feasible, new security updates ship separately from functionality updates. Security updates that are needed during the support period must be provided free of charge, accompanied by advisory messages giving users the relevant information, including on actions to take. Updates must be distributed through secure mechanisms, and once a patch exists it must be disseminated without delay.

The qualifiers are the exam: free of charge, without delay, where technically feasible, top-level dependencies. Distractors flip exactly these words.

Test, disclose, coordinate

Manufacturers must apply effective and regular tests and reviews of the product's security. Once a security update is available, information about fixed vulnerabilities must be publicly disclosed, including a description of the vulnerability, the affected products, the impacts, the severity, and clear information helping users to remediate — though disclosure may be delayed where users can be updated first and the security risk of publication outweighs the benefit. A coordinated vulnerability disclosure policy must be put in place and enforced, and manufacturers must provide a contact address for reporting vulnerabilities and facilitate the sharing of information about potential vulnerabilities, including in their third-party components.

Vulnerability handling meets the support period

All Part II duties run for the support period determined under Article 13. A component vulnerability is the manufacturer's problem: due diligence when integrating third-party and open-source components is an Article 13 duty, and where a manufacturer identifies a vulnerability in a component, including open source, it must report it to the person maintaining the component and, where it modifies the component, share the fix. The CVD policy, the disclosure contact, and the researcher-facing process are exactly what a coordinated vulnerability disclosure platform operationalises.