Your monitoring tool lights up with fifteen new CVE alerts this morning. Seven are marked critical. The vendor says patch immediately, but you're running production services and three systems need reboots. Which ones do you fix right now, and which can wait until the maintenance window?
I've handled enough emergency patch cycles to know that "critical" doesn't always mean "drop everything." A filesystem race condition in a desktop package you don't run is less urgent than a remote code execution bug in your public-facing web server, even if both carry the same CVSS score. The scoring framework below gives you a repeatable way to decide.
Why CVSS scores aren't enough
CVSS gives you a severity number, usually between 0.0 and 10.0. Anything above 9.0 is critical. That's useful, but it doesn't account for your environment.
A critical SQLite vulnerability matters if you run apps that use SQLite. It doesn't matter if your stack is PostgreSQL and Redis. CVSS can't see your network layout, your exposed services, or whether proof-of-concept exploit code is circulating on GitHub. You need a second layer.
The three-axis scoring model
I score every CVE on three axes: exposure, exploit maturity, and business impact. Each axis gets 1 to 5 points. Multiply them together for a priority score between 1 and 125.
Exposure (1-5)
- 5: Service is internet-facing and unauthenticated (public web server, DNS resolver, mail relay).
- 4: Service is internet-facing but requires authentication (SSH on port 22, cPanel login, Webmail).
- 3: Service is internal but on a shared network segment (database server on the same VLAN as a compromised WordPress install).
- 2: Service runs locally and binds to localhost only.
- 1: Package is installed but the vulnerable binary isn't running.
If you're unsure, check listening ports:
ss -tuln | grep LISTEN
A service bound to 0.0.0.0 or :: is reachable from outside if your firewall allows it. A service on 127.0.0.1 is not.
Exploit maturity (1-5)
- 5: Public exploit code exists and is being used in the wild (check security mailing lists, your IDS logs, or public exploit databases).
- 4: Proof-of-concept code is public but no widespread exploitation yet.
- 3: Detailed technical write-up exists; skilled attacker could build an exploit in a few hours.
- 2: Vulnerability is documented but exploitation requires deep knowledge or specific conditions.
- 1: Theoretical or requires local access plus another privilege escalation.
Zero-day disclosures with working exploits should always score 5 here. If you see scanner traffic hitting the vulnerable endpoint in your logs, that's a 5.
Business impact (1-5)
- 5: Compromise leads to data breach, regulatory penalty, or total service outage (patient records, payment card data, your only production database).
- 4: Compromise disrupts revenue or violates SLA (e-commerce checkout, customer-facing API).
- 3: Compromise affects internal operations but has workarounds (internal wiki, staging environment).
- 2: Compromise is contained and low-value (isolated dev box, honeypot system).
- 1: Compromise has no material impact (retired service, unused test VM).
Be honest here. Not every server is equally important.
Calculating priority scores
Multiply the three numbers. A CVE that scores 5 × 5 × 5 = 125 needs patching tonight. A CVE that scores 2 × 1 × 3 = 6 can wait for the next maintenance window.
Here's a real example I worked last year. A remote code execution bug in OpenSSH came out. Our environment:
- Production web server: Exposed SSH on port 22, no key-based auth yet (exposure 4). Public exploit available (exploit 5). Hosts customer sites (impact 5). Score: 100. Patched within two hours.
- Internal CI runner: SSH only from office IP range (exposure 3). Same public exploit (exploit 5). Builds code but holds no customer data (impact 2). Score: 30. Patched next morning.
- Archived backup server: SSH disabled, only rsync over cron from one IP (exposure 1). Same exploit (exploit 5). Contains old backups, current ones are on different system (impact 2). Score: 10. Patched during weekend maintenance.
The CVSS score was identical for all three. The risk was not.
Thresholds and response times
Set score thresholds that match your team's capacity:
- 75-125: Patch immediately, even if it means downtime outside the maintenance window. Notify your manager or on-call team lead.
- 30-74: Schedule patching within 24-48 hours. Test in staging first if you have time.
- 10-29: Include in your next regular maintenance cycle (weekly or bi-weekly).
- 1-9: Patch eventually or accept the risk if mitigation is in place.
Your thresholds might differ. A financial services shop might pull the trigger at 50. A personal blog might wait until 100. Adjust based on your risk tolerance and compliance requirements.
What if you can't patch right away?
Sometimes the vendor hasn't released a fix yet, or the patch breaks a critical application. Mitigation buys you time.
Firewall rules can block access to the vulnerable service:
iptables -A INPUT -p tcp --dport 8080 -j DROP
iptables -A INPUT -p tcp --dport 8080 -s 10.0.0.0/8 -j ACCEPT
That drops all traffic to port 8080 except from your internal network. Fast, effective, and reversible.
Web application firewall rules can block specific exploit patterns. If the CVE involves a malformed HTTP header, write a rule to reject requests with that header.
Disabling the vulnerable feature works if the feature isn't required. A CGI execution bug doesn't matter if you disable CGI.
Isolating the system on a separate VLAN and restricting access reduces exposure from 5 to 3. That might drop your priority score below the emergency threshold.
Document every mitigation. When you finally patch, remove the workaround to avoid leaving technical debt.
Automating triage
If you manage more than a handful of servers, manual scoring doesn't scale. I built a small Python script that pulls CVE data from our vulnerability scanner's API, queries each server's listening ports and package list, and calculates scores automatically. High scores trigger a Slack alert; medium scores go into a weekly digest.
You can do the same with any scanner that has an API. The scoring logic is simple arithmetic. The hard part is maintaining accurate asset metadata (which services are public, which data stores are regulated). Keep that in a config file or CMDB.
Watch for cascading dependencies
A low-priority CVE in a library can become high-priority if a public-facing application links against it. Suppose a memory corruption bug in libxml2 scores low because the library isn't directly exposed. Then you realize your Apache instance loads libxml2 through a PHP module, and that Apache serves your customer portal. Re-score the CVE with the web server's exposure.
Check dependencies:
ldd /usr/sbin/httpd | grep libxml2
If you see output, the library is in play.
Track what you deferred
Keep a patching backlog in a spreadsheet or ticket system. For each deferred CVE, record the score, the reason you deferred it, and the planned patch date. Review the backlog weekly. Scores can change—if someone opens a new internet-facing service on the same host, exposure goes up.
I've seen teams defer a CVE with a score of 20, then forget about it. Six months later, an attacker chains it with another bug to gain access. The backlog prevents that.
Common scoring mistakes
I made all of these at some point:
- Overestimating impact because the system "feels" important. If it's a redundant replica with ten others, impact is lower than you think.
- Underestimating exposure because the service runs on a high port. Attackers scan the entire port range. If it's bound to a public IP, it's exposed.
- Ignoring exploit maturity and treating every CVE as equally dangerous. A vulnerability that requires local root access is not the same as a remote code execution with public exploit code.
- Scoring once and never revisiting. Threat landscapes shift. A CVE that scored 15 last month might score 75 today if exploit code dropped.
Re-score at least once a week for unpatched CVEs.
What about false positives?
Vulnerability scanners report a lot of noise. A scanner might flag OpenSSL 1.1.1k as vulnerable to a specific CVE, but you backported the patch as part of your distro's update process. The package version didn't change because your distro doesn't rebase, it backports.
Check the changelog:
rpm -q --changelog openssl | head -n 50
or
apt changelog openssl | head -n 50
If the CVE number appears in the changelog, it's already fixed. Mark it as a false positive in your scanner and move on.
Patch what matters first
You can't patch everything instantly. Scoring lets you defend where it counts. I'd rather patch three high-exposure, high-exploit systems perfectly than half-patch fifteen boxes and leave gaps.
Run your scoring framework on every CVE alert. Track what you defer and revisit it weekly. When the next wave of vulnerabilities hits—and it will—you'll know exactly where to start.