18.4 Prioritizing Fixes Based on Exposure and Impact
Severity Alone Ignores Your Network
A base CVSS score is deliberately deployment-agnostic: it describes the flaw, not your estate, which is why teams drown in hundreds of Critical findings they cannot fix this month. Three adjustments restore reality. The Environmental group re-weights the score for asset value and controls already present. Exploitability evidence tells you whether attackers are already trying: a published proof of concept, a functional exploitation module, and inclusion in the CISA Known Exploited Vulnerabilities catalogue are progressively stronger signals, with KEV acting as a "someone is using this today" flag. Probabilistic likelihood scores estimate the odds of exploitation in the next thirty days, useful for ranking the large grey mass of Medium findings.
Exposure Questions That Reorder the Queue
Before scheduling, ask what an attacker must already possess. Is the service reachable from the internet, or only from an internal segment behind multi-factor access? Is exploitation unauthenticated remote code execution in the default configuration, or does it require local administrator rights? Is the product still supported, since an end-of-life system never gets a fix at all? Is the vulnerable code path compiled in, enabled by a feature flag, or a vendored library nothing calls? Client-side flaws need user interaction, so their risk follows browsing and mail habits. Then measure blast radius: a defect in a shared compression, TLS, or image-parsing library replicates across every host that loads it.
Compensating Controls Buy Time, Not Closure
When patching today is impossible -- vendor build absent, validated controller, change freeze -- reduce exposure instead. Unpublish the service, close the listening port, or move it behind a VPN or zero-trust gateway. Segment the affected systems into a restricted VLAN with outbound limits. Disable the vulnerable module, protocol, or feature. Front the service with a web application or intrusion prevention signature, understood as virtual patching that slows automation while you plan. Ensure endpoint detection actually blocks the exploitation technique, and tighten the accounts that can reach the host. Each control needs an accountable owner, documented risk acceptance, and an expiry date; compensating controls are bypassable, and an undated exception quietly becomes permanent risk.
Service Levels and Work-to-Completion
Convert priority into clocks. A common tiering: internet-facing Critical or KEV-listed within 24 to 72 hours, internal Critical within 7 days, High within 30, Medium within 90, Low accepted and reviewed quarterly. Track mean time to remediate per tier and per owner, and publish an aging report for findings already past their window -- aging, not raw counts, is what managers should see. Group work by component so one library CVE becomes one patch campaign with an asset list rather than two hundred tickets, and close the loop with rescan or agent evidence proving the fixed version is installed, linking the vulnerability ticket to the change record that delivered it.
Architecture Diagram
Key Takeaways
- Base CVSS ranks impact in the abstract; environmental re-weighting plus exploit evidence ranks your queue.
- KEV listing, public exploit code, and observed probing are the strongest urgency signals available.
- Ask exposure first: internet reachable, unauthenticated, default config, supported product, vulnerable path actually enabled.
- Compensating controls reduce exposure when patching waits, but need an owner, risk acceptance, and an expiry date.
- Priority is a clock: tiered remediation SLAs, aging reports, grouped campaigns, and rescan evidence to close tickets.