CVSS

FIRST defines the bands: 9.0 and above is critical, 7.0 to 8.9 is high, 4.0 to 6.9 medium, 0.1 to 3.9 low.

A good score is not a thing, though. The number describes the flaw, and the question you actually have is what that flaw reaches inside your product.

Because scoring involves judgement calls about attack complexity, privileges required and impact, and reasonable people disagree. A vendor scoring its own product often reads those questions more narrowly than the researcher who found it.

Treat any score as a position somebody argued for, and read the vector string if the difference matters to you.

It is a defensible rule and a poor policy on its own. It fixes dormant features while leaving a medium on the endpoint that serves every customer.

Add two filters before the score: is it reachable in your deployment, and does it touch data or money. What survives all three is your queue.

No, and FIRST says so in the user guide. The base score measures intrinsic severity, assuming the worst reasonable case.

Risk needs your context: exposure, exploitation activity, what the asset is worth, what else would have to fail. That is why the standard includes environmental metrics you are meant to set yourself.

It complements it. CVSS asks how bad this would be. Exploitation data asks how likely anybody is to try.

Teams that combine the two ship better queues than teams that sort on severity alone, which is the main criticism levelled at score-only prioritisation.