CISA KEV-to-Asset Triage Playbook: How to Prioritize Real-World Exploitation Fast

If your patch queue is always full, your biggest risk is not “all vulnerabilities.” It is the subset already being exploited in the wild. That is exactly what CISA’s Known Exploited Vulnerabilities (KEV) catalog gives you: a defender-priority signal you can operationalize today.

This guide shows a practical KEV-to-asset triage workflow for SOC and sysadmin teams. The goal is simple: in about 30 minutes, identify which KEV entries map to your environment, prioritize by exposure, and produce an action list your operations team can execute.

Why KEV should drive daily prioritization

• Threat-informed: KEV entries are tied to observed exploitation, not theoretical CVSS risk.
• Actionable: each entry includes CVE, vendor/product details, and due-date style prioritization patterns used in federal guidance.
• Efficient: helps small teams avoid spending cycles on low-likelihood findings.

For most organizations, a high-severity non-KEV vulnerability on an internal host is often less urgent than a KEV-tagged vuln on an internet-facing edge device.

30-minute KEV triage workflow

Step 1) Pull the latest KEV catalog

Use CISA’s JSON feed and normalize fields you care about:

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json | jq -r '.vulnerabilities[] | [.cveID,.vendorProject,.product,.dateAdded,.dueDate] | @csv' > kev.csv

If you do not have jq, a short Python parser works too:

import requests, csv
u = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"
rows = requests.get(u, timeout=30).json()["vulnerabilities"]
with open("kev.csv","w",newline="",encoding="utf-8") as f:
    w = csv.writer(f)
    w.writerow(["cve","vendor","product","dateAdded","dueDate"])
    for r in rows:
        w.writerow([r.get("cveID"), r.get("vendorProject"), r.get("product"), r.get("dateAdded"), r.get("dueDate")])

Step 2) Export a current asset/software inventory

Any source is fine (EDR, CMDB, vuln scanner, Intune/SCCM, cloud inventory), as long as you can produce CSV with at least:

• hostname or asset_id
• internet_facing (true/false)
• business_criticality (high/med/low)
• software_name / version
• owner_team

Step 3) Build an initial match set

Start with vendor/product keyword matching, then tighten using scanner CVE evidence if available.

import pandas as pd
kev = pd.read_csv("kev.csv")
assets = pd.read_csv("assets.csv")

# coarse candidate matching by vendor/product text
kev["needle"] = (kev["vendor"].fillna("") + " " + kev["product"].fillna("")).str.lower()
assets["sw"] = assets["software_name"].fillna("").str.lower()

matches = []
for _, k in kev.iterrows():
    hit = assets[assets["sw"].str.contains(k["product"].lower(), na=False)]
    for _, a in hit.iterrows():
        matches.append({
            "cve": k["cve"],
            "product": k["product"],
            "asset_id": a["asset_id"],
            "internet_facing": a["internet_facing"],
            "business_criticality": a["business_criticality"],
            "owner_team": a["owner_team"]
        })

pd.DataFrame(matches).to_csv("kev_asset_candidates.csv", index=False)

Do not treat this coarse match as final truth. It is a queue for validation using scanner telemetry, package/version checks, and change windows.

Step 4) Prioritize with an exposure-first score

Create a simple score that operations can understand:

• +50 internet-facing
• +30 business critical = high
• +20 externally reachable management plane (VPN gateway, firewall, OWA, hypervisor, remote admin)
• +10 no compensating control (WAF rule, ACL, IPS signature, temporary disable)

Sort descending and label top items as P1-KEV. This avoids endless severity debates and drives concrete mitigation.

Step 5) Choose mitigation path per asset

• Best: patch/upgrade to fixed version.
• If patch delay is unavoidable: isolate service, restrict exposure, disable vulnerable feature, enforce MFA and conditional access, monitor exploit indicators.
• Document temporary controls with expiry date so exceptions do not become permanent risk.

Detection engineering quick wins

For every high-priority KEV item, create temporary detections that cover exploit and post-exploit behavior:

• Unexpected child processes from edge-facing services (web server, VPN, identity appliance)
• New admin account creation near exploit window
• Suspicious outbound traffic from appliance/server management interfaces
• Authentication anomalies following exploitation (impossible travel, token misuse, brute-force bursts)

Map detections to MITRE ATT&CK techniques so analysts have investigation context and can tune quickly.

Daily operating checklist (copy/paste)

• [ ] Pull latest KEV feed
• [ ] Refresh asset/software inventory
• [ ] Generate KEV-to-asset candidate matches
• [ ] Validate top candidates with scanner/EDR evidence
• [ ] Score by exposure and criticality
• [ ] Open remediation tickets with owner + due date
• [ ] Apply temporary compensating controls where patching is delayed
• [ ] Add/tune detections for top KEV items
• [ ] Report: open P1-KEV count, age, and internet-facing backlog

What success looks like

After 2-3 weeks, you should see:

• Lower mean time to remediate internet-facing KEV exposure
• Fewer “critical but not exploited” distractions in emergency queues
• Cleaner reporting to leadership: risk tied to active exploitation, not generic severity labels

KEV is not your entire vulnerability management strategy?but it is one of the highest ROI inputs for daily defender prioritization. Treat it as your exploitation radar, and build your patch/detection rhythm around it.

References

• CISA Known Exploited Vulnerabilities Catalog
• CISA KEV JSON Feed
• CISA BOD 22-01: Reducing Significant Risk from Known Exploited Vulnerabilities
• MITRE ATT&CK Framework
• NIST Cybersecurity Framework (CSF)