As the product owner you usually assign the CVSS base score. Work through each base metric from your validated reproduction, not from the reporter's worst case, publish the score together with its vector string, and treat the number as technical severity, not business risk. Let customers adjust for their own environment.
Who scores what
The CVSS v3.1 specification from FIRST splits scoring into three groups. Base metrics describe qualities of the vulnerability that stay constant over time and across environments, and produce a score from 0.0 to 10.0. Temporal metrics cover things that change, such as exploit code maturity and fix availability. Environmental metrics reflect a particular organisation's controls and the importance of the affected system.
The specification says base and temporal metrics are generally assigned by analysts, security vendors or application vendors, since they usually have the most accurate information. Environmental metrics belong to the end user organisation. Anyone publishing a score must include the vector string so others can see how it was derived.
The rating scale
| Rating | Score range |
|---|---|
| None | 0.0 |
| Low | 0.1 to 3.9 |
| Medium | 4.0 to 6.9 |
| High | 7.0 to 8.9 |
| Critical | 9.0 to 10.0 |
Steps for a small team
- Finish validation first. Score what you reproduced.
- Write down the attack path in one sentence: who does what, from where.
- Set each base metric from that sentence. Ask: does the attacker need network access, privileges, or a user to click something?
- Decide the impact on confidentiality, integrity and availability separately, based on what you observed.
- Have a second person score it independently, then compare. Differences point to unclear assumptions.
- Record the vector string, not only the number.
- Share the score with the reporter and note where you differ from theirs, with reasons.
Where teams go wrong
- Scoring the scariest chain instead of the single flaw.
- Treating a default configuration the same as a hardened one without saying which you scored.
- Marking user interaction as none because the user is "probably" going to click.
- Copying the score of a similar flaw without re-reading the metrics.
What CVSS does not tell you
The specification states that CVSS measures technical severity and that organisations may combine it with factors outside its scope, such as customer counts or monetary losses, when ranking threats. For your own queue that means a medium issue in your login flow may still go before a high issue in a feature almost nobody uses. Write that reasoning in the ticket.
Try it yourself
Open the vulnerability management demo and compare severity with the other signals it shows beside each item. Notice how a score alone does not decide order.
Click through it at your own pace, or open it full screen.
Quick check
What if the reporter's score is higher than ours?
Explain your metric choices in writing and invite them to point out an assumption you missed. Both scores can be mentioned, but publish the one you can defend with a vector.
Do we have to use CVSS?
No. It is common, and tools expect it, but you can add a plain statement of impact. If you use it, publish the vector string.
For dependency issues, Safeguard adds reachability analysis so you can see whether a flaw is exercised by your code before you rank it. The free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
