A scanner report lists a finding at CVSS 8.8. The vendor’s own advisory for the same CVE ID lists 5.3. Nothing about the vulnerability changed between the two publications: the code is the same, the exploit path is the same, the affected versions are the same. What changed is who scored it and what assumptions they made while scoring. If your SLA clock starts the moment a finding is ingested, you need a rule for which number starts that clock, not just an intuition that “the higher one is safer.”
Why two authoritative CVSS scores exist for the same CVE
Every CVE record has a primary source: the CVE Numbering Authority (CNA) that assigned the ID. For most vulnerabilities in vendor-maintained software, the CNA is the vendor itself, a coordinating body such as MITRE, or a platform like GitHub Security Advisories. The CNA publishes an initial CVSS vector alongside the advisory, usually written by the people who found or fixed the bug and who understand the exact preconditions for exploitation.
NVD then performs its own independent analysis of the same CVE. Since the CVE record schema moved to v5, this shows up structurally: a CVE JSON record can carry a CNA container and one or more ADP (Authorized Data Publisher) containers, with NVD as one of the publishers. Query the NVD API directly and you will see multiple cvssMetricV31 entries on the same record, each tagged with a source field, one for the CNA’s organization ID and one for nvd@nist.gov. They are not duplicates. They are two separate people reading the same description and reaching different conclusions about attack vector, complexity, privileges required, and scope.
NVD’s own scoring guidance describes its role as estimating the reasonable worst case impact for a given vulnerability description, which is a materially different job than a vendor scoring the specific proof of concept sitting on their desk.
Documented disagreement patterns: narrow impact vs. default configuration
Two recurring patterns explain most of the gap:
- Vendors score what they know. A vendor’s security team has the crash dump, the stack trace, and often a working exploit. If triggering the bug requires a non-default build flag, an already-authenticated session, or a specific plugin that ships disabled, the vendor’s CVSS vector reflects that: higher attack complexity, privileges required set to low or high, scope unchanged. The resulting score is often lower than a generic reading of the advisory text would suggest.
- NVD scores what the description says. NVD analysts work from the published advisory text, not from vendor source code or internal reproduction notes. When a description is ambiguous about preconditions, such as “an attacker can trigger memory corruption via a crafted request,” NVD’s documented practice is to assume the more severe, more broadly reachable interpretation unless the text rules it out. That produces network attack vector, low complexity, and no privileges required by default, which pushes the score up.
There is a third, less discussed pattern worth naming honestly: vendors have a commercial incentive to keep their own CVSS numbers modest, since a self-reported 9.8 reads differently to customers and auditors than a self-reported 5.3 for what is functionally the same bug class. This is not proof of bad faith in any specific case, but it is a reason to treat “the vendor said it’s low severity” as one input rather than a verdict, especially when the vendor is also the one facing the SLA and disclosure pressure.
Case studies: when the gap exceeded three points
Two documented, publicly discussed examples illustrate both directions of the disagreement.
The OpenSSL punycode buffer overflow pair, tracked as two separate CVEs disclosed together in late 2022, is the cleanest example of a score moving after deeper analysis. OpenSSL’s pre-announcement flagged the upcoming fix as addressing a “critical” severity issue, the project’s highest category, based on an initial read of a stack-based buffer overflow reachable during certificate name checking. Once the security team completed platform-by-platform analysis of stack layout and calling conventions, the released severity was downgraded to “high,” because reliable remote code execution turned out to be far harder to achieve on most real-world builds than the initial description implied. Some downstream scanners and news coverage kept citing the pre-announcement “critical” label for days after the actual, lower rating shipped, which produced exactly the kind of stale-severity mismatch this article is about, just with the timeline compressed into a single week instead of split across CNA and NVD.
The curl project is the most publicly documented long-running case of a maintainer disputing NVD’s re-scoring. curl’s own security advisories repeatedly note that NVD’s automated or semi-automated scoring assumed a network-reachable, unauthenticated attack path for issues that, in curl’s actual usage, require a specific redirect chain from a server the client already partially trusts, or a build option that most distributions do not enable. In several of these cases the published gap between curl’s own assessment and NVD’s re-analysis has run well past three points on the ten-point scale, in the direction of NVD scoring higher. curl’s maintainers have argued publicly, and repeatedly, that this overstates real-world risk for the majority of deployments.
Contrast both with Log4Shell (CVE-2021-44228), where the CNA and NVD landed on the same maximum severity within days of each other. Agreement is the norm for vulnerabilities that are unambiguous, unauthenticated, and remotely triggerable with no special configuration. Disagreement clusters around vulnerabilities whose exploitability is conditional, which is precisely the category that is hardest to summarize in a one-line CVE description.
Which source your scanner is actually reporting
Most teams do not know which of the two scores their tooling shows them, because the UI usually just says “CVSS Score” with no source label. A few concrete ways to check:
- Query the CVE directly:
curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2022-3602" | jq '.vulnerabilities[0].cve.metrics'returns every published vector with its source organization ID, so you can see the CNA’s number and NVD’s number side by side. - Check which upstream feed your scanner or SCA tool pulls from. Tools built on OSV (Open Source Vulnerabilities), including Trivy and Grype for open-source ecosystems, often surface the CNA’s or GitHub Security Advisory’s original vector. Tools built primarily on the legacy NVD JSON/CVE feed surface NVD’s re-analysis, sometimes with no CNA number visible at all.
- Watch for the NVD analysis backlog. Since early 2024, NVD has published a large volume of CVEs marked “awaiting analysis” with no NVD-assigned CVSS vector at all, sometimes for months. If your scanner shows a score for one of these, it is almost certainly the CNA’s number by default, not NVD’s, even if the UI labels it generically.
Feeding both vectors into an AI validation pass, such as the triage step in SITEY’s ai-triage module, lets the system flag a source mismatch automatically at ingestion instead of relying on an analyst noticing two conflicting numbers days apart.
A tiebreak policy: default to the higher score, escalate on exploitation evidence
A workable policy needs to be simple enough that an analyst can apply it without a debate every time. The table below is a starting point; adjust the thresholds to your own risk appetite and document the adjustment.
| Condition | Score to use | Required action |
|---|---|---|
| Gap of 1.0 point or less | NVD score (default source of record) | Log both vectors; no manual review needed |
| Gap greater than 1.0, up to 3.0, no known exploitation | Higher of the two | Flag for review within 30 days; downgrade only after documented re-analysis |
| CVE listed in CISA KEV, or EPSS percentile above your organization’s threshold (for example, above 0.10) | Higher of the two, regardless of gap | Treat as critical immediately; notify on-call; do not wait for scheduled review |
| Gap greater than 3.0, vendor score is lower, no exploitation evidence | Higher score, held provisionally | Route to a human reviewer with source access before any downgrade is approved |
The logic behind defaulting to the higher score is asymmetry of cost. Starting remediation on a finding that turns out to be lower severity wastes engineering hours. Under-starting remediation on a finding that turns out to be exploitable in your specific environment costs an incident. Given the choice under uncertainty, the SLA clock should start on the more conservative number, with a documented path to revise it downward once someone with real context has looked at it, not before.
Platforms that automate the triage phase, such as SITEY, can apply this table automatically at ingestion, pulling EPSS and CISA KEV status alongside both CVSS vectors so the escalation branch runs without a human opening three browser tabs to check three separate feeds.
Storing both scores so you can explain a decision months later
The policy only works if the reasoning survives past the moment it was applied. When an auditor, a customer’s security team, or your own future self asks “why was this ticket opened at Critical instead of Medium six months ago,” the answer needs to be retrievable, not reconstructed from memory. At minimum, record on the finding itself:
- The full CVSS vector string from each source, not just the numeric score, so the specific metric that drove the gap (attack complexity, privileges required, scope) is visible later.
- The source organization ID for each vector (CNA identifier vs. nvd@nist.gov).
- EPSS percentile and CISA KEV status at the time of ingestion, since both are revised over time and a later value will not match what actually drove the original decision.
- Which score was chosen, by which rule in the tiebreak table, and who or what applied it.
This record needs to be append-only. If NVD or the vendor revises a score next quarter, add a new entry with a timestamp rather than overwriting the one that justified the original SLA start date. Attaching this history to the finding’s full lifecycle record, such as the one tracked in SITEY’s vulnerability-lifecycle module, keeps the number tied to the finding as it moves through remediation and retest, instead of living only in a ticket comment that gets archived and forgotten.
For teams mapping severity to contractual or regulatory SLA tiers, under PCI DSS, ISO 27001, or a KVKK-driven internal policy, the tiebreak table and its audit trail should sit next to the control mapping itself, inside a module such as compliance-mapping, so an assessor can trace a single finding from its two raw CVSS vectors through the chosen score to the specific control deadline it triggered, without you having to rebuild that chain by hand during the audit window.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.