CVSS (common vulnerability scoring system)
The 0-to-10 number attached to a vulnerability, describing its technical severity but not how dangerous it is to your exact system.
See it
What it is
CVSS turns the technical traits of a vulnerability into a score from 0.0 to 10.0 and a compact vector string. The vector records facts such as whether exploitation needs network access, user interaction, or existing privileges, and what happens to confidentiality, integrity, and availability. Versions matter: a CVSS 3.1 vector and a CVSS 4.0 vector use different metrics and must not be mixed.
Use the published vector to sort an advisory queue and to see why two findings received different technical severity. When you score your own finding, publish the vector as well as the number so another person can check every choice instead of trusting an unexplained 9.8. Log4Shell sits at the ceiling, a straight 10.0, which is roughly once-a-decade territory.
Severity is not business risk. CVSS does not know that the vulnerable service is unreachable, the affected feature is disabled, or the exposed records are your crown jewels. Combine the score with reachability, active exploitation, asset value, and blast radius before deciding what gets patched first.
Ask AI for it
Assess [VULNERABILITY] with the FIRST CVSS v4.0 specification. Verify the attack path and impact from evidence, choose every Base metric explicitly, and output the full vector string beside the calculated 0.0-to-10.0 score and severity band. Explain each metric in one sentence, mark facts that remain unknown, and do not infer them from the vulnerability title. Then produce a separate environment-specific priority using reachability, internet exposure, active exploitation, data sensitivity, and blast radius, so the CVSS severity and our actual remediation order are not collapsed into one number.