Vulnerability triage: from CVE report to decision.

Five steps

• Capture the finding: CVE, affected component and version from a scanner, advisory or customer report.
• Check whether you are affected: is the version in the shipped release, is the vulnerable code reachable, does the configuration apply?
• Prioritise: consider severity, likelihood of exploitation and evidence of exploitation together.
• Decide: fix, mitigate, accept the risk with justification, or classify as not affected.
• Document: record the rationale, owner and status so they can be shared with customers.

CVSS, EPSS and KEV

CVSS (FIRST, currently version 4.0) rates technical severity on a scale from 0.0 to 10.0. EPSS (also FIRST) estimates daily the probability that a vulnerability will be exploited in the next 30 days. The KEV catalogue by the US agency CISA lists vulnerabilities with evidence of active exploitation. Together, the three signals separate the severe from the probable; they do not replace the assessment in your own product context.

Documenting decisions: VEX

VEX (Vulnerability Exploitability eXchange) is a machine-readable statement on whether a product is affected by a vulnerability. Common statuses are not_affected (with a justification, for example because the vulnerable code is not present or not reachable), affected, fixed and under_investigation. VEX can be expressed in CSAF, CycloneDX or OpenVEX and saves customers from querying findings that are irrelevant to the product.

Reporting duties under the Cyber Resilience Act

Since 11 September 2026, manufacturers must report actively exploited vulnerabilities in their products (Article 14 of Regulation (EU) 2024/2847): an early warning within 24 hours, a notification within 72 hours and a final report no later than 14 days after a corrective or mitigating measure is available. A practised triage process is the prerequisite for meeting these deadlines.