> ## Documentation Index
> Fetch the complete documentation index at: https://docs.binarly.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Vulnerability Database Overview

> How the Binarly Vulnerability Database aggregates vulnerability data from many sources into variants on each finding and reconciles severity across them.

The Binarly Vulnerability Database (VDB) aggregates vulnerability data from the sources listed in [Vulnerability Data Sources](/resource-center/vdb-sources) and attaches each source's data to the corresponding finding as a variant. This is what lets a finding carry accurate severity, exploitability context, and patch status without you having to reconcile conflicting advisories yourself.

## Finding variants

A vulnerability can be reported under different identifiers across sources: a CVE, a GHSA advisory, a distribution-specific advisory, and so on. Rather than merging these into one record, the VDB keeps each source's data as a separate variant on the same finding. The variant matching a product's configured ecosystem is applied by default, and every other source's data stays available on the finding as an alternative variant.

See [Finding Variants](/user-guides/image-scans/finding-variants) for how the applied variant is chosen and how to configure source priority per product.

## Severity reconciliation

When sources disagree on severity, the VDB picks a CVSS score using a defined source-priority order rather than an arbitrary one, then fills in any missing CVSS vector fields from lower-priority sources without overriding the chosen score. NVD is the default primary source; see [Vulnerability Data Sources](/resource-center/vdb-sources) for how other sources fit into that priority order, and [Finding Variants](/user-guides/image-scans/finding-variants) for how to override source priority per product.

## Supporting correlation data

Beyond the named sources, the VDB maintains additional data to keep matching accurate:

* **CPE correction** - known-incorrect vendor/product associations in NVD's own CPE data are corrected, so a component isn't matched to the wrong CVE because of an upstream CPE error.
* **PURL and CPE cross-referencing** - Package URLs and CPE identifiers for the same component are cross-referenced against each other, supporting the component identifiers described in [Provenance](/resource-center/provenance).
* **Upstream release monitoring** - current stable versions are tracked for supported projects, which helps flag components that are stale or past end-of-life independent of any specific CVE.

## Related

* [Vulnerability Data Sources](/resource-center/vdb-sources) - Full reference for every source the VDB aggregates
* [Vulnerability Detection](/resource-center/vulnerability-detection) - How version-based detection uses VDB data to identify vulnerabilities
* [Provenance](/resource-center/provenance) - How components are attributed to a package, vendor, and product
* [Finding Variants](/user-guides/image-scans/finding-variants) - Configure source priority per product
* [Risk Scoring](/resource-center/risk-scoring) - How exploitation intelligence influences finding priority