# Cvss In Context > Use when prioritising a backlog of vulnerabilities — adjusting raw CVSS base scores with environmental and exploitability context so you fix what actually matters first. - Skill: `jihedbfr-art/cvss-in-context` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add jihedbfr-art/cvss-in-context` - Raw SKILL.md: https://api.skillmd.com/api/skills/jihedbfr-art/cvss-in-context/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: jihedbfr-art (https://skillmd.com/u/jihedbfr-art) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/jihedbfr-art/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.