Prioritising Two Critical Findings with One Sprint of Capacity

Order: B first, then A.

Reasoning, not score:

• CVSS base score measures the severity of an exploit in the abstract; it does not measure whether anyone can reach the target here. A 9.8 behind mutual TLS, reachable only from a hardened jump host, with no public exploit and EPSS 0.018, requires a prior foothold on that jump host or a stolen client certificate. The realistic path is long.
• B is internet-facing, has public exploit code, sits in KEV (exploitation observed in the wild) and has EPSS 0.71. Its attack path needs nothing but a connection to the concentrator. Expected loss is roughly likelihood times impact, and B's likelihood is one to two orders of magnitude higher.
• The 45-minute outage is a scheduling problem, not a risk justification. Book the next approved window; if the COO slips it, apply compensating controls (restrict VPN to posture-checked devices, enforce phishing-resistant MFA, rate-limit and geo-block, virtual patching at the edge) and record the residual risk.
• A is still a genuine finding. Patch it in the next low-risk maintenance window and open a documented, time-bound exception rather than letting it sit silently.

Tell leadership the dashboard ranks by a number that ignores exposure and exploitability, and propose a second view.

The defensible answer is not 'the scanner ranked it first'.

Auditors test two things: was the decision made by someone with authority, and is it documented before or at the breach of SLA.

• Show the decision record: timestamp, asset owner, CISO approval, evidence (EPSS, KEV status, reachability, compensating controls), residual risk rating, expiry date and planned remediation date.
• Distinguish a policy exception (agreed in advance, with controls) from an unapproved overdue finding (a control failure). If policy requires exceptions before day 7 and this reached day 10, concede the process gap and show the fix: automatic escalation at day 5 to the asset owner and security manager.
• Do not ask the auditor to accept that you were busy with B. Show instead that the same two engineers were deliberately allocated to a higher expected-loss item, and that A had compensating controls reducing the interim exposure.

Then fix the metric. An SLA keyed only to CVSS rewards gaming and produces noise across 12,400 findings, most of which no one will ever exploit. Propose tiered SLAs driven by exploitability and reachability: KEV-listed or EPSS above 0.1 plus internet exposure gets 7 days; internal, unpublished exploit gets 90 days with an exception path. Report two numbers: findings past SLA, and exploitable findings unremediated. The second is the one that matters.

Validate before you schedule the outage:

• Read the vendor advisory for pre-authentication versus post-authentication exploitation and the exact affected build. Compare against your deployed version.
• Reproduce in an isolated staging copy of the concentrator, never in production: does the bypass work without valid credentials? If it needs an account, the attacker population shrinks to anyone who can obtain credentials - still serious with 340 users and a public exploit.
• Check external attack-surface scans for other exposed management interfaces on the same appliance (admin UI, client portal) and whether the patch touches them.

Interim detection while the outage waits:

• Authentication logs: successful logins from new ASNs or countries with no staff, logins outside shift patterns, failure bursts followed by success.
• Post-authentication behaviour: new device enrolments, configuration exports, creation of local admin accounts, unusual session lengths.
• Network: flows from the concentrator to unknown external addresses and large outbound transfers.
• A temporary high-priority alert mapped to the published exploitation pattern, reviewed daily rather than left in an unread queue.

Document that detection is not a substitute for patching: it shortens dwell time, it does not reduce the likelihood of entry.