Cvss In Context

Prerequisites

• Target system, dependencies and environment configured.

Usage

Purpose

A CVSS base score describes a vulnerability in the abstract, as if every environment were identical. Yours isn't. A 9.8 on an isolated internal box with no reachable path can safely wait behind a 6.5 that's internet-facing and being actively exploited. This skill is about turning raw scores into a real priority order using the context the base score ignores.

When to use it

Every time a scan or feed hands you more findings than you can fix at once — which is always. It's the difference between a vulnerability programme that reduces risk and one that just processes tickets by number.

The three layers of CVSS

• Base — intrinsic severity (attack vector, complexity, impact). This is the number most people stop at. It's a starting point, not a priority.
• Threat / Temporal — is there a working exploit? Is it being used in the wild? A vuln with public exploit code and active campaigns is far more urgent than an equal-base-score one with no known exploit.
• Environmental — how it maps to your estate: is the asset exposed? Does it hold sensitive data? Are compensating controls in place? This is where you personalise the score.

Procedure

1. Start from the base score, but treat it as an input, not the answer.
2. Add exploitability reality. Check whether the CVE is on CISA KEV (known exploited — if so, it jumps the queue regardless of base score) and its EPSS probability (likelihood of exploitation in the next 30 days). A modest base score with high EPSS or KEV listing outranks a scary base score with neither.
3. Add exposure. Is the affected asset internet-facing, internal-only, or air-gapped? Reachability changes real risk more than almost anything. An unreachable critical is a low priority in practice.
4. Add asset value. What does the asset hold or enable? A medium vuln on the crown-jewel database beats a high on a throwaway test box.
5. Add compensating controls. A WAF rule, network segmentation, or MFA may already blunt the vuln — lowering urgency (but note it as mitigation, not a fix).
6. Rank by the adjusted picture and set remediation SLAs from that ranking, not from the raw base severity band.

Cheatsheet

priority ≈ base severity  ×  exploitability  ×  exposure  ×  asset value  ÷  controls

jump-the-queue signals (fix now, near regardless of base score):
  - on CISA KEV (actively exploited in the wild)
  - high EPSS score (likely to be exploited soon)
  - internet-facing AND unauthenticated AND no compensating control

de-prioritise signals:
  - not reachable from any threat path (air-gapped / internal-only, segmented)
  - no known exploit AND low EPSS
  - strong compensating control already in place
  - asset holds nothing sensitive and enables nothing

sources: nvd.nist.gov (base), first.org/epss (EPSS), cisa.gov/kev (KEV)

Reading the picture

• KEV-listed is the strongest single signal — it's not theoretical, it's being used. Treat as urgent even at a medium base score.
• High EPSS predicts near-term exploitation; a rising EPSS on an exposed asset is a fix-this-week item.
• Internet-facing + unauthenticated multiplies everything; the same CVE internally is often a different priority tier.
• A critical with no exploit, no exposure, low EPSS is defensible to schedule rather than scramble on — document the reasoning so the deferral is a decision, not neglect.
• Beware base-score tunnel vision: a queue sorted purely by CVSS base routinely fixes irrelevant criticals while an exploited medium sits open.

Making it repeatable (the "fix")

• Automate enrichment: pull KEV and EPSS into the vuln pipeline so every finding arrives with exploitability context, not just a base score.
• Tag assets with exposure and business value up front (asset inventory skill) so environmental scoring isn't guesswork each time.
• Set SLAs on the adjusted priority, e.g. KEV/actively-exploited internet-facing → days; high base but unreachable → normal cycle.
• Record risk-acceptance decisions with an owner and a review date when you defer something — that's the audit trail that makes deferral legitimate.

Pitfalls

• Sorting the backlog by base CVSS. The single most common vuln-management mistake — it wastes effort on unreachable criticals and misses exploited mediums.
• Ignoring KEV/EPSS. The base score can't tell you what's being exploited; those feeds can. Skipping them means flying blind on urgency.
• Counting a compensating control as a fix. It lowers urgency, it doesn't close the vuln. Keep it on the list, just lower.
• Deferring without documentation. An undocumented deferral looks identical to negligence after an incident. Write down the why and the owner.

References

• FIRST — CVSS v3.1/v4.0 specification (base/threat/environmental metrics)
• FIRST EPSS (first.org/epss)
• CISA Known Exploited Vulnerabilities Catalog
• NIST SP 800-40 (patch and vulnerability management)

Inputs

• Relevant source code, logs, network traces, or system specifications.

Outputs

• Analysis findings, security audit report, or generated code artifacts.