Your inbox has fourteen CVEs flagged as critical, all scoring 9.0 or higher. Your patching window is Tuesday night. Which four do you fix first?
CVSS scores measure theoretical severity—how bad things could get if an attacker chains the right conditions. They don't measure likelihood or business impact. A 9.8 CVE in a Python library you installed once for testing is not the same as a 9.1 in your public-facing web server with active exploitation in the wild.
I've seen teams patch in CVSS order and miss the actively exploited 7.5 that mattered. Here's how to build a triage framework that works.
Factor One: Active Exploit Availability
Start here. Is there a public proof-of-concept? A Metasploit module? Evidence of exploitation in the wild?
A CVE with working exploit code gets immediate attention, regardless of score. The window between disclosure and mass scanning is measured in hours for popular services. I've watched Apache Struts vulnerabilities go from disclosure to automated scans hitting our honeypots in under six hours.
Check these sources when a new CVE drops:
- ExploitDB and GitHub for proof-of-concept code
- Metasploit modules (searchsploit on Kali makes this fast)
- CISA's Known Exploited Vulnerabilities catalog
- Vendor security advisories for "active exploitation" language
- Your IDS/IPS logs for related signatures firing
No public exploit? You have breathing room. That 9.8 without a PoC can wait behind the 8.1 with a one-liner curl exploit.
Exploitation Complexity Matters Too
Some CVEs require local access, user interaction, or a chain of conditions. Others work with a single HTTP request. Read the actual vulnerability description, not just the score.
A remote code execution that needs an authenticated admin session is serious but less urgent than an unauthenticated RCE. Check the attack vector field: network, adjacent, local, or physical. Network-based attacks with low complexity jump the queue.
Factor Two: Asset Exposure and Accessibility
Where is the vulnerable service running, and who can reach it?
A critical flaw in a server sitting behind three firewall layers, accessible only from your office VPN, is not the same as the same flaw in your public web server. Exposure determines opportunity.
Map your vulnerable assets by:
# Find listening services and their exposure
netstat -tulnp | grep LISTEN
# Check if a service is reachable externally
nmap -p <port> <your-public-ip>
# Review firewall rules
iptables -L -n -v
# or for firewalld
firewall-cmd --list-all
Prioritize patches for:
- Internet-facing services (web servers, mail servers, DNS)
- Services handling sensitive data (databases with customer records)
- Systems with privileged access (hypervisors, backup servers)
- Jump hosts and bastion servers
- Internal services come last unless they're identity providers
A 9.5 CVE in an internal GitLab instance behind VPN can wait. The same CVE in your customer-facing cPanel server cannot.
Factor Three: Data Classification and Business Impact
What runs on the vulnerable system, and what happens if it's compromised?
I use a simple matrix: data sensitivity times service criticality. A vulnerability in a dev server hosting test data rates lower than the same flaw in production email routing customer support tickets.
Ask these questions:
- Does this system process payment data, health records, or PII?
- Would downtime break SLAs or customer access?
- Is this system a pivot point to other infrastructure?
- What's the recovery time if this gets ransomwared?
Systems with high business impact need patches first, even if exposure is moderate. Your billing platform or primary DNS server can't wait for the next maintenance window just because it's not directly internet-facing.
Compliance and Audit Implications
PCI-DSS requires high-severity vulnerabilities patched within thirty days. HIPAA doesn't specify timelines but auditors ask for documented risk assessments. If you're in a regulated industry, known vulnerabilities in production become audit findings fast.
Critical CVEs in cardholder data environments get patched immediately or you document compensating controls. There's no third option.
Factor Four: Vendor Response and Patch Maturity
Is a patch even available? How long has it been out? Has it caused issues?
A day-zero CVE with no patch yet needs mitigation, not patching. You're looking at firewall rules, service isolation, or temporary shutdown. But once a patch drops, timing matters.
Patches released in the last 24 hours are higher risk. Wait for the first round of testing unless exploitation is active. I've seen emergency kernel patches that panicked systems on reboot and OpenSSL updates that broke reverse proxy configs.
Check vendor changelogs and forums:
- Are there reports of patch-induced breakage?
- Did the vendor release a revised patch within hours (red flag)?
- Is this a hotfix or part of a regular release cycle?
Patches that have been out for a week with no incident reports are safer. Test in dev first, but don't delay long—if the patch is stable and the CVE is critical, waiting another week just expands your window of vulnerability.
What If No Patch Exists?
You need a workaround or compensating control:
- Disable the vulnerable feature if it's not required
- Apply firewall rules to limit exposure
- Implement WAF rules to block known exploit patterns
- Increase monitoring and alerting for indicators of compromise
- Consider replacing the component with an alternative
Document your decision and set a review date. The moment a patch drops, reevaluate.
Factor Five: Dependency Chain and Patch Overhead
Some patches are easy. Others require downtime, database migrations, or break dependencies.
A kernel patch needs a reboot. That's downtime. A PHP update might break legacy code relying on deprecated functions. An OpenSSL upgrade can require recompiling everything linked against it.
Weigh urgency against disruption:
- Can you patch during your regular maintenance window?
- Does this patch require coordinated updates across a cluster?
- Will this break integrations or require code changes?
- Do you have rollback procedures tested?
For high-overhead patches, you might stage the work: mitigate with network controls first, then schedule the full patch during planned maintenance. Low-overhead patches (updating a WordPress plugin, patching a library) can happen immediately.
Testing Before Production
Always test patches in a non-production environment that mirrors production. Spin up a VM or container with the same OS version and service config:
# Clone production config to test system
scp user@prod:/etc/apache2/apache2.conf /etc/apache2/
# Apply patch
apt-get update && apt-get install <package>
# Verify service stability
systemctl status apache2
apachectl configtest
# Check logs for errors
tail -f /var/log/apache2/error.log
Run your smoke tests. If it breaks, you found out in dev, not at 2 AM in production.
Building Your Prioritization Workflow
Here's the checklist I use when triaging a batch of CVEs:
- Triage by exploit status: Separate CVEs with active exploitation or public exploits from theoretical vulnerabilities.
- Map exposure: Identify which vulnerable systems are internet-facing or handle sensitive data.
- Score business impact: Rate each system by criticality and data classification.
- Check patch availability: Confirm a stable patch exists and review any known issues.
- Estimate patch overhead: Flag patches requiring downtime, testing, or dependencies.
- Create priority tiers: - Tier 0 (patch this week): Active exploitation + internet-facing + patch available - Tier 1 (patch within 2 weeks): Public exploit or high exposure + critical service - Tier 2 (patch within 30 days): High CVSS but no active exploit, moderate exposure - Tier 3 (next regular cycle): Low exposure, low impact, or no patch yet
Document your decisions. When an auditor or manager asks why you patched CVE-X before CVE-Y with the higher score, you have a rationale.
What to Prioritize First
CVSS scores are a starting point, not the finish line. When you're staring at a dozen critical CVEs, start with the ones being actively exploited, face the internet, and have stable patches. Business impact and patch complexity determine your timeline.
The goal isn't to patch everything instantly. It's to patch the right things in the right order before an attacker makes the choice for you.