When a new CVE drops in your inbox at 2 AM, the first question is always the same: patch it now or wait until morning? Not every vulnerability deserves immediate attention. Some CVEs look scary on paper but affect code paths your infrastructure never touches. Others arrive with a low score but pair with public exploits already hammering internet-facing services.
I've watched teams waste weekend nights patching theoretical flaws while leaving actively exploited bugs unpatched for weeks. The difference between reactive chaos and calm triage is a repeatable framework.
Understanding CVSS scoring
The Common Vulnerability Scoring System gives every CVE a numeric severity from 0.0 to 10.0. It's the starting point, not the finish line.
CVSS considers three metric groups. The base score comes from exploitability factors like attack vector, complexity, and required privileges, plus impact metrics covering confidentiality, integrity, and availability. Temporal metrics adjust the score based on exploit maturity and whether a fix exists. Environmental metrics let you customize scoring for your specific deployment, though most organizations skip this step.
A score of 9.0 or higher earns the "Critical" label. High severity covers 7.0 to 8.9, Medium spans 4.0 to 6.9, and anything below 4.0 is Low. These thresholds matter because compliance frameworks and insurance policies often mandate patch windows tied to severity: critical within 15 days, high within 30, medium within 90.
But the raw score doesn't tell you whether the flaw matters in production.
Base score blind spots
Base metrics assume worst-case conditions. A remote code execution bug in a library gets a 9.8 even if your application never calls the vulnerable function. An authentication bypass scores high regardless of whether the affected admin panel sits behind a VPN with MFA enforced.
I've seen critical-rated OpenSSL CVEs cause panic when the vulnerable cipher suite was already disabled months earlier. The CVSS calculator doesn't know your TLS config.
Temporal and environmental adjustments help, but most vulnerability feeds only publish base scores because they're context-free and comparable across vendors.
Checking exploit availability
A vulnerability with working exploit code is a different problem than one requiring six months of reverse engineering.
Public exploit databases like Exploit-DB and GitHub matter here. If proof-of-concept code exists that runs successfully against default configurations, the window for safe patching shrinks fast. Metasploit modules make exploitation trivial for even script kiddies.
Active exploitation in the wild changes everything. CISA's Known Exploited Vulnerabilities catalog tracks CVEs observed in real attacks, often before CVSS scores even get assigned. When CISA flags a CVE, patch schedules compress to days or hours no matter what the score says.
Some CVEs get weaponized within 24 hours of disclosure. The Log4Shell disclosure in late 2021 saw exploit attempts hitting production systems before most teams finished reading the advisory.
Exploit maturity stages
Not all exploit code is equal. Early proof-of-concepts often require precise conditions: specific OS versions, particular application configurations, manual steps an attacker would struggle to automate. These buy you time.
Reliable exploits work against default installs with minimal attacker interaction. When you see "no user interaction required" paired with "exploit code matured," move fast.
Automated scanning and exploitation frameworks represent the final stage. Once Shodan queries exist to find vulnerable hosts and Metasploit modules land, every exposed instance becomes a target.
Mapping asset exposure
A critical CVE in software that only runs on your internal build servers behind three firewall hops is not the same emergency as the same CVE in your public web application.
Internet-facing assets get attacked first. Web servers, mail relays, VPNs, anything with a public IP becomes a target the moment exploit code circulates. These need patching on compressed timelines.
Internal services carry lower urgency unless lateral movement or privilege escalation is your threat model. If an attacker already has a foothold, unpatched internal systems become pivot points. But you have more breathing room than with perimeter services.
Data classification matters
Servers handling payment card data, personal health information, or credentials need tighter patch windows regardless of network position. Compliance frameworks enforce this. PCI-DSS requires high-risk vulnerability remediation within 30 days, but credit card processors often demand weekly patching for cardholder data environments.
Development and test environments can wait longer unless they mirror production data. I've seen dev servers get popped because they ran outdated stacks with production database dumps and no one bothered patching them.
Building your triage matrix
Combine the three factors into a decision matrix. Each dimension gets a rating, and the intersection determines patch priority.
Start with CVSS severity as your Y-axis: Critical, High, Medium, Low. Add exploit availability as your X-axis: Active exploitation, public exploit exists, proof-of-concept only, theoretical. Then filter everything through asset exposure.
Any CVE that scores Critical CVSS + active exploitation + internet-facing asset goes into your P0 emergency bucket. Patch within hours. These are the "drop everything" alerts.
High CVSS + public exploit + internet-facing becomes P1, patched within 48-72 hours. High CVSS + no exploit + internet-facing or Critical CVSS + exploit exists + internal-only both land in P2, giving you up to a week.
Medium-severity bugs on internet-facing infrastructure get P3 priority unless exploit code surfaces. Low-severity findings and anything on isolated development boxes go into P4 for the next maintenance window.
Practical triage checklist
When a new CVE notification arrives, run through these questions in order:
- Do we run the affected software version? Check package managers, container images, dependency trees.
- Is the vulnerable component actually used? Library X might be installed but never imported.
- Are vulnerable code paths reachable in production? An admin API CVE doesn't matter if that endpoint is firewalled.
- What's the CVSS base score? Start with vendor-published scores.
- Does exploit code exist publicly? Search Exploit-DB, GitHub, Metasploit modules.
- Is CISA tracking active exploitation? Check their KEV catalog.
- Where does the software run? Internet-facing, internal, DMZ, isolated dev?
- What data does it access? PCI, PHI, customer credentials, public content?
- What's the blast radius if exploited? Remote code execution, data exfiltration, denial of service?
- Do compensating controls reduce risk? WAF rules, network segmentation, authentication requirements?
Document your answers. The triage decision needs to be repeatable and auditable.
Handling vendor patch lag
Not every CVE gets a patch the same day it's disclosed. Vendors issue security updates on their own schedules, and some move slower than others.
When a critical CVE drops but no patch exists yet, you have three mitigation paths. First option: disable the vulnerable feature if the application can function without it. I've disabled specific PHP functions, turned off unused Apache modules, and blocked endpoints at the load balancer to buy time for proper fixes.
Second: apply vendor workarounds. Security advisories often include configuration changes that reduce risk until patches land. These might be disabling a protocol version, adjusting file permissions, or adding firewall rules.
Third: deploy virtual patches or WAF rules if you run web application firewalls or IPS devices. Signature-based blocking can stop known exploit patterns even when the underlying code remains vulnerable.
So what do you do when the vendor goes silent?
Zero-day response
Zero-days—vulnerabilities exploited before patches exist—demand the fastest response. Monitor threat intelligence feeds. When security researchers or vendors confirm active exploitation, assume you're a target.
Isolate affected systems if possible. Pull them off the public internet, restrict access to known-good sources, increase logging and monitoring. Treat compromise as likely and start hunting for indicators.
If the service is business-critical and can't be taken offline, layer compensating controls aggressively. Extra authentication factors, IP allowlists, rate limiting, anything that raises the exploitation bar.
Automation and tooling
Manual CVE triage doesn't scale past a handful of servers. Automation becomes mandatory.
Vulnerability scanners like OpenVAS, Nessus, or Qualys identify installed software versions and match them against CVE databases. These tools export severity ratings and affected hosts, giving you the raw data for triage.
Patch management platforms like Red Hat Satellite, WSUS, or Ansible Tower let you group systems by criticality and schedule patching waves. You can stage patches to dev environments first, verify nothing breaks, then promote to production on a controlled timeline.
Security information and event management systems ingest CVE feeds and correlate them with asset inventories. SIEM rules can auto-create tickets for high-priority CVEs affecting production, bypassing manual review.
Building a patch workflow
Your workflow should move from detection to remediation with clear hand-offs.
Step one: vulnerability scanners run daily and feed results to a central dashboard. Scan schedules vary by environment—production might get daily scans, dev weekly.
Step two: automation filters CVEs by severity and matches them against your asset database. Anything scoring Critical or High on internet-facing production assets triggers an alert.
Step three: a human reviews the alert against exploit intelligence. Check CISA KEV, vendor advisories, security mailing lists.
Step four: assign a priority tier and create a change ticket. Include rollback procedures in case the patch breaks something.
Step five: test the patch in a non-production environment. This catches incompatibilities before they hit revenue-generating systems.
Step six: deploy to production during a maintenance window for lower-priority patches, or emergency change for P0/P1.
Step seven: rescan to confirm remediation. Closed-loop verification ensures patches actually applied.
Communication during incidents
When you're triaging a critical CVE at 3 AM, someone needs to decide whether to wake the CTO. Clear escalation criteria prevent both under-reaction and false alarms.
Document your priority tiers and map them to notification procedures. P0 emergencies might page the on-call engineer, the security lead, and the infrastructure manager immediately. P1 findings send email alerts but can wait until business hours for action. P2 and below go into the weekly vulnerability review meeting.
Status updates matter for high-priority CVEs. Stakeholders want to know: Are we vulnerable? Is it being exploited? When will we be patched? A templated status message saves time: "CVE-YYYY-XXXXX affects [system]. CVSS 9.8 (Critical). Public exploit exists. Systems are internet-facing. Patching in progress, ETA 4 hours. Monitoring for exploitation attempts."
What to check first
Start with internet-facing infrastructure. Web servers, load balancers, VPN gateways, DNS servers—anything reachable from the public internet gets priority attention. Run vulnerability scans focused on the perimeter.
Next, audit systems handling sensitive data even if they sit internally. Database servers, file shares with compliance-scoped data, authentication providers. These become secondary targets after initial compromise.
Check whether the CVE affects components you thought were disabled. Old Apache modules, unused programming language runtimes, deprecated services. Just because you don't actively use something doesn't mean it can't be exploited.
Review your patch testing procedures now, before the next critical CVE. If you can't rapidly test and deploy patches, the triage framework won't help when minutes count.
FAQ
What if we can't patch immediately?
Deploy compensating controls: disable vulnerable features, add firewall rules, implement virtual patches via WAF, increase monitoring, and document accepted risk with a timeline for remediation.
Should we patch all Critical CVEs within 24 hours?
Not automatically. Triage first. A Critical CVE in a library function your code never calls is lower priority than a High CVE with active exploitation against your public-facing service.
How do we know if a CVE is being exploited in the wild?
Check CISA's Known Exploited Vulnerabilities catalog, monitor security mailing lists, review threat intelligence feeds, and watch for unusual traffic patterns or failed authentication attempts in your logs.
Can we skip Medium and Low CVEs?
Not indefinitely. They accumulate and create technical debt. Schedule regular patching windows for lower-severity findings. Compliance frameworks often require remediation even for Medium-rated vulnerabilities within 90 days.
What's the difference between CVSS 3.x and 4.0?
CVSS 4.0 adds granular scoring for operational technology, refines privilege requirements, and improves environmental metrics. Most vulnerability feeds still publish 3.x scores, so both versions coexist during the transition period.
Patch the right things in the right order
CVE triage isn't about patching everything immediately. It's about deploying limited resources where they matter most. CVSS gives you severity, exploit databases tell you urgency, and asset inventory defines blast radius.
Combine all three factors into a repeatable priority framework. Document your decisions. Automate the detection and filtering. Test patches before deploying them. And when a P0 emergency lands, you'll know exactly which servers to patch first.