Scoring incoming bug reports with CVSS: severity is not risk

Use CVSS to describe how severe a reported flaw is, label the score by the metric groups you used, and add threat and environment context before deciding priority. FIRST states plainly that the Base score is a measure of severity, not risk, and should not be used alone to assess risk.

What CVSS measures

CVSS is an open framework for describing the characteristics and severity of software vulnerabilities, producing a score from 0 to 10. Version 4.0 has four metric groups:

• Base: intrinsic qualities that do not change over time or across environments.
• Threat: qualities that change over time, such as whether exploitation is known.
• Environmental: qualities specific to your own setup.
• Supplemental: extra context that does not change the final score.

Label the score

FIRST asks that scores be labeled by the groups used to produce them. CVSS-B means Base only. CVSS-BT adds Threat. CVSS-BE adds Environmental. CVSS-BTE uses all three.

If a reporter sends you "9.8" with no label, ask what it covers. A base score from the reporter and your own environmental score can differ a lot, and that is normal.

A practical triage routine

1. Read the report and reproduce it.
2. Score the Base metrics from the flaw itself. Do this without thinking about your own setup.
3. Add Threat context. Is exploitation already seen? Is a public proof of concept available?
4. Add Environmental context. Is the affected component exposed to the internet? Is it behind authentication? Does it hold sensitive data? Do compensating controls exist?
5. Record the full label, for example CVSS-BTE, with the vector string.
6. Decide priority from the combined picture, plus your own policy.

FIRST notes that organisations that automate use of the Threat and Environmental groups can get a CVSS-BTE score much closer to risk. Closer, not equal.

Where teams go wrong

Copying the reporter's number. Reporters see the flaw in isolation. You see your deployment.

Using one number for every decision. A 9.0 on an internal test service can matter less than a 6.0 on your login page. Priority needs exposure and data value.

Hiding the vector. Without the vector string, nobody can check or argue with the score.

Arguing over decimals. The difference between 7.4 and 7.6 should not take a meeting. If you cannot decide between High and Critical, ask what you would do differently, and let the answer settle it.

Writing the decision into your policy

Say in your disclosure policy how you rate reports, for example "we score with CVSS and adjust for our environment". Then give reporters a way to ask for reconsideration with new evidence. This reduces friction and avoids public arguments about severity.

Linking severity to deadlines

Many teams set fix targets by severity band. Keep the bands in your own process, and write them down: for example, critical issues get a hotfix plan within days, high issues go in the next release. The numbers are yours to set. What matters is that they are written, followed and shared with the reporter.

Quick check

Safeguard's reachability analysis is one way to add environment context for dependency flaws, by showing whether vulnerable code paths are actually used.

Sources

• FIRST CVSS v4.0 user guide

Last reviewed: 19 October 2026.