CVSS 9.8 Internally Versus CVSS 7.5 on the Internet

Remediate B first, and say so plainly: CVSS is a severity score for the flaw, not a risk score for this organisation.

Factors used:

• Exposure: B is reachable by anyone on the internet; A only by the development subnet. Exposure multiplies likelihood more than any base metric.
• Threat activity: B is on the Known Exploited Vulnerabilities catalog, meaning exploitation is observed in the wild, not theoretical. A is a research-grade flaw on an isolated host.
• Asset role and population: B is the entry point for 200 daily users and is itself a gateway into the network; A has no production credentials and no egress, so a compromise yields little and cannot easily call home.
• Compensating controls already present: A's network position is effectively a control.
• Attack complexity in practice: compare EPSS or exploit availability, not just the base vector.

Note the shape of the argument for the board: a 7.5 with active exploitation against a 9.8 with no path to it is not a close call. Patch B inside the window and treat A as a tracked exception with the dev team's date, not as a silent deferral. Also flag that the 14-day policy is written around a score rather than around exposure, and should be rewritten.

A deferral is a decision, not an omission, and it needs an owner.

• Who decides: the business owner of the application, countersigned by the CISO. IT does not accept risk on the business's behalf, and the CISO does not accept it alone.
• What is documented: finding ID, CVE, affected asset, the technical reason patching is blocked, the compensating controls in place, the residual risk in plain language, an expiry date aligned to the release (not open-ended), and the review date. Add the monitoring plan so you will know if the assumption changes.

Compensating controls to require while deferred:

• Restrict inbound access to the development subnet to named jump hosts, and confirm the no-egress rule is enforced at the firewall, not just assumed.
• Remove or rotate any credentials and tokens present on the host; confirm the 'no production credentials' claim rather than trusting it.
• Add an IDS or EDR detection for deserialization exploitation attempts against that service, with an owner who reads the alert.
• Virtual patching at the WAF if the service is proxied; otherwise a network-level deny from the production subnets.
• Re-scan the host the day after patching to confirm the finding closes; a deferral that never gets verified becomes permanent.

Distinguish a policy exception (this rule does not fit) from risk acceptance (we know and accept it). Most of these are the latter.

'9 criticals' is a poor board metric because:

• It is not comparable over time - scan coverage, plugin updates and asset counts change, so the number moves for reasons that have nothing to do with security.
• It ignores exposure and asset value, which is precisely what drives real risk, as items A and B demonstrate.
• It incentivises the wrong behaviour: teams learn to dispute scores, split tickets, or stop scanning rather than fix things.
• It says nothing about whether the worst findings were dealt with inside the agreed time.

Two better metrics:

1. Percentage of internet-facing assets with a known-exploited vulnerability, and the count of KEV findings open past target. This is small, board-legible, and directly tracks the thing that causes incidents.
2. Median days to remediate for internet-facing critical and high findings, with a target line. It measures the organisation's ability to respond rather than its inventory of problems.

Add a supporting health pair: scan coverage as a percentage of known assets, and number of open risk acceptances past their expiry date - the second one usually reveals the real governance gap and is a single number the board can act on.