Security Triage

Security triage is the rapid initial assessment of incoming security findings — whether researcher vulnerability reports, CVE disclosures from dependency monitoring, SIEM alerts, or penetration test findings — to determine their validity, applicability, severity, and response priority. The term is adapted from emergency medicine, where triage allocates scarce treatment resources to patients based on urgency. In security operations, triage allocates scarce engineering and security resources to the findings that pose the greatest real risk, ensuring critical issues are addressed urgently while routine issues enter the normal patch cycle. Without triage, security teams are overwhelmed by volume — modern vulnerability databases publish hundreds of CVEs per week, and not all of them require the same urgency of response.

For manufacturers operating under CRA obligations, triage is a mandatory step in the vulnerability handling process. CRA Article 13 requires manufacturers to address vulnerabilities 'without undue delay' — this implies a prioritisation mechanism that distinguishes between critical vulnerabilities requiring immediate response and low-severity issues that can wait. A CRA-compliant triage workflow includes:

1. Intake and acknowledgement: Log the incoming report or CVE; acknowledge receipt to the reporter within 5 business days (for researcher submissions).
2. Validation: Confirm the vulnerability is genuine and affects the product. For CVEs, confirm the affected component and version are present in the product's SBOM.
3. Severity scoring: Assign a CVSS base score and record the EPSS score. Assess the product-specific environmental score considering compensating controls.
4. Exploitation assessment: Check whether the vulnerability is in the CISA KEV catalogue; assess exploitation probability using EPSS.
5. Priority assignment: Assign to a response SLA tier (Critical, High, Medium, Low) based on combined CVSS/EPSS assessment.
6. Routing: Assign to the appropriate engineering team with the SLA deadline.

Documented triage SLAs are a key element of a CRA-compliant PSIRT. They make the 'without undue delay' standard concrete and auditable. A typical PSIRT triage SLA framework:

• Actively exploited (any CVSS): Triage within 4 hours; ENISA notification initiated within 24 hours.
• Critical (CVSS 9.0–10.0): Initial triage within 1 business day; full triage (including impact assessment and remediation timeline) within 3 business days.
• High (CVSS 7.0–8.9): Full triage within 5 business days.
• Medium (CVSS 4.0–6.9): Full triage within 10 business days.
• Low (CVSS 0.1–3.9): Full triage within 15 business days.

These SLAs apply to the triage process itself — not the full remediation timeline. Remediation SLAs are set separately after triage is complete.

Manual triage is unsustainable at scale. Modern PSIRT operations use automation to reduce the per-finding manual effort:

• SBOM-based pre-filtering: Automated CVE correlation against the product SBOM filters out CVEs for components not in the product, reducing volume by 90%+ for products with well-maintained SBOMs.
• CVSS/EPSS auto-population: PSIRT systems that automatically retrieve CVSS and EPSS scores for incoming CVEs reduce manual scoring effort.
• CISA KEV integration: Automatic flagging of CVEs present in the CISA KEV catalogue for immediate escalation, regardless of CVSS score.
• VEX pre-population: Historical VEX assertions for components with known reachability assessments can be automatically applied to new CVEs affecting those components, reducing manual effort for recurring patterns.

CVD Portal integrates SBOM correlation, CVSS/EPSS data, and CISA KEV checks to automate the triage pre-processing steps, surfacing only confirmed-relevant, accurately scored findings to human analysts.