CVSS measures how severe a flaw is in the abstract. Risk also depends on exploitation and on your environment, which a model cannot see unless you tell it. So an LLM-produced CVSS number is a rough guess at the base score, and it should never stand in for a risk decision.
What FIRST says CVSS is for
The CVSS v4.0 user guide states that Base scores measure severity and "should not be used alone to assess risk". The groups are separate on purpose:
- Base: intrinsic qualities that stay constant over time and across environments.
- Threat: characteristics that change over time, such as known exploitation.
- Environmental: characteristics unique to your environment, including the confidentiality, integrity and availability requirements.
The guide also says applying Threat and Environmental metrics is the responsibility of the CVSS consumer, meaning you. Providers and the NVD typically publish only Base scores, labelled CVSS-B.
Where an LLM goes wrong
Ask a model "what is the CVSS of this CVE" and three things can happen.
- It recalls a published score correctly. Useful, but it is a lookup you could do directly.
- It recalls an old or different score, or one for another CVE, and states it flatly.
- It invents a vector string that looks plausible.
In none of these cases did it learn your environmental facts. It does not know that the affected service sits behind a gateway, handles no sensitive data, or is internet-facing and holds customer records.
A division of labour that works
| Input | Who provides it |
|---|---|
| Base score and vector | The published record, copied and checked |
| Known exploitation | A live source, dated |
| Asset exposure and data sensitivity | Your inventory and owners |
| Whether vulnerable code is reachable | Analysis of your code |
| Wording of the ticket and the explanation | The model, from the facts above |
Notice that the model's job is the last row. It is good at turning structured facts into a clear paragraph for an engineer.
How to test any tool that gives severity
Take ten findings you have already triaged by hand. Run them through the tool or prompt. Compare not only the final label but the stated reasons. If the reasons mention facts about your system that you never supplied, the output is invented context. Record disagreements and who was right.
For a fuller method see does AI severity match CVSS, how to test.
Writing the rule down
A short internal rule helps: "Severity labels come from the published record. Priority comes from severity plus exploitation plus our exposure. An AI assistant may draft the explanation but may not set the priority." Put an owner's name next to final priority decisions so the record shows a person made them.
Where Safeguard fits
Safeguard combines dependency scanning with reachability analysis and policy gates, so priority can be tied to whether the vulnerable code path is actually used in your software, with your own rules deciding what blocks a build. Try a free scan at https://gold.safeguard.sh/scan.
Quick check
Can an LLM calculate a CVSS vector from a description?
It can propose one, and that can help a reviewer start. Treat it as a draft and verify each metric against the advisory and the specification.
Who should set the Environmental metrics?
The team that owns the affected system, because they know its exposure and data. FIRST says this is the CVSS consumer's responsibility.
Sources
- FIRST, CVSS v4.0 User Guide: https://www.first.org/cvss/v4-0/user-guide
- CISA, Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
Last reviewed: 19 October 2026.
