Rescore a CVE for your product only when your product changes the exploitability or impact in a way you can explain. If the vulnerable code is absent or unreachable, a VEX not affected statement is clearer than a lower number. Always label which score is the upstream Base score and which is yours.
Definitions
CVSS, the Common Vulnerability Scoring System, rates vulnerabilities. Version 4.0 has four metric groups. Base covers intrinsic characteristics. Threat covers exploit maturity, which changes over time. Environmental covers a consumer's own setting, such as controls and asset importance. Supplemental adds context such as safety and provider urgency, and does not change the numerical score.
What the specification says
The CVSS 4.0 specification says Base metrics are typically supplied by bulletin analysts or product vendors, who have the best information about the vulnerability. Threat and Environmental metrics are best assessed by consumer organisations. It also says scores should be labelled by the groups used, such as CVSS-B or CVSS-BTE, and notes that NVD and similar sources typically publish only CVSS-B scores. It advises consumers to enrich Base scores with Threat and Environmental values, and to treat CVSS as one input among others, such as regulatory requirements and business impact.
Decision guide
| Situation | Better tool |
|---|---|
| Component absent from your product | VEX not affected, component not present |
| Present but the vulnerable function is never called | VEX not affected, with the justification and evidence |
| Present and reachable, but your product blocks the attack input | VEX with inline mitigations, or a rescored Environmental view with notes |
| Present and reachable, and your product exposes it more than usual | Keep the Base score, add context, and consider raising urgency |
| Customer asks for a number to put in their risk register | Provide CVSS-B and describe what would change it |
Steps
- Record the upstream Base score and its source.
- Decide whether your product changes the attack vector, privileges or impact. If not, do not rescore.
- If it does, document the change in plain words, with the metric names.
- Record the rescored value as a separate, labelled score.
- Cross check against whether the flaw is known to be exploited.
- Have a second person review before it goes into a bulletin.
Why labels matter
If a customer sees "7.5" in a bulletin and "9.8" in their scanner, they assume an error. A label such as "vendor assessed, Environmental" explains it. Unlabelled downgrades read as marketing, even when they are accurate.
Try it yourself
Click through it at your own pace, or open it full screen. Look at the difference between a severity score and an exploitability answer.
Quick check
Is a lower vendor score the same as not affected?
No. A lower score still says the product is affected. Not affected is a statement that the vulnerability cannot be exploited in the product.
Can customers ignore our rescore?
Yes, and they may rescore for their own environment. Give them the reasoning so they can.
Safeguard's reachability analysis can help show whether a vulnerable function is called, which is evidence for a not affected claim. A free scan is available.
Sources
Last reviewed: 19 October 2026.