Conflicting-Source Resolution

Summary

A source conflict is a material difference between records about the same security question. It does not mean either record is wholly false. Conflicts often come from different scope, timing, product branch, evidence type, terminology, or source authority. Resolve each claim separately, preserve material source values, and keep unresolved conflict visible.

Why it matters

Vendor, CVE Program, NVD, CISA KEV, EPSS, research, incident reports, and internal telemetry can legitimately answer different questions. Silent overwrite loses provenance. Missing data is not contradiction, and one preferred display value must not erase source context. Publication and modification dates help distinguish a correction, retraction, superseding update, or merely stale record.

When to use this guidance

Use this when CVE descriptions, titles, dates, CVSS scores, vendor severity, affected products, fixed versions, backports, exploit claims, KEV state, EPSS values, local telemetry, or definitions of affected, exposed, and compromised appear to disagree.

Prerequisites

Collect original source records and preserve source name, type, record ID, URL, publication date, modification date, retrieval context, raw value, scope, and direct versus inferred evidence. Start by naming the exact claim under review, not by trying to merge an entire record automatically.

Core concepts

Scope difference can explain different branches, platforms, packages, deployment models, or definitions without creating a true contradiction.
Timing difference can explain an older advisory, later correction, retraction, superseding update, or date-sensitive EPSS value. Stale data is not necessarily fraudulent.
Source absence and missing data are not automatically contradiction. Record what a source does and does not claim.
Preferred display value is a justified value for a specific use. It preserves alternate values and provenance rather than deleting them.
Global evidence and local evidence can both be valid at different scopes. No local telemetry is not proof of no compromise.

Common conflict types

Common cases include conflicting CVE descriptions or titles; publication and modification dates; CVSS version or score differences; vendor severity versus NVD severity; affected or fixed-version differences; first-fixed release versus superseding update; package backport versus upstream version; vendor advisory versus third-party summary; exploit claim versus observed exploitation; KEV inclusion versus absence from another catalog; EPSS changes over time; disputed, rejected, withdrawn, or corrected CVE states; product branches; deployment models; and global reporting versus local telemetry.

Claim-specific source authority

Authority depends on the claim. Prefer the CVE Program record for CVE state such as reserved, published, rejected, or withdrawn. Prefer a vendor advisory or release note for that vendor product's fixed release and branch. Keep vendor severity separately attributed from NVD-provided CVSS, including vector and version. Use CISA KEV for catalog inclusion, EPSS with score, percentile, and date from its source, technical and incident evidence for exploit claims, validated asset and configuration evidence for local exposure, and investigation evidence for local compromise.

Source precedence without data loss

Claim-specific precedence selects a preferred value for a stated purpose; it does not create a universal source-precedence order. Preserve raw source value, normalized value where safe, authority, scope, freshness, conflict state, preferred display value, reason for preference, and unresolved limitations. A distribution advisory and package changelog can be preferred for a distribution backport even when an upstream version appears older.

Conflict classification

Conflict class	Typical signal	Resolution approach	Common mistake
Scope difference	Different product branch, edition, or deployment	Preserve scope; compare like with like.	Publishing one universal fixed version.
Timing difference	Older advisory versus updated revision	Preserve dates and supersedence.	Calling an older record fraudulent.
Different scoring framework	Vendor severity differs from NVD severity	Keep both with source, vector, and version.	Averaging CVSS scores.
Package backport	Package revision differs from upstream version	Use distribution evidence for that package.	Generic upstream comparison.
Global versus local evidence	Public report but no local alert	Assess local applicability and telemetry coverage.	Treating no alerts as no compromise.
Unresolved contradiction	Material claims remain incompatible	Preserve both and name resolving evidence.	Hiding uncertainty.

This is guidance, not an exhaustive taxonomy. Analyst judgment is required when scope and evidence remain unclear.

Practical resolution workflow

