Purpose of the Template
Your vulnerability scanner just flagged 847 CVEs across your infrastructure. Which ones do you patch first?
This template helps your team build a risk-based vulnerability management workflow using CISA's Known Exploited Vulnerabilities Catalog as a prioritization filter. While Binding Operational Directive (BOD) 26-04 mandates this approach for Federal Civilian Executive Branch agencies, the same logic applies to any organization that can't patch everything immediately.
The template provides:
- A decision matrix for triaging vulnerabilities
- Asset classification criteria aligning with BOD 26-04's "total control" threshold
- Automated KEV Catalog checks for your scanning workflow
- Documentation scripts for audit evidence
Use this when your team needs to justify why you patched vulnerability X within 48 hours but deferred vulnerability Y for 30 days.
Prerequisites
Before implementing this template, ensure you have:
Technical requirements:
- A vulnerability management platform supporting API integration or CSV import (Tenable, Qualys, Rapid7, or similar)
- Access to CISA's KEV Catalog JSON feed
- An asset inventory with exposure classification (internet-facing vs. internal)
Organizational requirements:
- Defined asset tiers (critical, high, standard) based on business impact
- Documented patching SLAs that you're willing to override for KEV-listed vulnerabilities
- Authority to prioritize KEV remediation over routine maintenance windows
Knowledge requirements:
- Understanding of "total control post-exploitation" for your environment (root access, domain admin, database compromise)
- Familiarity with your organization's change management process
If you don't have asset tiers defined, start there. This template won't work if you're treating a public-facing authentication server the same way you treat a development sandbox.
The Template
Part 1: KEV-Based Vulnerability Decision Matrix
VULNERABILITY TRIAGE WORKFLOW
Step 1: Check KEV Catalog Status
- Query CISA KEV Catalog for CVE-[ID]
- If listed → Proceed to Step 2
- If not listed → Route to standard risk scoring
Step 2: Assess Asset Exposure
- Is asset internet-facing? [YES/NO]
- Does asset handle authentication? [YES/NO]
- Does exploitation grant total control? [YES/NO]
Step 3: Apply Remediation Timeline
IF KEV-listed AND internet-facing AND total control = CRITICAL PATH
→ Remediate within 48 hours
→ Document pre-patch compromise check
→ Notify security leadership
IF KEV-listed AND internet-facing = HIGH PRIORITY
→ Remediate within 7 days
→ Standard change management
IF KEV-listed AND internal-only = ELEVATED PRIORITY
→ Remediate within 14 days
→ Consider network segmentation as interim control
Step 4: Document Decision
- Log CVE, asset ID, KEV status, and chosen timeline
- Record justification for any timeline extension
- Capture pre-patch security event review
Part 2: Automated KEV Check Script (Python)
import requests
import json
def check_kev_status(cve_id):
"""
Queries CISA KEV Catalog to determine if CVE is actively exploited
Returns: dict with KEV status and remediation deadline if applicable
"""
# Fetch current KEV Catalog
kev_url = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"
response = requests.get(kev_url)
kev_data = response.json()
# Search for CVE in catalog
for vuln in kev_data['vulnerabilities']:
if vuln['cveID'] == cve_id:
return {
'in_kev': True,
'vendor': vuln['vendorProject'],
'product': vuln['product'],
'description': vuln['vulnerabilityName'],
'due_date': vuln['dueDate'],
'required_action': vuln['requiredAction']
}
return {'in_kev': False}
def classify_asset_risk(internet_facing, grants_total_control):
"""
Determines remediation priority based on asset characteristics
Mirrors BOD 26-04 logic for non-federal environments
"""
if internet_facing and grants_total_control:
return 'CRITICAL', 48 # hours
elif internet_facing:
return 'HIGH', 168 # 7 days in hours
else:
return 'ELEVATED', 336 # 14 days in hours
# Usage example
cve = "CVE-2026-9198"
kev_result = check_kev_status(cve)
if kev_result['in_kev']:
priority, sla_hours = classify_asset_risk(
internet_facing=True,
grants_total_control=True
)
print(f"{cve} is KEV-listed: {priority} priority, patch within {sla_hours} hours")
Part 3: Pre-Patch Compromise Assessment Checklist
SECURITY EVENT REVIEW (Complete before patching KEV vulnerabilities)
Asset: _____________________
CVE: _______________________
Date of KEV addition: _______
Date vulnerability disclosed: _______
Review the following logs for the period between disclosure and patch:
[ ] Authentication logs
- Failed login attempts from unusual IPs
- Successful logins outside normal patterns
- Privilege escalation events
[ ] Network traffic logs
- Connections to/from asset on unusual ports
- Data exfiltration indicators (large outbound transfers)
- Command-and-control patterns
[ ] Application logs
- Error messages indicating exploit attempts
- Unusual API calls or input patterns
- File access outside normal operations
[ ] Endpoint detection
- Process execution anomalies
- Persistence mechanism creation
- Lateral movement indicators
FINDING: [NO EVIDENCE OF COMPROMISE / SUSPICIOUS ACTIVITY DETECTED]
If suspicious activity detected:
- Escalate to incident response team before patching
- Preserve forensic evidence
- Consider asset isolation
Reviewed by: _______________ Date: ___________
Customizing the Template
Adjust timelines based on your change management constraints. The 48-hour critical path assumes you can execute emergency changes. If your environment requires change advisory board approval, build that time into your SLA or establish a pre-approved KEV remediation process.
Modify "total control" criteria for your technology stack. BOD 26-04 focuses on vulnerabilities that grant complete asset control. For your environment, define this explicitly:
- Web servers: Remote code execution as root/SYSTEM
- Databases: SQL injection leading to admin access
- Authentication systems: Bypass allowing credential theft
- Network devices: Configuration modification access
Integrate with your existing ticketing system. The Python script outputs priority levels. Map these to your ITSM platform's priority field so KEV vulnerabilities automatically jump the queue.
Scale the pre-patch review based on asset criticality. You don't need a full forensic review for every KEV vulnerability on every asset. For standard-tier internal assets, a basic log check suffices. Reserve the detailed checklist for internet-facing critical systems.
Add compensating controls to the decision matrix. If you can't patch immediately, document interim mitigations:
- Web application firewall rules blocking known exploit patterns
- Network segmentation isolating vulnerable assets
- Enhanced monitoring for exploitation indicators
Validation Steps
After implementing this template, verify it's working:
Week 1: Test the automation
- Manually check three CVEs from CISA's KEV Catalog
- Confirm your script correctly identifies them as KEV-listed
- Verify priority assignments match your decision matrix
Week 2: Audit historical decisions
- Pull the last 30 days of vulnerability remediation tickets
- Identify any KEV-listed CVEs you patched under standard timelines
- Calculate how many would have received faster remediation under this workflow
Week 3: Validate documentation quality
- Select five KEV vulnerabilities your team remediated
- Review pre-patch compromise assessments for completeness
- Confirm you can demonstrate due diligence to an auditor
Ongoing: Monitor KEV additions
- Set up automated alerts when CISA adds vulnerabilities to the catalog
- Cross-reference new KEV entries against your asset inventory within 24 hours
- Track your mean time to remediation for KEV vulnerabilities vs. non-KEV
The real test: Can you explain to your CISO why you delayed patching a CVSS 9.8 vulnerability to prioritize a CVSS 7.2 that appeared in the KEV Catalog? If your documentation supports that decision, the template is working.
