Vulnerability Handling

Vulnerability handling encompasses the end-to-end set of processes a manufacturer uses to manage security weaknesses in its products from discovery through to user notification and remediation. ISO/IEC 30111 defines vulnerability handling (also called 'vulnerability management') as distinct from vulnerability disclosure — it covers the internal processes, whereas disclosure covers the external communication. Under the CRA, vulnerability handling includes: maintaining an SBOM to know what is in the product; monitoring for new CVEs affecting components; validating and triaging reported vulnerabilities; developing patches; publishing advisories; and reporting to regulators when exploitation is detected.

Annex I Part II lists the vulnerability handling obligations that form part of the essential requirements:

• Component identification — document all software and hardware components, including third-party and open-source (SBOM).
• Proactive monitoring — continuously monitor for vulnerabilities in components; assess impact on the product.
• Timely remediation — develop and release patches without undue delay; do not impose charges for security fixes.
• CVD policy — publish and maintain an accessible coordinated vulnerability disclosure policy.
• Advisory publication — inform affected users of vulnerabilities and remediation steps.
• ENISA notification — notify ENISA and national CSIRTs of actively exploited vulnerabilities within 24 hours.
• Support period commitment — document and communicate the period during which vulnerabilities will be handled.

A CRA-compliant vulnerability handling lifecycle follows these stages:

1. Discovery — vulnerability identified through internal testing, external researcher report, CVE monitoring, or threat intelligence.
2. Triage — validate the report, assess severity (CVSS score), determine exploitability, and check for active exploitation.
3. Notification — if actively exploited, notify ENISA/CSIRT within 24 hours. Request CVE ID.
4. Remediation — develop and test a fix; document the root cause.
5. Release — publish the patch through the product update mechanism, free of charge.
6. Advisory — publish a CSAF security advisory with CVE reference, CVSS score, affected versions, and remediation instructions.
7. Documentation — update technical documentation with the vulnerability record and advisory.

A significant CRA compliance challenge is vulnerability handling for third-party and open-source components. Manufacturers are responsible for these components as if they were their own. Required processes include:

• CVE feed monitoring — subscribe to NVD, vendor security bulletins, and sector-specific ISAC feeds; match new CVEs against the product SBOM.
• Impact assessment — for each matching CVE, determine if the vulnerable code path is reachable in the product.
• Upstream patch tracking — monitor upstream projects for security fixes; integrate them into the product's next release cycle.
• VEX publication — for CVEs where the vulnerability is present in a component but not exploitable in the product's specific configuration, publish a VEX statement (via CSAF) to prevent unnecessary customer alarm.

The SBOM is the foundation that makes all of this tractable.