The letters after CVSS tell you which metric groups produced the number. CVSS-B uses Base metrics only, CVSS-BT adds Threat, CVSS-BE adds Environmental, and CVSS-BTE uses all three. Most public advisories and databases publish CVSS-B, so the number you see usually says nothing about exploitation or your own environment.
What each label means
The CVSS v4.0 specification asks that every numerical score be labeled with the metric groups used to calculate it. Four labels exist:
- CVSS-B: Base metrics only.
- CVSS-BT: Base and Threat metrics.
- CVSS-BE: Base and Environmental metrics.
- CVSS-BTE: Base, Threat and Environmental metrics.
The specification says the label should appear wherever a numerical value is displayed or communicated. If you see a bare "9.3" with no label, you do not know which of these it is.
Who supplies which part
Base metrics describe the intrinsic qualities of the flaw. They are normally assigned by the vendor, the maintainer or a bulletin analyst, because those parties know the flaw best.
Threat and Environmental metrics are the job of the consumer. The specification says plainly that product maintainers and public entities such as the National Vulnerability Database typically provide only the Base score, written CVSS-B. Whether a working exploit exists, and how critical the affected system is to you, are facts only you or your threat feed can supply.
Defaults are not neutral
In v4.0 all three groups are always part of the calculation. If you leave Threat and Environmental metrics unset, they take the value Not Defined, and a complete score still comes out.
For the Exploit Maturity metric, Not Defined is treated like Attacked for scoring. That is the worst case. So a CVSS-B score already assumes the vulnerability is being exploited. Adding real threat data can only keep the score or lower it. The FAQ explains why: vendors score for a reasonable worst case, and consumers apply what they actually know.
CVSS-B is severity, not risk
The CVSS v4.0 user guide states that the Base score measures severity and should not be used alone to assess risk. It adds that an organization that applies Threat and Environmental metrics by automation gets a CVSS-BTE score that is much closer to risk.
That gives you a practical reading rule:
- Find the label. No label means treat it as CVSS-B.
- Ask where Threat data came from and how recent it is.
- Ask whether anyone adjusted for your asset and its controls.
- If the answers are "nowhere" and "no", use the score only to sort, not to set a deadline.
Putting it into a workflow
A simple pattern works for most teams. Keep the vendor CVSS-B as the stored baseline. Record exploitation status from a separate source and refresh it daily. Record asset importance once, in your inventory, and reuse it. Then compute or reason about the adjusted view from those three inputs, and keep the labels visible in reports so nobody mistakes one for another.
Safeguard shows severity next to reachability and fix availability, so a base score is one input and not the whole answer. A free dependency scan is available at gold.safeguard.sh/scan.
Quick check
If an advisory shows only "CVSS 8.7", which label is it likely to be?
Most likely CVSS-B, because vendors and public databases usually publish Base scores only. Check the vector string and the source to be sure.
Can adding threat intelligence raise a CVSS-B score?
No. Not Defined already assumes the worst case for Exploit Maturity, so threat data can only hold the score or lower it.
Sources
Last reviewed: 19 October 2026.
