You're spending hours each week triaging CVE feeds, debating patch windows with application owners, and watching your backlog grow faster than you can manage. Meanwhile, threat actors aren't targeting your entire vulnerability list. They're focusing on the CISA Known Exploited Vulnerabilities Catalog, exploiting the same flaws across thousands of organizations.
CISA recently added CVE-2026-81578 and CVE-2026-82078 affecting PaperCut NG/MF to the KEV Catalog. If you're running PaperCut and you learned about these vulnerabilities here instead of from your patch queue, your process needs improvement.
Here's how to build a KEV-driven vulnerability management pipeline that prioritizes actual risk over CVSS scores.
The Problem
Your vulnerability scanner finds everything, but your team can't fix everything. This gap is where breaches occur.
Traditional vulnerability management treats all CVEs as equally urgent until you apply a mix of CVSS score, asset criticality, and intuition. The result: you're patching theoretical risks while known-exploited vulnerabilities remain in your backlog because they scored 7.2 instead of 9.8.
Binding Operational Directive 26-04 requires federal agencies to prioritize KEV Catalog vulnerabilities on publicly exposed assets that grant total control post-exploitation. You don't need to wait for a mandate. The KEV Catalog is public, updated continuously, and shows exactly what attackers are using right now.
What You Need Before Starting
Access and permissions:
- Read access to your vulnerability scanner's API (Tenable, Qualys, Rapid7, or similar)
- Write access to your ticketing system API (Jira, ServiceNow, etc.)
- CISA KEV Catalog JSON feed: CISA KEV Catalog JSON feed
Technical requirements:
- Python 3.8+ environment (or equivalent scripting capability)
- Requests library for API calls
- JSON parsing capability
- Scheduled task runner (cron, Task Scheduler, or CI/CD pipeline)
Organizational requirements:
- Defined asset inventory with public vs. internal classification
- SLA agreement: KEV vulnerabilities on public assets get 48-72 hour remediation windows
- Escalation path when application owners push back
Step-by-Step Implementation
Step 1: Pull and Parse the KEV Catalog
Create a script that fetches CISA's KEV feed daily:
import requests
import json
from datetime import datetime
def fetch_kev_catalog():
url = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"
response = requests.get(url)
kev_data = response.json()
# Extract CVE IDs into a set for fast lookup
kev_cves = {vuln['cveID'] for vuln in kev_data['vulnerabilities']}
return kev_cves, kev_data
Store the full catalog locally. You'll need vendor names, product names, and required action dates for context when talking to asset owners.
Step 2: Query Your Scanner for KEV Matches
Connect to your vulnerability scanner's API and filter for KEV-listed CVEs:
def get_scanner_vulns_matching_kev(scanner_api_url, api_key, kev_cves):
headers = {"X-ApiKeys": f"accessKey={api_key}"}
# This example uses Tenable.io syntax; adjust for your scanner
payload = {
"query": {
"field": "plugin.attributes.cve",
"operator": "in",
"value": list(kev_cves)
}
}
response = requests.post(
f"{scanner_api_url}/workbenches/vulnerabilities",
headers=headers,
json=payload
)
return response.json()
Step 3: Classify by Exposure
Not every KEV vulnerability deserves the same urgency. BOD 26-04 focuses on publicly exposed assets that grant total control. Build that logic into your pipeline:
def classify_kev_findings(vulns, asset_inventory):
high_priority = [] # Public + grants total control
medium_priority = [] # Public but limited impact
low_priority = [] # Internal only
for vuln in vulns:
asset = asset_inventory.get(vuln['asset_id'])
if not asset:
continue
is_public = asset.get('exposure') == 'public'
grants_control = vuln.get('exploitability') in ['RCE', 'Authentication Bypass']
if is_public and grants_control:
high_priority.append(vuln)
elif is_public:
medium_priority.append(vuln)
else:
low_priority.append(vuln)
return high_priority, medium_priority, low_priority
The PaperCut vulnerabilities (CVE-2026-81578 is a missing authentication flaw, CVE-2026-82078 is unsafe reflection) both qualify as high-priority if your print management server is reachable from the internet.
Step 4: Auto-Generate Remediation Tickets
Create tickets automatically with all the context your team needs:
def create_remediation_ticket(vuln, kev_entry, ticketing_api):
ticket = {
"summary": f"KEV-URGENT: {vuln['cve']} in {vuln['product']} on {vuln['hostname']}",
"description": f"""
CISA Known Exploited Vulnerability detected.
CVE: {vuln['cve']}
Asset: {vuln['hostname']} ({vuln['ip']})
Product: {vuln['product']} {vuln['version']}
Exposure: Public-facing
CISA Required Action: {kev_entry['requiredAction']}
Due Date: {kev_entry['dueDate']}
Evidence of active exploitation exists. Prioritize immediately.
""",
"priority": "Critical",
"labels": ["KEV", "public-exposure"],
"due_date": kev_entry['dueDate']
}
response = requests.post(ticketing_api, json=ticket)
return response.json()
Step 5: Schedule and Monitor
Run this pipeline daily at minimum. When CISA adds new KEV entries, you want tickets created before your next standup.
Set up monitoring:
- Alert when KEV count increases but no new tickets are created (pipeline failure)
- Track median time from KEV publication to ticket creation
- Measure time from ticket creation to closure for KEV vs. non-KEV vulnerabilities
Validation
Test your pipeline before trusting it in production:
Verify KEV feed parsing: Check that your script correctly identifies CVE-2026-81578 and CVE-2026-82078 in the current catalog. Print the vendor name (PaperCut), product name (NG/MF), and required action.
Confirm scanner integration: Manually verify that your scanner has detected at least one KEV-listed vulnerability. Run your query and confirm the CVE appears in results.
Test ticket creation: Create a test ticket for a known KEV vulnerability. Verify that priority is set to Critical, labels are applied, and the description includes CISA's required action.
Validate classification logic: Run a sample asset through your exposure classification. Confirm that a public-facing web server with RCE gets tagged high-priority while an internal file share with the same CVE gets tagged low-priority.
Maintenance and Ongoing Tasks
Daily:
- Automated KEV feed pull and comparison
- Ticket creation for new matches
- Review of overdue KEV remediation tickets
Weekly:
- Audit for KEV vulnerabilities that closed without patching (verify compensating controls are documented)
- Review classification accuracy (spot-check 5-10 assets to confirm public/internal designation is current)
Monthly:
- Compare your KEV remediation SLA performance against non-KEV vulnerability SLA
- Update asset exposure classifications as network architecture changes
- Review false positives (scanner detected a vulnerability in a product you don't actually run)
Quarterly:
- Validate that your asset inventory exposure data is accurate (public vs. internal)
- Test your escalation path by running a tabletop exercise: "CISA adds a KEV affecting your VPN appliance at 4 PM Friday. Walk through the process."
When CISA updates the catalog: Your pipeline should handle this automatically, but monitor your alert channels. If CISA adds a vulnerability affecting infrastructure you know you're running and you don't get a ticket within 24 hours, your pipeline has failed.
The KEV Catalog isn't perfect. It won't catch zero-days, and it lags behind the absolute cutting edge of threat intelligence. But it's evidence-based, continuously updated, and shows what's working in the wild. If you're still prioritizing vulnerabilities by CVSS score alone, you're focusing on the wrong metric.
