Kev Catalog Workflow

Prerequisites

• Target system, dependencies and environment configured.

Usage

Purpose

Among all the signals for prioritising vulnerabilities, one stands above the rest: is it being exploited right now in the real world? CISA's Known Exploited Vulnerabilities (KEV) catalog is the authoritative list of exactly that — CVEs with confirmed in-the-wild exploitation. This skill covers building KEV into your workflow so a confirmed-exploited vulnerability automatically jumps the queue, because observed reality beats every predicted-severity score.

When to use it

As a standing input to vulnerability prioritisation, checked continuously (the catalog is updated as new exploitation is confirmed). It's the strongest single prioritisation signal and one of the easiest to operationalise, which makes it a high-value, low-effort addition to any programme.

Why KEV matters

• Most vulnerabilities are never exploited; KEV is the subset that definitely is. That confirmed-in-the-wild status is a stronger signal than any severity score (CVSS says how bad it could be) or even prediction (EPSS estimates likelihood). KEV is observed fact.
• It's authoritative and free (CISA maintains it), and each entry comes with a due date for US federal agencies — a useful benchmark for your own urgency even if you're not bound by it.

Procedure

1. Ingest the KEV catalog automatically. CISA publishes it (JSON/CSV, updated regularly). Pull it into your vuln pipeline so every finding can be checked against it — don't do this by hand.
2. Flag and elevate matching findings. Any vulnerability in your environment whose CVE is on KEV should automatically escalate to top priority — a "fix now" tier — largely regardless of its CVSS base score. A KEV-listed medium outranks a non-KEV critical.
3. Set an aggressive SLA for KEV items. Confirmed exploitation means the clock is already running; give KEV findings a short remediation window (days), and treat them through the emergency-patch path (see patch-management). CISA's own due dates are a reasonable reference.
4. Cross-reference exposure. A KEV vuln on an internet-facing, unauthenticated asset is a genuine emergency; the same CVE on an isolated internal system is urgent but slightly less so. KEV sets the floor of urgency; your environmental context (cvss-in-context) fine-tunes it.
5. Hunt for signs of exploitation on KEV findings. If a vuln is being exploited in the wild and you have it exposed, assume you might already be a target — pair remediation with a check for indicators of compromise (feeds threat hunting / IR).
6. Report KEV status prominently — "number of KEV-listed vulnerabilities open, and for how long" is one of the most meaningful metrics you can show leadership (feeds the reporting skill).

Cheatsheet

KEV = CISA's list of CVEs with CONFIRMED in-the-wild exploitation
  strongest prioritisation signal (observed reality > CVSS 'could' > EPSS 'likely')
  authoritative + free ; entries carry a federal due date (useful benchmark)

workflow
  1. ingest KEV automatically (CISA JSON/CSV, updated regularly)
  2. match findings -> KEV-listed = jump to "fix now" tier (near-regardless of CVSS)
  3. aggressive SLA (days) + emergency-patch path
  4. exposure cross-check: KEV + internet-facing + unauth = genuine emergency
  5. KEV + exposed -> also hunt for IoCs (you may already be targeted)
  6. report "open KEV count + age" -> top-tier leadership metric

rule: a KEV-listed medium outranks a non-KEV critical.

Reading KEV in your data

• A KEV-listed vulnerability open in your environment = confirmed-exploited and unfixed; the single most urgent class of finding. It should already be escalated by an automated rule, not discovered manually.
• A KEV item on an exposed, unauthenticated asset = a genuine emergency and a reason to also look for signs you've been hit, not just to patch.
• KEV findings sitting past a short SLA = the highest-severity governance failure a vuln programme can have — known-exploited holes left open. This is the metric to escalate hardest.
• A backlog sorted by CVSS that buries a KEV medium under non-KEV criticals = the prioritisation gap KEV fixes; the exploited medium is the real risk.
• KEV ingested, matched, escalated, and remediated fast, with open-KEV reported to leadership = a programme prioritising by reality.

The fix / best practice

• Automate KEV ingestion and matching so confirmed-exploited findings self-escalate; manual checking doesn't scale and misses the point.
• Give KEV findings a top-priority tier and a short SLA, routed through the emergency-patch path.
• Combine with exposure context — KEV sets the urgency floor, environmental exposure fine-tunes it, and KEV + exposed also triggers threat-hunting.
• Track and report open KEV count and age as a headline metric — it's meaningful to any audience and drives action.
• Use KEV alongside EPSS and severity, not instead of them — KEV covers confirmed exploitation, EPSS predicts the rest, severity sizes the impact; together they order the backlog by real risk.

Pitfalls

• Not using KEV at all. Prioritising by CVSS alone while ignoring the authoritative list of what's actually being exploited leaves known-exploited holes buried under theoretical criticals. It's free and high-value — use it.
• Manual KEV checking. It doesn't scale and lags; automate ingestion and matching so escalation is immediate.
• Treating KEV as just another data point. It's confirmed exploitation — the strongest signal. A KEV-listed vuln jumps the queue; don't let its CVSS score demote it.
• KEV without exposure context. KEV + internet-facing is an emergency; the context still matters for fine-tuning and for deciding whether to hunt for compromise.
• Leaving KEV items open past SLA. Known-exploited and unfixed is the worst state to be in; these get the hardest escalation.

References

• CISA Known Exploited Vulnerabilities Catalog (cisa.gov/known-exploited-vulnerabilities-catalog)
• CISA Binding Operational Directive 22-01 (the KEV remediation mandate and due dates)
• The epss-and-exploit-likelihood, cvss-in-context, patch-management, and reporting skills

Inputs

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

Outputs

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