NVD vs Vendor Advisory Differences

Use NVD for broad indexing and vendor advisories for product-specific action.

Use this guide when NVD, vendor, distro, scanner, CNA, cloud provider, or asset-owner evidence disagrees about affected versions, severity, exploitability, fixes, or priority.

Difference rule: source disagreement is normal. NVD, vendor, distro, CNA, scanner, and cloud sources serve different jobs. Do not treat one field as final proof of local exposure, exploitability, patch status, or business impact without product-owner and environment evidence.

NVDbroad index

CVE ID, description, CWE, CVSS, references, and CPE-style product mapping.

Vendorproduct truth

Affected ranges, fixed versions, workaround limits, prerequisites, and support status.

Distro/cloudpackaged context

Backports, managed-service responsibility, package naming, and tenant or customer action.

Local proofdecision point

Installed version, feature state, exposure, telemetry, and owner signoff.

Each source answers a different question.

Open Source Confidence

NVD record

Broad catalog entry for indexing and cross-reference. It may lag vendor updates, use noisy CPE mapping, or carry a CVSS score that differs from product-specific guidance.

Vendor advisory

Usually strongest for product branch, affected range, fixed version, workaround, and required action. It may omit broad CPE details and change often during investigation.

CNA record

May be closest to the assigning authority and earliest public structure, but it can be sparse, vendor-shaped, or less operational than a later advisory.

Distro notice

Explains package and backport context. An upstream version can look vulnerable while the distribution package is fixed through a patched backport.

Scanner finding

Useful environment clue, not final source truth. Validate version, signature, plugin logic, backport status, feature state, and product owner evidence.

Cloud or SaaS notice

Shared responsibility matters. Separate provider-side remediation from tenant settings, integration changes, logging, and customer action.

Common conflicts and the safer reading.

CVSS differs

Compare vector assumptions and keep priority separate from severity. Exposure, exploitation, asset criticality, and fix availability decide action.

Affected versions differ

Prefer vendor or distro product context, then validate local version, branch, platform, package, feature, and deployment mode.

Fixed version unclear

Do not close because a patch exists somewhere. Confirm the safe target, supersedence, support branch, workaround limits, and owner change proof.

NVD says affected, vendor says not affected

Treat this as mapping disagreement until product and version evidence proves the local case. Preserve both sources in the note.

Vendor says fixed, scanner still flags

Check plugin freshness, authenticated scan quality, package backports, installed version evidence, and whether the scanner sees the actual fixed artifact.

Cloud provider says remediated

Confirm whether the provider fully fixed the service or whether tenants still need configuration, rotation, logging, access review, or integration changes.

Use source disagreement without dismissing evidence.

Say

NVD and vendor records differ; we are using vendor and product-owner evidence for action.

Do not say: NVD is wrong so ignore it.

Say

The scanner finding needs validation against vendor, distro, and backport evidence.

Do not say: Scanner proves affected.

Say

A vendor fixed version exists, but local deployment status is still under validation.

Do not say: We are remediated because the vendor published a patch.

Source difference review

Source difference review - [CVE/advisory]
NVD says: [severity/CVSS/CPE/affected product/description/reference]
Vendor/CNA says: [affected range/fixed version/workaround/prerequisites/exploit notes]
Distro/cloud/scanner says: [package/backport/provider action/plugin result/tenant action]
Local evidence needed: [installed version, feature state, exposure, owner, telemetry, change proof]
Difference: [CVSS / affected scope / fixed version / exploit note / remediation status / product mapping]
Decision basis: [vendor advisory / distro backport / cloud responsibility / local proof / risk acceptance]
Safe caveat: [what is not proven yet]
Owner and review trigger: [team/person/date/source update/vendor reply/scanner retest]