When you're managing dozens of servers and a new batch of CVEs drops every week, patching everything immediately isn't realistic. You need a system that tells you which vulnerabilities deserve attention today and which can wait until the next maintenance window.
I've spent years triaging vulnerabilities in production environments where downtime costs real money and unpatched holes invite real attackers. The framework below isn't theoretical—it's what I use when a scanner dumps two hundred findings on my desk and I need to tell management which five require weekend work.
The three-axis scoring model
Every CVE gets ranked across three dimensions: how easy it is to exploit, what assets it affects, and whether a patch exists. Score each axis, multiply the results, and you have a priority number that reflects actual risk rather than vendor panic.
Exploitability score (1-5)
This measures how likely an attacker is to successfully use the vulnerability. A remote code execution bug with a public Metasploit module scores higher than a privilege escalation that requires local shell access and specific timing conditions.
Here's how I assign points:
- 5 points: Exploit code is public and weaponized. One-click remote code execution. No authentication required.
- 4 points: Exploit code exists but needs modification. Authentication required but default credentials are common.
- 3 points: Proof-of-concept available. Requires authenticated access or user interaction.
- 2 points: No public exploit. Requires complex pre-conditions or local access.
- 1 point: Theoretical vulnerability. No known exploitation path.
When CVSS scores and exploitability diverge, trust exploitability. A CVSS 9.8 that nobody can reliably trigger matters less than a CVSS 7.2 with a working one-liner.
Asset exposure score (1-5)
Not all servers are equal. A vulnerability in your public-facing web server cluster deserves more urgency than the same bug in an internal dev box that talks to nothing.
Score based on what's at risk:
- 5 points: Internet-facing production systems handling customer data or payment processing. Database servers with PII.
- 4 points: Internal production systems with access to sensitive data. Systems that can pivot to score-5 assets.
- 3 points: Production systems with limited data access. Internal tools used by multiple teams.
- 2 points: Development or staging environments. Internal tools with restricted access.
- 1 point: Isolated test systems. Decommissioned servers still running.
Map your infrastructure before the next CVE lands. You should already know which boxes are score-5 targets.
Patch availability score (1-5)
A vulnerability with a vendor patch you can apply in ten minutes is different from one requiring you to compile a custom kernel or migrate to a new major version.
The scoring:
- 5 points: Official patch available through standard package manager. Minimal service disruption.
- 4 points: Patch available but requires service restart or brief downtime.
- 3 points: Workaround or configuration change available. Patch expected soon.
- 2 points: No official patch. Mitigation requires significant changes (firewall rules, disabling features).
- 1 point: No patch, no workaround. Vendor silence or end-of-life software.
Counter-intuitively, score-1 situations sometimes deserve immediate action—if you can't patch and the exploitability is high, you might need to take the service offline until a fix arrives.
Calculating final priority
Multiply the three scores: Exploitability × Exposure × Patch Availability = Priority Number.
A maximum score of 125 (5×5×5) means an internet-facing system with a weaponized exploit and an easy patch. That gets fixed today. A score of 30 or below can usually wait for your regular maintenance cycle.
Here's how I bucket the results:
- 100-125: Emergency. Patch immediately, even if it means unplanned downtime.
- 60-99: High priority. Patch within 24-48 hours during next change window.
- 30-59: Medium. Schedule for next weekly maintenance.
- 15-29: Low. Include in monthly patching cycle.
- 1-14: Monitor. May not require action if compensating controls exist.
The math forces honest conversations. When someone insists their development server needs an emergency Saturday patch, the scoring shows it's a 2×2×5—only 20 points.
Building your asset inventory
The framework falls apart without accurate asset data. You need to know what's running where before you can score exposure.
Start with a simple spreadsheet:
Hostname | IP | Services | Internet-facing | Data classification | Owner
web-01 | 10.0.1.5 | nginx, php-fpm | Yes | Customer data | Platform team
db-prod | 10.0.2.10 | PostgreSQL | No | PII, payment | Data team
dev-api | 10.0.3.15 | Node.js | No | Test data | Dev team
Update it when you provision or decommission systems. The five minutes you spend maintaining this list saves hours during the next zero-day panic.
For larger environments, configuration management tools or asset discovery scanners can populate this automatically. Just make sure the data stays current—an outdated inventory is worse than none because it gives false confidence.
Tracking exploitability intel
Public exploit availability changes fast. A CVE with no exploit on Monday might have three GitHub repos by Friday.
I check these sources when scoring:
- Exploit-DB and GitHub: Search for the CVE number. If working code exists, exploitability jumps to 4 or 5.
- Metasploit modules: Indicates reliability and ease of use.
- CISA KEV catalog: Known Exploited Vulnerabilities list means active exploitation in the wild.
- Vendor bulletins: Sometimes they'll quietly mention "exploits observed" without public details.
Set up alerts for CVEs affecting your key software stacks. When a new Apache or OpenSSH vulnerability drops, you want to know within hours, not days.
What if the score says "low" but your gut says "urgent"?
Trust the framework, but understand its limits. The scoring assumes rational attackers targeting valuable data.
Some situations override the numbers:
- Compliance requirements: Your auditor might demand immediate patching regardless of technical risk.
- Targeted threats: If you're in an industry that nation-state actors care about, a score-2 exploitability might still matter.
- Chained exploits: Two medium-risk bugs that chain together can create high risk.
- Reputational damage: A breach on a public-facing blog might not leak PII but could cost customer trust.
Document when you override the framework and why. Pattern analysis over six months will show whether your gut is calibrated or paranoid.
Patch testing before deployment
High-priority scores mean fast patching, not reckless patching. Even emergency fixes get a sanity check.
Minimal safe testing:
- Apply patch to one non-production system that mirrors production config
- Run automated tests if available
- Verify the service starts and handles basic requests
- Check logs for new errors
For score-100+ emergencies, this might take thirty minutes. For score-60 patches, spend a few hours testing edge cases.
Keep a rollback plan. Before patching production databases or web servers, verify you can restore from backup or revert to the previous package version.
Communicating risk to non-technical stakeholders
Management doesn't care about CVSS scores. They care about business impact.
Translate your priority numbers:
- Score 100+: "This vulnerability lets attackers access customer data remotely. Exploit code is public. We need a two-hour maintenance window today."
- Score 60-99: "Authentication can be bypassed on our payment gateway. Patch is available. Scheduling for tonight's change window."
- Score 30-59: "Local privilege escalation on internal dev servers. Including in this weekend's maintenance."
Include what you checked, not just the conclusion. "I verified the vulnerability affects our Apache version and confirmed working exploit code on GitHub" sounds more credible than "this is critical."
Start with your top-10 assets
You don't need to score every server on day one. Identify the ten systems that would hurt most if compromised—usually your internet-facing production boxes and your databases.
Score only CVEs affecting those systems for the first month. Once the workflow feels natural, expand to the next tier. The framework scales from ten servers to ten thousand, but you'll learn faster by starting narrow.
Print the three-axis scoring guide and tape it next to your monitor. When the next critical CVE alert arrives and everyone's shouting about CVSS 10.0, you'll have a rational way to decide whether it's a drop-everything emergency or a next-week task.