How Does OESIS Prioritize the Source of Truth for CVE Reporting?

OESIS collects, analyzes, and reports CVEs by aggregating data from multiple upstream sources, including official vendor security advisories, the National Vulnerability Database (NVD), Microsoft, Linux distribution repositories, and other authoritative feeds. Because these sources do not always describe the same vulnerability in the same way, OESIS applies a defined order of precedence when deciding which source to treat as authoritative.

This article explains that order of precedence, why vendor advisories take priority over NVD and other feeds, and why this can cause OESIS results to differ from those of other vulnerability management tools.

Source-of-truth priority

When the same CVE is described by more than one source, OESIS resolves the conflict using the following order of priority:

1. Vendor security advisory: For products whose vendor publishes its own security advisory (for example, Oracle, Microsoft, Adobe, or a Linux distribution), the vendor advisory is treated as the primary source of truth for affected versions and remediation.
2. NVD: Where a vendor does not publish a dedicated advisory for a product, OESIS uses NVD as the source of truth. NVD is the source we rely on most widely across the supported product catalog.
3. Other authoritative feeds: Additional sources, such as distribution repositories and internal research data, are used to enrich or corroborate the above when a vendor advisory or NVD entry is unavailable or incomplete.

The key principle: the entity that produces the software is the most authoritative source for which versions of that software are vulnerable. When that entity publishes an advisory, OESIS follows it.

Why vendor advisories take priority over NVD

Under the industry CVE publication process, the vendor (acting as the CVE Numbering Authority, or CNA, for its own products) is responsible for validating and stating which versions of its products are affected by an identified security vulnerability. Vendors have direct knowledge of their own codebase, build history, and fix versions, so their advisories are the most accurate statement of the affected version range.

NVD and other downstream databases are valuable for breadth and consistency, but they reproduce and interpret information that ultimately originates from the vendor. When a vendor advisory and NVD disagree, OESIS defers to the vendor because that is where the authoritative determination is made in the publication process.

OESIS also follows the versions explicitly stated in an advisory rather than inferring a broader range. Advisories do not always spell out the full set of affected versions, and assuming that every earlier version is affected can produce false positives. To avoid reporting versions as vulnerable without vendor confirmation, OESIS reports the versions the advisory identifies unless there is additional authoritative information that confirms a wider range.

Why results may differ from other vulnerability management tools

Different vulnerability management vendors make different choices about which source to trust and how to interpret an advisory. Some tools default to NVD-derived CPE ranges, and some expand a stated version into a broader "less than or equal to" range. Because OESIS prioritizes the vendor advisory and reports the versions it explicitly identifies, OESIS may flag a narrower or different set of versions than a tool that relies primarily on NVD or on an expanded range.

This is an expected outcome of the prioritization model, not a detection gap. The difference reflects the source each tool treats as authoritative.

Example 1: CVE-2024-54534 (Oracle Java)

CVE-2024-54534 affects Oracle Java and illustrates how the prioritization works in practice.

OESIS marks 8.0.4410.7 as affected because that is the version specifically referenced in Oracle's advisory. Oracle Critical Patch Updates are cumulative, so it may be reasonable to assume earlier versions also contain the vulnerability, but Oracle does not always explicitly confirm the full affected range. Rather than automatically assuming all earlier versions are vulnerable, OESIS reports the version Oracle states, which avoids flagging versions as vulnerable without vendor confirmation.

A scanner that interprets the same advisory as <= 8.0.4410.7 will report a broader range. Both tools are reading the same Oracle advisory; the difference is in interpretation. OESIS follows the version explicitly identified by the vendor.

Example 2: CVE-2020-16918 and CVE-2020-17003 (Microsoft 3D Viewer)

This pair of CVEs affects Microsoft 3D Viewer and shows the same principle working in the opposite direction, where OESIS correctly does not flag a version that another scanner reports as vulnerable.

A question was raised about why version 6.1908 was not flagged, given that some external scanners report every 3D Viewer version as vulnerable. OESIS uses Microsoft's MSRC advisory as the trusted source. That advisory points to the CVE.org record, which defines the vulnerability as affecting 3D Viewer from version 7.0.0. Because 6.1908 is below that floor, OESIS does not report it as vulnerable. After review, the broader detection was confirmed to be a false positive on the other scanner's side, not a miss by OESIS.

This is the mirror image of Example 1. In the Oracle case, prioritizing the vendor advisory produced a narrower range than other tools. Here, prioritizing the vendor advisory means a lower version reported elsewhere is correctly excluded. In both cases OESIS reports what the vendor states.