Vulnerability management

The cycle

detection → SBOM correlation → triage → exploitability qualification (VEX)
   → prioritisation → remediation → verification → advisory publication
   → closure → archiving

Every transition is timestamped. That chronology is what demonstrates, in an inspection, the “without delay” handling Annex I requires.

The sources to aggregate

Source	Nature	Role
EUVD	European vulnerability database, operated by ENISA	The European reference, fed by CRA reports
NVD	US database, CPE correlation	Broad coverage, latency and imprecise matching
OSV	Per-ecosystem database, PURL correlation	High precision on packages
Catalogues of confirmed exploitation	Vulnerabilities actually exploited	Priority trigger
Vendor and distribution advisories	Fixes and backports	Avoids version-based false positives
Upstream project advisories	Often ahead of the databases	Early detection
National CERTs	Alerts and threat context	Regional context

Aggregation is the job of the steering platform, not of a spreadsheet.

Triage

Three questions, in this order:

1. Is the component actually present? Verify by purl and hash. Many alerts stop here — see Identifiers.
2. Is the vulnerable code reachable? Reachability analysis, examination of the execution path. This is where the VEX status is decided.
3. How urgent is it really? Prioritisation, below.

Prioritisation

No single indicator suffices.

Indicator	What it tells you	What it does not
Base severity (CVSS)	Intrinsic severity	Neither actual exploitation nor your context
Environmental score	Severity for you	Requires contextualisation work
Exploitation probability	Likelihood of near-term exploitation	Neither presence with you nor impact
Confirmed exploitation	That it is exploited in the wild	Neither with you, nor on this path
Reachability	That the code is called	Neither exploitability nor impact
Network exposure	That the component is reachable	—
Business criticality of the product	The impact of an incident	—

Recommended composite score, to be weighted once and documented:

priority = contextualised severity
         × exploitation factor (confirmed > likely > theoretical)
         × reachability (called > present but not called)
         × exposure (network > local)
         × business criticality of the product

What matters is not the formula but that it is written down, stable and applied uniformly: that is what makes decisions comparable and defensible.

Remediation SLAs

To be defined, published internally, and measured:

Level	Trigger	Target fix interval
Emergency	Active exploitation observed on your product	Immediate workaround, fix within 72 h
Critical	Remotely exploitable without authentication, reachable	7 days
High	Exploitable, reachable, specific conditions	30 days
Medium	Exploitable in a restricted scenario	90 days
Low or not exploitable	Documented in a VEX	Handled in the next release

These intervals are internal; the Regulation requires handling “without delay” without quantifying it. Written and honoured SLAs are the best demonstration of what you mean by “without delay”.

The reporting trigger

This is the hinge between engineering and law.

As soon as a vulnerability in your product is qualified as actively exploited, the 24-hour clock in Article 14 starts. Moving from triage to legal obligation must not depend on the initiative of whoever is on call.

Implementation: a dedicated status in the tracking tool whose activation automatically raises an alert to the legal on-call rota and opens an entry in the decision register. See 24-hour procedure and Reporting duties.

Separating fixes

Annex I asks that, where technically feasible, security fixes be provided separately from functional updates. That requires:

• a branching strategy for maintenance per supported version line;
• the ability to backport to older branches;
• a numbering scheme that clearly marks a security fix;
• regression tests runnable on old branches, hence a preserved build environment.

It is a heavy engineering constraint, to be decided at design time rather than at the first incident.

Metrics

Median triage interval, median remediation interval by level, average age of open vulnerabilities, share of alerts handled through VEX, share of SLAs met, number of vulnerabilities inherited from abandoned components. See Metrics.