Define the exact claim in conflict.
Collect original source records and dates.
Identify product, branch, platform, package, and deployment scope.
Determine whether scope, timing, or terminology explains the difference.
Identify authority for the specific claim.
Compare direct evidence with summaries and inference.
Check corrections, retractions, supersedence, and freshness.
Preserve all material conflicting values.
Select a preferred display value only when justified.
Record the preference reason and remaining limitations.
Mark an unresolved conflict when evidence is insufficient.
Define resolving evidence and reassessment triggers.

Handling severity conflicts

CVSS versions, vectors, source roles, and assumptions can differ. Vendor severity and NVD severity should remain separately attributed. Do not average scores or use a universal severity winner. Keep the score, vector, CVSS version, date, and source. Business criticality and exploit evidence are not severity, and a preferred display score must not erase material alternatives.

Handling product and version conflicts

Do not collapse aliases, editions, branches, server and client products, package versions, upstream versions, builds, KBs, package revisions, or hotfixes. A vendor backport can resolve a CVE without an upstream version jump. First-fixed release differs from a superseding update. Open-ended ranges and unsupported branches need caution. Absence of a fixed version in one source does not prove no fix exists; do not publish a safe version unless explicit source evidence supports the exact product context.

Handling exploit and local-evidence conflicts

Exploit code can exist without confirmed active exploitation; active exploitation elsewhere does not prove local compromise; KEV and EPSS answer different questions; and scanning is not successful exploitation. Internal telemetry may differ from global reporting because conditions and visibility differ. Local applicability needs asset and configuration evidence, while local compromise requires investigation evidence. Preserve uncertainty and coverage gaps.

Evidence to collect

Record claim type; source name and type; record ID, URL, publication and modification dates, retrieval context, raw and normalized values; product, branch, version, package, platform, scope; authority; direct versus inferred evidence; freshness; corrections or retractions; corroboration; conflicting values; preferred value and reason; unresolved limitations; local applicability; telemetry; confidence; next evidence; and reassessment trigger.

Common mistakes

Do not silently overwrite older values, treat missing data as contradiction, use one precedence order for every field, treat NVD severity as vendor severity, average CVSS, merge incompatible branches, compare package and upstream versions generically, prefer a third-party summary to a primary source, discard older records without checking timing, hide unresolved conflict, treat KEV as local compromise, treat no alerts as no compromise, or collapse global and local evidence.

Worked example

A fictional CVE Program record is published for a broad product family. NVD provides one CVSS score and broad affected range. A fictional vendor advisory provides a different severity and narrower branches, with a fixed release for branch A. A fictional distribution advisory documents a backported package fix for branch B. A third-party article wrongly says every version below the branch-A release is vulnerable. An older vendor advisory lacks branch-B detail; a newer update adds it. CISA KEV includes the CVE, and EPSS changes between two dates. One internal asset runs branch A; another uses the distribution package on branch B. Local telemetry has no matching alerts but incomplete coverage. The CVE Program governs record state. NVD and vendor severity remain separate. Vendor guidance applies to branch A; distribution evidence applies to branch B; the universal third-party claim is overbroad. The older advisory is stale, not necessarily false, and the newer update resolves part of the conflict. KEV supports known exploitation evidence but not local compromise; EPSS retains its date. The assets need separate applicability conclusions, and no alerts do not prove no compromise.

Writing a bounded resolution note

Use: Claim under review; Sources compared; Scope of each source; Publication and modification dates; Material differences; Authoritative source for this claim; Preferred display value; Preserved alternate values; Reason for preference; Remaining conflict; Local applicability; Confidence; Limitations; Next evidence needed; and Reassessment trigger.

Reassessment triggers

Reassess after source corrections, retractions, vendor revisions, CVE Program updates, package changelog changes, new KEV or EPSS data, improved telemetry, configuration changes, or new incident evidence. Preferred values can change when material sources update.

Limitations

Public sources can be incomplete, update timing varies, some authoritative sources require authentication, terminology differs, normalization can lose context, version comparison can be vendor-specific, and internal telemetry can have gaps. Unresolved conflicts may remain. This guidance does not replace vendor, incident-response, legal, regulatory, or change-management requirements.