CVSS and rating vulnerabilities: How critical is a flaw?

In short: CVSS rates security flaws on a scale from 0 to 10; EPSS and KEV additionally show how likely and how actually a flaw is exploited.

In more detail: New vulnerabilities (CVE numbers) are published daily. Nobody can fix them all at once, so you need prioritisation. The Common Vulnerability Scoring System (CVSS) provides a standardised severity.

In Depth

The CVSS value

The base score from 0.0 to 10.0 results from properties of the flaw:

• Attack vector (network, adjacent, local, physical).
• Complexity of the attack, required privileges and user interaction.
• Impact on confidentiality, integrity, availability.
• Scope (does it affect other components?). Severities: 0.1–3.9 low, 4.0–6.9 medium, 7.0–8.9 high, 9.0–10.0 critical. The vector (for example CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) shows the individual values. CVSS 4.0 refines the model.

Why the value is not everything

CVSS describes the theoretical severity, not the risk in your environment. A critical flaw in a component you do not use or that is not reachable is less urgent than a medium flaw in a publicly reachable system with an existing exploit. Important: check affectedness (is the vulnerable function reachable?), include environmental values (protection requirement, countermeasures).

Other signals

• EPSS (Exploit Prediction Scoring System): probability that the flaw will be exploited in the next 30 days.
• CISA KEV (Known Exploited Vulnerabilities): list of actually exploited flaws: patch immediately.
• Exploit available? (Exploit-DB, Metasploit), proof of concept public.
• Vendor notes, BSI warnings.
• VEX statements (“not affected”) reduce false alarms.

Practical procedure

1. Know your inventory (SBOM, asset list).
2. Use scanners (Dependabot, npm audit, Trivy, OWASP Dependency-Check).
3. Prioritise: KEV/EPSS high → immediately; CVSS ≥ 9 on reachable systems → days; the rest as planned.
4. Fix (update/patch) or mitigate (configuration, WAF, network segmentation, disable the function).
5. Document and repeat regularly. Always ask: is it reachable, exploitable in our case and how bad would the damage be?

See also: Dependencies and vulnerabilities (CVE), Software supply chain and SBOM, Risk analysis, Responsible disclosure