Vulnerability Triage

Vulnerability triage is the structured process of evaluating a vulnerability — whether received through a researcher report, a CVE disclosure, or an automated scanner alert — to determine whether it is valid, which products or components it affects, how severe it is in context, and what priority to assign to remediation. The term borrows from medical triage: just as hospitals prioritise patients by urgency, security teams prioritise vulnerabilities by exploitability, impact, and remediation complexity. Without a triage process, high volumes of vulnerability reports overwhelm engineering teams and cause genuinely critical issues to be missed among routine low-severity findings. The CRA requires manufacturers to address vulnerabilities 'without undue delay' — meaningful only if they can first determine which vulnerabilities require what level of urgency.

A complete triage workflow involves three stages:

Validation: Confirming the reported vulnerability is genuine and reproducible. For researcher reports, this means setting up a test environment and reproducing the issue. For CVE-based alerts (e.g., a new CVE in a library in the SBOM), this means confirming whether the vulnerable code path is actually reachable in the product.

Scoring: Assigning a severity score using CVSS (v3.1 or v4.0) and optionally supplementing with EPSS for exploitation likelihood. The product's threat context affects the Environmental Score — a vulnerability that is critical in isolation may be lower severity when compensating controls are applied.

Prioritisation: Ranking the validated, scored vulnerabilities against available remediation capacity. Prioritisation considers: CVSS score, EPSS score, whether the vulnerability is in the CISA KEV catalogue, potential harm to users, and complexity of the fix.

The CRA's Article 14 requires manufacturers to notify ENISA of actively exploited vulnerabilities within 24 hours. This notification obligation cannot be met unless the manufacturer has a triage process capable of making a rapid determination of exploitation status. Similarly, the general obligation to address vulnerabilities 'without undue delay' requires a triage outcome — severity and remediation priority — to be established promptly after a vulnerability is identified. PSIRT teams responsible for CRA compliance should have documented triage SLAs: for example, all researcher reports acknowledged within 5 business days, initial severity assessment within 10 business days, and exploited vulnerabilities triaged within hours rather than days. These SLAs should be tracked and auditable.

Manual triage is unsustainable for products with large dependency trees. Modern triage tooling includes:

• SBOM-driven correlation: Automated matching of new CVEs against the product's SBOM to surface only relevant vulnerabilities, filtering out the large proportion of NVD/CVE entries that do not affect the specific components in the product.
• VEX documents: Vendor statements (Vulnerability Exploitability eXchange) asserting that specific CVEs do not affect a product version, enabling downstream users to filter noise.
• EPSS integration: Incorporating EPSS scores into automated prioritisation to focus on vulnerabilities most likely to be exploited, not just those with high CVSS scores.
• PSIRT ticketing systems: Structured case management tracking each vulnerability from intake through triage, remediation, and advisory publication.

CVD Portal integrates SBOM-driven CVE correlation and VEX generation to automate significant portions of the triage workflow.