Not reliably. An AI assistant may assign severity from its own judgement, which can differ from a CVSS score computed by the published method. Test it: give the tool 20 findings with known CVSS scores, compare bands, and decide whether its labels are usable for prioritising.
What CVSS gives you
The Common Vulnerability Scoring System produces a number from 0 to 10. In version 4.0, the specification defines four metric groups: Base, Threat, Environmental and Supplemental. Base covers intrinsic characteristics, Threat covers factors that change over time such as exploit maturity, Environmental covers your own setting, and Supplemental adds context without changing the score.
The qualitative bands are:
| Band | Score |
|---|---|
| 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 |
The same document describes the Base score as the severity of a vulnerability by its intrinsic characteristics, and says users should add Threat and Environmental values for a more comprehensive input to risk assessment. Things like regulatory requirements and customer impact fall outside CVSS entirely. So even a correct score is severity, not risk.
Why an AI label may differ
- The model may judge from a short description, not the vector.
- It may blend severity with how likely it thinks exploitation is, which is closer to risk but not the same measure.
- It may label by the weakness class (injection sounds critical) rather than by the context.
- It may be inconsistent: the same finding gets different labels on different runs.
None of this makes the AI label useless. It means you must know what it represents.
The test
- Pick 20 findings from a source with published CVSS vectors, spread across bands.
- Hide the score. Give the assistant the finding description, affected component and context you would normally supply.
- Ask it for a severity label and the reasoning. Repeat three times.
- Compare with the published band. Count exact matches, one band off, and two or more bands off.
- Check consistency across the three runs.
Pay most attention to critical and high items it rates low, since those are dangerous misses, and to low items rated critical, since they waste urgent attention.
Decide how to use it
| Result | Use |
|---|---|
| Matches bands, stable | Can help pre-sort, still confirm against the record |
| Close but unstable | Use as a hint alongside the published score |
| Often wrong | Do not use its label for priority, use it only to explain |
Better prioritisation inputs
Rather than asking the assistant to guess severity, supply the facts that move it: the published score, whether an exploit is known, whether the vulnerable code is reachable in your service, and how exposed the service is. Then ask it to explain how those facts affect your priority. The decision stays with your policy.
For the verification habit behind this, see checking CVE and CWE references an AI assistant gives.
Try it yourself
Open the demo and see how exploitability facts change which finding matters most, beyond a headline score.
Click through it at your own pace, or open it full screen.
Quick check
Is a CVSS Critical always the first thing to fix?
Not always. The Base score is severity, so check exploit activity, reachability and exposure before ordering the work.
Should I let the assistant set ticket priority?
Only after testing it against published scores, and with a person confirming. Better to give it the facts and keep priority rules in your policy.
Safeguard includes reachability analysis and vulnerability management, so priority can reflect whether code is reachable. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
