Risk Rating and Prioritization

A CVSS score describes technical severity, not what the business loses. Lead each threat with a scenario: who does what, to whose money or data, and what it costs. Use the score only to rank items against each other.

A bug bar is a written table, agreed before any finding exists, that defines each severity band by the concrete kinds of flaw that belong in it, the deadline to fix each band, and which bands block shipping.

A CVSS v3.1 base vector: network-reachable with low complexity, needing no privileges and no user interaction, escaping its own security scope to fully compromise confidentiality and integrity in the component it reaches, with no availability impact.

Rate likelihood from what the abuse requires, not from how clever it is: who already holds the access, how much effort and skill it takes, and whether anyone would notice. Every picker already has the scanner, so likelihood is high.

Risk-matrix band numbers are ordinal ranks, not measured quantities: they say one band is worse than the next, not how much worse. Multiplying ranks yields a score with no consistent meaning, so the ordering it produces is arbitrary.

They break the tie on likelihood, which severity never measured. A finding in the top EPSS percentile and on a confirmed-exploitation list is being attacked now; an identical 7.5 in neither is a hypothesis. Same impact, very different urgency.

A CVSS base score rates the flaw itself under reasonable worst-case assumptions. It ignores where your instance actually sits, how much the affected asset matters to your business, what controls already stand in the way, and how likely exploitation is.

Mitigate: add a control that cuts likelihood or impact. Avoid: redesign so the threat cannot exist. Transfer: move the financial consequence to another party by contract or insurance. Accept: knowingly carry the residual risk, with an owner and an expiry.

A defensible acceptance names the accountable owner, states the residual risk as a concrete outcome, records the evidence and compensating controls behind the call, gives the reason it was taken, and carries a hard expiry that forces a fresh decision.

A severity score says how bad a threat is - not what the fix costs, how many other threats it clears, or what must be right before a fixed launch date. Sorting by score alone gives an indefensible order of work.

Discoverability lowers a threat's score because the flaw is hard to find, crediting obscurity as if it were a control. The vulnerability is unchanged; only attacker knowledge is, and that can shift overnight.

Rating the whole set in one pass keeps every threat on the same scale. Rated piecemeal over weeks, the bar drifts: what the group called High early becomes Medium later, so the resulting order is not comparable.

State the threat and the actor plainly, then be exact about what logging changes: it makes an unauthorised look detectable and attributable, not impossible. Price the redesign you decline, and let the privacy officer decide, with a review date.

Band the threat on the worst credible consequence if it is real, using the bar's flaw-class rows. Absence of a working exploit is not evidence of low severity; genuine doubt about whether the flaw exists becomes a time-boxed verification task, not a downgrade.

Scope:Changed in CVSS v3.1 means the exploit crosses out of the vulnerable component's own security authority and impacts resources governed by a different one — a hypervisor escape reaching co-tenant VMs, for example. It raises the score, never lowers it.

Averaging five ordinal guesses destroys a threat's shape: a trivial issue touching everyone lands on the same digit as a moderate-everywhere one. The ratings are also unanchored, so a later session produces different digits from identical facts.

Rate the worst credible loss this one threat delivers, not the worst story you can tell. Name what is reached, cap it at what the attacker's position gives them, then translate that into business and regulatory harm.

Replace adjective labels like Major with concrete, observable outcomes in the product's own vocabulary — for a photo-sharing service, Impact 4 means any cross-account read of another user's private media. Write the anchors before the rating argument, then calibrate them on past threats.

Almost certainly the 6.5. Rescore both with environmental metrics: the admin console flaw needs an attacker already inside the private network, while the payments path has high confidentiality, integrity and availability requirements, which lifts its score.

Bring priced options, not a demand: for each threat, a full fix, a partial mitigation, detection only, or a temporary control for the event. Then state what the deferred one costs, over what window, and get it owned and dated.

Reject the framing that one rating decides both. Ship the cheap fix for the likely bounded threat this sprint, and treat the catastrophic one as an architecture decision with a named owner, a date and a written acceptance.

Compare the control's full cost — build, operation and the user friction it adds — against the measured loss it prevents over a stated window, and record the assumptions. Tail risks and legal floors are not settled by that comparison.

OWASP Risk Rating splits likelihood into four threat-agent factors and four vulnerability factors, and impact into four technical and four business factors. Each is scored 0 to 9 and averaged within its group, then read as low, medium or high.

Re-rate the whole cluster the control touches, not just the row it targeted, and rate the new threats the control itself introduces. A mitigation usually lowers likelihood while leaving impact intact, so bands move, new rows appear, and the queue re-sorts.

Agree the bands, clocks and gate before any finding exists, keep the gating set small enough that a block is believable, route acceptance to an accountable business owner rather than the security engineer, and change the bar only in scheduled reviews, never mid-argument.

CVSS v4.0 splits scoring into Base, Threat, Environmental and Supplemental groups, drops Scope for explicit subsequent-system impact, and adds non-scoring context such as Safety and Automatable. Migrating pays where those distinctions change decisions, not as a bulk re-score.

Keep the five prompts, throw away the arithmetic. Asking about damage, repeatability, effort, blast radius and visibility structures a short discussion well; computing and publishing a mean gives a number nobody can reconstruct or defend later.

A matrix that rates most threats alike has stopped discriminating, so it cannot sequence work. Diagnose why first — vague bands, raters avoiding the extremes, or a colour region drawn across too many cells — then re-cut the bands against the real portfolio.

Only when the control provably blocks the attack path, and only through environmental metrics, leaving the base score untouched. The lowered number then depends on that control existing, so record it as a precondition with a rescore trigger.