Prioritize Vulnerabilities by Real Exploitability, Not Raw CVSS

Patching strictly by CVSS means you spend the same urgency on a critical bug in a locked-down internal tool as on a medium bug being weaponized in the wild against your public API. AI helps by fusing the signals that actually predict risk — EPSS exploitation probability, CISA KEV known-exploited status, and your own asset context — into a defensible priority order. The model reasons and explains; the feeds provide the ground truth. Your job is to confirm the inputs are current and the ranking survives scrutiny.

When to reach for this

• •
  A scan produced more vulnerabilities than the team can patch this cycle and you need a defensible order.
• •
  You want to justify why a medium-CVSS bug is being patched before a critical one (because it's on KEV and internet-facing).
• •
  You're building a repeatable prioritization that combines exploitability feeds with your asset inventory.

The workflow

1. 1.

   Assemble the inputs. For each vulnerability: CVE ID, CVSS, the current EPSS score, KEV membership, and asset context (internet-facing? sensitive data? compensating controls?). Pull EPSS and KEV fresh — they change daily.

2. 2.

   Prompt for a ranked, reasoned priority — and use structured output so it's programmatic. For a repeatable pipeline, drive it through the Anthropic SDK:

   Copy

   import anthropic
   from pydantic import BaseModel
   
   class Ranked(BaseModel):
       cve: str
       priority: int          # 1 = patch first
       tier: str              # "Immediate" | "This cycle" | "Backlog"
       rationale: str         # why this rank, citing EPSS/KEV/asset context
   
   class Plan(BaseModel):
       items: list[Ranked]
   
   client = anthropic.Anthropic()
   response = client.messages.parse(
       model="claude-opus-4-8",
       max_tokens=8000,
       thinking={"type": "adaptive"},
       messages=[{
           "role": "user",
           "content": (
               "Rank these vulnerabilities for patching by REAL exploitability, "
               "not raw CVSS. Weight KEV membership and high EPSS above CVSS, and "
               "weight internet-facing / sensitive assets above internal ones. "
               "Cite the specific signals in each rationale.\n\n" + vuln_table
           ),
       }],
       output_format=Plan,
   )
   plan = response.parsed_output
   for item in plan.items:
       print(item.priority, item.cve, item.tier, "-", item.rationale)
   

   Expected output: a validated ranking where a KEV-listed, high-EPSS, internet-facing medium sits above a critical that's internal-only with no known exploit — each with a rationale you can quote to leadership.

3. 3.

   Sanity-check the top of the list against KEV directly. Anything on CISA KEV is being exploited now; confirm every KEV item landed in the Immediate tier regardless of CVSS.

4. 4.

   Reconcile with asset reality. The model only knows the asset context you fed it. Cross-check the top items against your CMDB — is the "internet-facing" flag still true? Is there a compensating control (WAF rule, network segmentation) that changes the urgency?

5. 5.

   Produce the patch plan. Group by tier, attach the rationale, and hand it to the owners — the rationale is what gets a disruptive emergency patch approved.

Verify before you trust it

• Confirm the feeds are current. EPSS and KEV update daily; a stale snapshot ranks yesterday's risk. Re-pull before every prioritization run and check the dates.
• Confirm KEV items are all at the top. Known-exploited is the strongest signal there is. If a KEV CVE ranked below a non-KEV one, the model mis-weighted — override it.
• Verify asset context, don't assume it. The ranking is only as good as the "internet-facing" and "sensitive" flags you supplied. Confirm the top items' context against the real inventory before you commit resources.
• Re-derive a couple of rankings by hand. Pick two items and reason through them yourself. If your ordering disagrees with the model's, find out why before trusting the rest.

Pitfalls

• Stale exploitability data. The entire advantage over CVSS-only is fresh EPSS/KEV signal. A cached feed throws that away.
• Treating the model's rank as final. It's a proposal grounded in the data you gave it; the KEV cross-check and asset reconciliation are what make it defensible.
• Ignoring compensating controls. A high-EPSS bug behind strong segmentation may genuinely be lower priority than the raw signal suggests — but only if the control is real and verified.
• Feeding wrong asset context. "Internal-only" for an asset that's actually reachable inverts the priority. Garbage context, garbage ranking.
• Over-rotating on EPSS alone. EPSS is a probability, not a certainty; pair it with KEV and asset value rather than treating a high score as a mandate.

Tools

• EPSS (FIRST)free daily exploitation-probability scores; the forward-looking signal CVSS lacks.
• CISA KEV catalogfree authoritative list of vulnerabilities confirmed exploited in the wild; the strongest single prioritization input.
• An LLM (Claude-class)fuses the feeds with asset context into a ranked, explained plan you can defend to stakeholders.

Client-safe variant

Vulnerability inventories reveal a client's weak spots and asset topology — sensitive if leaked. EPSS and KEV are public feeds, so you can enrich locally without exposing anything. Before prompting, replace real hostnames and asset identifiers with roles ("public API gateway", "internal HR DB") — the ranking logic only needs exposure and sensitivity, not names. Where the client bars external AI, run a local model for the reasoning; the feeds are just data files you already hold. Keep the patch plan in the client's own tracker and confirm per-client tool approval before sending any inventory detail outward.