Why This Matters
Your vulnerability scanner just flagged 847 CVEs across your environment. Your patch management team can realistically address maybe 30 this sprint. Which ones should you prioritize?
Most teams default to CVSS scores, but that metric doesn't tell you what attackers are actually exploiting right now. The CISA Known Exploited Vulnerabilities Catalog solves this problem by tracking CVEs with confirmed active exploitation. Recent additions like CVE-2025-68686 (Fortinet FortiOS) and CVE-2026-16812 (Arista VeloCloud Orchestrator) show the catalog updates continuously as new threats emerge.
Binding Operational Directive 26-04 requires Federal Civilian Executive Branch agencies to prioritize KEV remediation on publicly exposed assets that grant total control post-exploitation. While BOD 26-04 doesn't apply to commercial organizations, the directive's risk-based approach offers a practical framework you can adopt. If you're treating all vulnerabilities equally, you're wasting time on theoretical risks while active threats sit unpatched.
What You Need Before Starting
Before integrating KEV into your workflow, ensure you have:
Asset Inventory with Exposure Classification
You need to know which systems are internet-facing versus internal-only. BOD 26-04 specifically targets publicly exposed assets because they're immediately accessible to attackers. If you don't have this mapped, start with your perimeter scan results or cloud security posture management tool.
API Access or Automation Capability
CISA publishes the KEV Catalog as a machine-readable JSON feed at https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json. You'll need to pull this data into your vulnerability management platform. Most enterprise tools (Tenable, Qualys, Rapid7) already support KEV tagging, but verify your version includes it.
Defined Remediation SLAs
BOD 26-04 sets specific timelines for federal agencies based on asset criticality. You'll need equivalent internal SLAs. A common commercial approach: 7 days for KEV on externally-facing critical assets, 14 days for internal critical systems, 30 days for non-critical.
Change Control Process for Emergency Patching
KEV vulnerabilities require faster action than your normal monthly patch cycle. Make sure your change advisory board has an expedited approval path.
Step-by-Step Implementation
1. Ingest the KEV Feed into Your Vulnerability Scanner
If your platform doesn't natively support KEV tagging, build a simple integration:
# Daily cron job example
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
-o /var/vuln/kev_catalog.json
# Parse and tag vulnerabilities in your CMDB
python3 tag_kev_vulns.py --source /var/vuln/kev_catalog.json \
--cmdb-api https://your-cmdb/api/v2/vulnerabilities
The JSON feed includes CVE ID, vendor/product, vulnerability name, date added, required action, and due date (for federal agencies). You're primarily interested in the CVE list to cross-reference against your scan results.
2. Create KEV-Specific Vulnerability Views
Build filtered reports that separate KEV vulnerabilities by exposure:
- Critical KEV + Public Exposure: These get immediate attention. Cross-reference your KEV list against assets tagged as internet-facing in your asset inventory.
- Critical KEV + Internal Only: Still high priority, but slightly longer remediation window since exploitation requires initial access.
- KEV + Non-Production: Patch these during your next deployment cycle, but don't ignore them entirely.
Tag each vulnerability with its CISA "required action" field. Some entries specify "Apply mitigations per vendor instructions" rather than just "update to version X.X." This distinction matters when patches aren't immediately available.
3. Implement Automated Alerting
Configure notifications when new KEV entries match your environment:
# Pseudo-logic for alerting rule
IF (new_kev_entry.cve IN current_scan_results)
AND (affected_asset.exposure = "public")
THEN send_alert(security_team, severity=CRITICAL)
create_jira_ticket(project=VULN, priority=P1)
notify_asset_owner(affected_asset.owner)
Don't wait for your weekly vulnerability review meeting. KEV additions indicate active exploitation, so you need same-day awareness.
4. Establish Pre-Exploitation Compromise Checks
BOD 26-04 requires agencies to check for compromise before patching certain KEV vulnerabilities. Adopt this practice by creating runbooks for common exploitation indicators:
- Review authentication logs for unusual access patterns in the 30 days before patch deployment
- Check for unexpected file modifications in application directories
- Scan for known indicators of compromise associated with the CVE (if published)
- Query your SIEM for the specific exploit signatures or post-exploitation behaviors
Document this as a mandatory step in your emergency patch process. If you find evidence of exploitation, immediately escalate to your Computer Security Incident Response Team rather than just patching.
5. Track Remediation Velocity
Measure your team's performance against KEV timelines:
KEV Remediation Rate = (KEV vulns patched within SLA) / (total KEV vulns identified)
Mean Time to Remediate (KEV) = average days from KEV addition to patch deployment
Compare this against your standard vulnerability remediation metrics. If your KEV response isn't faster than your baseline, your prioritization isn't working.
Validation - How to Verify It Works
After implementing your KEV workflow, validate it's functioning:
Run a Test Scenario
Pick a historical KEV entry that affected your environment. Manually add it back to the catalog feed and verify your automation triggers alerts, creates tickets, and routes to the correct teams within your target timeframe.
Audit Your Exposure Accuracy
Pull a random sample of assets tagged as "publicly exposed" and verify they're actually reachable from the internet. Use an external scanner or penetration testing tool to confirm. Misclassified assets mean you're either over-prioritizing internal systems or under-prioritizing exposed ones.
Check Your API Feed Freshness
CISA updates the KEV Catalog as new vulnerabilities emerge. Verify your ingestion job runs daily and compare your internal KEV count against the official catalog count. If they don't match, your feed is stale.
Review a Month of KEV Tickets
Pull your last 30 days of KEV-tagged vulnerabilities and verify each one received accelerated handling compared to non-KEV items. If they're sitting in the same queue with the same SLAs, your process isn't actually prioritizing them.
Maintenance and Ongoing Tasks
Weekly: Review New KEV Additions
CISA doesn't publish a fixed schedule. Check the catalog weekly (or subscribe to CISA alerts) and manually review any additions that affect your technology stack, even if your automation should catch them.
Monthly: Calibrate Your SLAs
Track your actual remediation times and adjust targets if you're consistently missing deadlines or if you're patching so fast you're introducing change-related outages.
Quarterly: Audit Asset Exposure Classifications
Your infrastructure changes. Systems move from internal to DMZ, cloud resources get accidentally exposed, acquisitions bring new public-facing applications. Re-validate your exposure tagging quarterly to ensure KEV prioritization targets the right assets.
Consider Submitting Vulnerabilities
If you discover active exploitation of a CVE not yet in the catalog, submit it through CISA's KEV Nomination Form. You'll need the CVE ID, evidence of exploitation (threat intelligence, logs, or incident data), and confirmation that clear remediation guidance exists. This benefits the broader community and ensures the catalog remains comprehensive.
The KEV Catalog isn't just a federal compliance requirement. It's the closest thing we have to a real-time list of what attackers are actually using. By operationalizing it into your patch workflow, you're shifting from theoretical risk scoring to evidence-based prioritization.
