Build a Tiebreaker System for Conflicting Vulnerability Scores

The Problem: Conflicting Vulnerability Scores

Your vulnerability scanner just flagged 847 findings. KEV says 12 are actively exploited. EPSS shows 89 with high exploit probability. CVSS marks 156 as critical. Exactly three appear on all three lists.

You've got four patch windows this month and a team that's already overwhelmed. Which vulnerabilities get fixed first?

The scoring systems don't agree because they measure different things. KEV tracks what attackers are using now. EPSS predicts likely future exploits. CVSS measures technical severity without context. All three matter, but when they conflict, you need a decision rule your team can execute without an emergency meeting.

This isn't theoretical. Internet-exposed systems with active exploitation need remediation within 24 to 72 hours. Miss that window, and you're defending against an attack that's already happening.

What You Need Before Starting

Before building a prioritization system, gather three foundational datasets:

Asset Inventory with Exposure Classification: You can't prioritize what you can't see. Your CMDB or asset management system must tag each asset with its network exposure: internet-facing, internal-only, or air-gapped. If you're using ServiceNow, Qualys, or similar platforms, create a custom field for exposure status and make it mandatory.

Business Criticality Ratings: Work with application owners to classify systems by operational impact. A four-tier model works: Tier 1 stops revenue or creates safety risk, Tier 2 degrades customer experience, Tier 3 affects internal productivity, Tier 4 is everything else. Document this in your asset register.

Compensating Control Registry: Maintain a list of existing protections: network segmentation rules, WAF policies, MFA enforcement, privilege restrictions. Reference this when deciding whether a vulnerability needs immediate patching or can wait because other controls reduce the attack surface.

You also need organizational buy-in. Security and IT leadership must agree that actively exploited internet-facing vulnerabilities interrupt normal patch schedules. Get this approved before you need it.

Step-by-Step Implementation

Step 1: Establish the Decision Hierarchy

Write this down and share it with your team:

1. Active Exploitation (KEV) on Internet-Exposed Assets = Immediate Priority: Remediate within 24 to 72 hours, even if CVSS is moderate.
2. High EPSS (>70%) on Internet-Exposed Assets = Next Tier: Exploit code exists or is likely. Treat these as pre-breach conditions.
3. High CVSS (9.0+) with Compensating Controls = Evaluate Context: A critical vulnerability in an isolated asset behind MFA and network segmentation may rank below a medium-severity issue in an exposed identity system.
4. Everything Else Follows Standard Patch Cycles: Prioritize by CVSS within business criticality tiers.

The key principle: exposure and exploitability outrank theoretical severity.

Step 2: Build the Triage Workflow

Create a decision tree your analysts can follow:

Is the vulnerability on KEV?
├─ Yes: Is the asset internet-exposed?
│  ├─ Yes: Priority 1 - remediate within 24-72 hours
│  └─ No: Is it business-critical (Tier 1)?
│     ├─ Yes: Priority 2 - remediate within 7 days
│     └─ No: Priority 3 - standard patch cycle
└─ No: Check EPSS score
   ├─ EPSS > 70%: Is the asset internet-exposed?
   │  ├─ Yes: Priority 2
   │  └─ No: Priority 3
   └─ EPSS < 70%: Use CVSS + business criticality
      ├─ CVSS 9.0+ on Tier 1: Priority 3
      └─ All others: Priority 4

Document this in your vulnerability management policy. Your ticketing system should auto-assign priority labels based on these rules.

Step 3: Define Emergency Patch Procedures

For Priority 1 vulnerabilities, you need pre-approved authority to act fast. Document:

• Who can authorize emergency maintenance windows (typically IT director or CISO)
• Maximum acceptable testing duration before deployment (consider 4-8 hours for critical systems)
• Rollback procedures if the patch breaks functionality
• Communication templates for stakeholders

When immediate patching isn't possible, define your compensating control playbook:

• Disable the vulnerable feature or service
• Restrict network access via firewall rules
• Implement additional monitoring on the affected system
• Isolate the asset to a quarantine VLAN

Automate what you can. If your vulnerability scanner integrates with your firewall API, create scripts that can block external access to a vulnerable service while you prepare the patch.

Step 4: Integrate with Existing Tools

Map your decision logic into your vulnerability management platform:

In Tenable or Qualys: Create custom dashboards that filter by KEV status, EPSS threshold, and asset exposure tag. Set up automated email alerts for any new KEV entry that matches an internet-exposed asset in your inventory.

In ServiceNow or Jira: Configure workflow automation that sets ticket priority and SLA based on the decision tree. A KEV vulnerability on an internet-facing web server should automatically create a P1 incident assigned to the application team.

In your SIEM: Create correlation rules that flag authentication attempts or unusual traffic to systems with unpatched Priority 1 vulnerabilities. You're looking for signs that exploitation is already underway.

Validation: How to Verify It Works

Test your system before you need it in production:

Scenario Testing: Take the last 90 days of vulnerability scan results and run them through your decision tree. Do the Priority 1 assignments match what actually got patched urgently? If not, refine your criteria.

Tabletop Exercise: Give your team a simulated scenario: "KEV just added CVE-2024-XXXX. We have 23 affected systems. Walk me through the next four hours." Time how long it takes to identify internet-exposed instances, notify application owners, and initiate emergency patching.

Metrics Review: Track these monthly:

• Percentage of Priority 1 vulnerabilities remediated within 72 hours
• Number of vulnerabilities that required compensating controls instead of patches
• False positive rate (vulnerabilities flagged as urgent that turned out to be unexploitable in your environment)

If you're consistently missing the 72-hour target, you either have too many internet-exposed systems or insufficient patch deployment automation. Both are fixable problems.

Maintenance and Ongoing Tasks

Weekly: Review new KEV additions and cross-reference against your asset inventory. CISA updates KEV regularly; automate this check if possible.

Monthly: Audit your asset exposure classifications. Development teams spin up new internet-facing services constantly. If your exposure tags are stale, your prioritization system fails.

Quarterly: Reassess business criticality ratings with application owners. Systems that were Tier 3 last year may be Tier 1 now if the business has changed.

Annually: Review your compensating control registry. That network segmentation you're counting on may have been modified by a firewall rule change six months ago. Validate that controls still exist and function as documented.

The goal isn't perfect scores across all metrics. It's a defensible system that directs limited resources toward the vulnerabilities attackers are most likely to exploit against your most exposed systems. When KEV, EPSS, and CVSS disagree, you need a tiebreaker that doesn't require a committee meeting.