Not every CVE announcement deserves a 3 AM deploy. I've watched teams burn out chasing every published vulnerability while the actually dangerous ones sat unpatched for weeks. The problem isn't laziness—it's the flood of notices hitting your inbox daily and no clear framework for deciding what ships today versus what waits until the maintenance window.
The real cost of patching everything immediately
Patching production systems carries risk. Reboots interrupt service. Updates sometimes break dependencies or introduce regressions. If you treat every CVE as critical, you train your team to ignore alerts altogether or you spend every Tuesday night applying patches that don't materially reduce your threat surface.
In support work I handled, the shops that stayed ahead of real threats had a triage system. They didn't patch slower—they patched smarter. Three factors drove every decision: the vulnerability's base severity, whether working exploits existed in the wild, and which of their assets were actually exposed.
CVSS: the starting point, not the finish line
The Common Vulnerability Scoring System gives you a number between 0.0 and 10.0. Scores of 9.0 or higher get labeled critical. Scores from 7.0 to 8.9 are high. Medium runs 4.0 to 6.9, and anything below 4.0 is low.
That base score comes from six metrics: attack vector (network, adjacent, local, or physical), attack complexity (low or high), privileges required (none, low, or high), user interaction (none or required), scope (unchanged or changed), and the impact on confidentiality, integrity, and availability. A remotely exploitable bug that needs no authentication and compromises all three CIA properties will score near 10.0. A local privilege escalation requiring admin access already will score much lower.
But CVSS is a starting point. A 9.8 score tells you the vulnerability is severe if exploited. It doesn't tell you whether attackers have weaponized it, whether your systems even run the affected component, or whether your network architecture limits exposure.
Temporal metrics adjust for real-world conditions
CVSS includes temporal modifiers that most teams ignore. Exploit code maturity drops from "not defined" to "unproven," "proof-of-concept," "functional," or "high" as public exploits emerge. Remediation level changes from "official fix" to "temporary fix" to "workaround" to "unavailable." Report confidence moves from "unknown" to "reasonable" to "confirmed."
These modifiers lower the score when exploits don't exist yet or when the vendor hasn't confirmed the report. In practice, you'll manually track exploit availability rather than wait for the temporal score to update, but the framework is sound.
Exploit availability changes everything
A critical-scored CVE with no public exploit is a different animal from one with working code on GitHub. When exploit code drops, your window shrinks from weeks to hours.
Monitor a few sources. The Exploit Database archives proof-of-concept code. Metasploit modules mean attackers can exploit the flaw with a few commands. Security researchers publish write-ups on personal blogs and Twitter. CISA's Known Exploited Vulnerabilities catalog lists CVEs actively abused in the wild—if it's on that list, patch it now.
Mass scanning starts within hours
Once a remote code execution exploit goes public, opportunistic attackers start scanning the entire IPv4 space. Services like Shodan and Censys make it trivial to find exposed instances of vulnerable software. I've seen SSH brute-force attempts hit a fresh VPS within minutes of it coming online; exploit scanners move even faster when a juicy RCE drops.
If your service is internet-facing and the CVE has a working exploit, you're in the blast radius.
Asset exposure: context is half the battle
A critical vulnerability in software you don't run isn't your problem. A medium-severity bug in your public-facing web server might be.
Maintain an inventory. What services listen on public IPs? What versions are they running? Which systems handle sensitive data or have admin access to other infrastructure? A vulnerability in a logging agent on an isolated dev box is lower priority than the same flaw in your edge load balancer.
Network segmentation buys you time
If the vulnerable service sits behind a firewall and only accepts connections from a management network, your urgency drops. An attacker needs a foothold inside your perimeter first. That doesn't mean ignore it—it means you can schedule the patch during business hours instead of rolling it at midnight.
Similarly, if the CVE requires local access or an authenticated session, and your authentication layer is solid, the risk is lower than a pre-auth remote exploit.
Data classification matters
A SQL injection in an internal HR system demands faster action than the same flaw in a test environment with dummy data. Think about what an attacker gains if they exploit the vulnerability on that specific asset. Credential theft, data exfiltration, and lateral movement paths all raise priority.
Building a triage matrix
I use a simple decision tree. Start with CVSS score, then adjust for exploit availability and asset exposure.
Patch immediately (same day): - CVSS 9.0+ with public exploit and internet-facing exposure - Any CVE on CISA's KEV catalog affecting your stack - Pre-auth RCE on production services, regardless of score
Patch within 48 hours: - CVSS 7.0-8.9 with public exploit on exposed services - CVSS 9.0+ with no known exploit but network-reachable - Privilege escalation bugs on multi-tenant or shared hosting systems
Patch within one week: - CVSS 7.0+ with no public exploit on exposed services - CVSS 9.0+ on internal-only systems with restricted access - Authentication bypass or credential leaks affecting non-critical apps
Patch during next maintenance window: - CVSS below 7.0 on any system - CVSS 7.0-8.9 on isolated or non-production systems with no exploit - Anything that requires local access on hardened, single-user systems
These aren't universal rules. Adjust thresholds based on your risk tolerance, compliance requirements, and operational constraints. A healthcare provider or financial institution will patch more aggressively than a static marketing site.
What about vendor advisories and compliance?
Some vendors release security bulletins rating their own CVEs as critical even when CVSS says otherwise. Read between the lines. Vendors sometimes inflate severity to cover liability or because they know context you don't—like that the vulnerable code path is enabled by default.
Compliance frameworks like PCI-DSS mandate patching high and critical vulnerabilities within specific windows (often 30 days for high, faster for critical). Those are minimums, not targets. If you're only patching to stay compliant, you're already behind.
Automate where you can, but test first
Unattended-upgrades on Debian-based systems or yum-cron on RHEL can handle routine security updates. Configure them to install updates automatically for specific repos or package categories.
# Debian/Ubuntu - enable automatic security updates
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
But automatic updates can break things. A kernel update might require a reboot. A PHP version bump might incompatible with legacy code. Test updates in staging first for anything that touches your application stack.
For critical infrastructure, I'd rather wake up at 2 AM to patch manually than discover at 8 AM that an automated update took down the mail server.
Track your patch lag
Measure the time between CVE publication and deployment in your environment. If you're consistently two weeks behind on high-severity patches, either your triage process is broken or you need more engineering time budgeted for maintenance.
A simple spreadsheet works: CVE ID, publish date, CVSS score, exploit available (yes/no), affected assets, patch date. Over time you'll spot patterns—maybe a specific vendor is slow to release fixes, or a particular server keeps falling through the cracks.
When patching isn't possible yet
Sometimes a fix doesn't exist, or deploying it would break production. Mitigation buys time.
Firewall rules can block attack vectors. If the CVE exploits a specific URL path, drop requests to that path at the load balancer. If it requires a certain HTTP header, filter it. For local privilege escalation bugs, restrict access to the vulnerable binary or disable the affected feature.
# Block access to a vulnerable script at the firewall
sudo iptables -A INPUT -p tcp --dport 80 -m string --string "/vulnerable.php" --algo bm -j DROP
Web Application Firewalls can catch some exploit attempts if you write rules for known attack patterns. Intrusion detection systems give you visibility when someone probes for the vulnerability.
Mitigation isn't a substitute for patching. It's a stopgap.
What to check first
When a new CVE drops, open the NIST NVD page and read the description. Check the CVSS vector string to understand attack requirements. Search your asset inventory for the affected software and versions. Query your firewall logs to see whether the vulnerable service is exposed.
If exploit code exists and you're exposed, patch immediately. If not, you have time to plan.
The teams that handle this well don't have bigger budgets or more people. They have a decision framework and they stick to it. Triage ruthlessly, patch what matters, and sleep better.
FAQ
Q: Should I always patch critical CVEs before high-severity ones?
Not automatically. A high-severity CVE with active exploitation on an internet-facing asset is more urgent than a critical CVE with no known exploit on an internal system. Score is the starting point; context decides priority.
Q: How do I know if an exploit exists for a CVE?
Check the Exploit Database, search GitHub for the CVE ID, look for Metasploit modules, and monitor security researcher Twitter/blogs. CISA's KEV catalog lists actively exploited CVEs.
Q: What if a vendor hasn't released a patch yet?
Mitigate by disabling the vulnerable feature, blocking attack paths with firewall rules, or isolating the affected system. Pressure the vendor for an ETA and monitor for workarounds in their advisories.
Q: Can I automate CVE triage?
Partially. Vulnerability scanners identify which CVEs affect your environment. CVSS and exploit databases are machine-readable. But deciding business impact and acceptable risk still requires human judgment.
Q: How often should I review my triage process?
Quarterly at minimum. As your infrastructure changes, so does your exposure. After a major incident, audit whether your triage matrix would have caught it earlier.
Patch with purpose
You'll never have zero unpatched CVEs. Perfection isn't the goal—reducing real risk is. Focus on the vulnerabilities that combine high severity, active exploitation, and exposure in your environment. Let the rest wait for scheduled maintenance. That's not cutting corners. It's engineering judgment.