About vulnerability data sources¶
A vulnerability data source is an upstream feed of known security defects that Dependency-Track uses to find vulnerabilities in your components. No single feed covers every ecosystem, identifier scheme, or disclosure path, so Dependency-Track integrates with several. You pick which ones to enable based on what you ship and where the relevant advisories are published. None of them are required, and enabling all of them is rarely the right answer.
This page explains what each source contributes, how the data reaches your findings, and the trade-offs you accept when you enable a source or turn one off. For the procedure to enable sources, see Configuring vulnerability sources.
Mirrored sources¶
Dependency-Track can mirror three public data sources into its own database:
- National Vulnerability Database (NVD) is the canonical CVE feed maintained by NIST. It contains over 200,000 CVE records spanning the early nineties to the present and describes affected products as Common Platform Enumeration (CPE) names. NVD is the broadest source for non-package software (operating systems, firmware, network equipment), but its CPE-based product model is a poor fit for open source packages.
- GitHub advisories is GitHub's curated advisory database (GHSA). It covers open source packages on npm, Maven, PyPI, NuGet, Go, RubyGems, and others. Advisories use Package URL (PURL) keys, often appear before the corresponding NVD entry, and frequently carry more ecosystem-specific detail than the NVD record.
- OSV is Google's open source vulnerability database. It aggregates advisories from GitHub, PyPA, RustSec, the Go team, distribution security teams, and others into one PURL-keyed dataset, and it covers ecosystems and distributions that NVD and GHSA do not (for example crates.io, Hex, Pub, Alpine, and Debian).
Picking sources¶
The three feeds overlap heavily for open source ecosystems. Most operators do not need all three:
- GHSA and OSV cover much of the same ground. OSV ingests GitHub advisories and adds advisories from other curators (PyPA, RustSec, Go, distribution security teams). OSV also lets you mirror per ecosystem, which is finer-grained control than GHSA offers. If you want one source for open source packages, prefer OSV.
- GHSA is useful on its own if you stay close to the GitHub ecosystem or want the data exactly as GitHub publishes it, without the aggregation layer that OSV adds.
- NVD is the only mirrored source that meaningfully covers non-package software identified by CPE. Enable it when your BOMs include such components, or when you specifically need CVE coverage independent of curator-specific feeds.
How Dependency-Track uses the data¶
Mirroring is a background task. On a configurable schedule and at instance startup, Dependency-Track downloads new and changed records from each enabled source and writes them into its own database.
Vulnerability analysis is a separate process. When you upload a Bill of Materials or trigger analysis, the internal analyzer matches the project's components against the mirrored data already stored locally. The internal analyzer makes no outbound calls during analysis, which makes findings reproducible and keeps analysis fast.
For the full analysis workflow, see Vulnerability analysis.
Turning a source off¶
Disabling a source stops further mirroring from that source, but Dependency-Track does not delete the records it has already written. Vulnerabilities mirrored before the source was turned off remain in the database, and the internal analyzer keeps matching components against them on subsequent analysis runs. Findings already raised from that source are not retroactively removed either.
The practical consequence is that turning a source off is reversible without re-downloading, but it does not clean up after itself. If you intend to drop a source entirely and have its findings disappear, expect to clear the data manually. Dependency-Track does not yet provide a built-in workflow for this.
How component matching works¶
Each advisory in a mirrored source names the products it affects, using either a CPE or a PURL, and specifies the affected versions. The internal analyzer matches a component to an advisory by identifier scheme first and version second.
| Source | Identifier in records | What components need |
|---|---|---|
| NVD | CPE | A valid CPE on the component |
| GitHub advisories | PURL | A valid PURL on the component |
| OSV | PURL | A valid PURL on the component |
A component with neither a CPE nor a PURL is not evaluated.
CPE matching¶
CPE matching follows the NIST CPE name matching
specification: the analyzer compares all eleven CPE
attributes (part, vendor, product, version, update, edition, language, sw_edition, target_sw,
target_hw, other) and rejects the match if any attribute is disjoint.
Two adjustments reduce false positives compared to a literal reading of the spec:
- A SUBSET vendor combined with a SUPERSET product (or the reverse) is rejected, because these combinations otherwise produce noisy matches across unrelated products (see issue #3178).
- Component versions of
*(ANY) and-(NA) are handled per the spec, not run through range comparison.
When the advisory specifies a version range, the analyzer evaluates it using the
vers range specification, with a versioning scheme inferred from
the component's PURL when present and the generic scheme otherwise.
PURL matching¶
PURL matching requires the advisory's PURL type, namespace, and name to match the component's exactly. For
OS-package PURLs (deb, rpm), if both sides carry a distro qualifier they must agree, with semantic equivalences
honored (for example, debian-13 matches trixie).
Version comparison uses vers with the versioning scheme derived
from the PURL type. If the strict scheme fails to parse a version, the analyzer falls back to the generic scheme to
avoid false negatives. For deb and rpm PURLs, an epoch qualifier is folded into the version as epoch:version
before comparison when the version does not already encode one.
Practical consequence¶
Most modern BOM generators emit PURLs but not CPEs. As a result, components from package ecosystems (npm, Maven, PyPI, and so on) match GHSA and OSV well but produce few or no findings from NVD data, even when CVE records exist for those packages. This is the most common reason operators see fewer NVD findings than expected.
If you need NVD coverage for ecosystem packages, your BOM generator must also produce CPEs for those components. Otherwise, rely on GHSA or OSV for open source coverage and on NVD primarily for non-package software identified by CPE. The OWASP SBOM Forum's recommendations to improve the NVD document this CPE-vs-PURL mismatch and the industry effort to close it.
Aliases across sources¶
A single vulnerability often has different identifiers in different sources. Log4Shell, for example, is CVE-2021-44228
in NVD and GHSA-jfh8-c2jp-5v3q in GHSA.
Dependency-Track records aliases when sources publish explicit links between identifiers and surfaces them in the UI. Aliases do not de-duplicate findings: if two enabled sources both report Log4Shell for the same component, you see two findings, one per source, with the alias relationship visible on each.
Mirrored sources vs. external analyzers¶
The mirrored sources are not the only way Dependency-Track gets vulnerability data. It also ships analyzers that call external services at analysis time:
- OSS Index (Sonatype)
- Snyk
- Trivy (against a Trivy server you operate)
- VulnDB (Flashpoint, commercial)
These analyzers send component identifiers to a third party on every analysis run, return findings inline, and store nothing locally beyond the result. They complement the mirrored sources but introduce an outbound dependency and, in some cases, a commercial contract. See Vulnerability analyzers for the full list and their requirements.
Vulnerabilities you define yourself¶
The private vulnerability repository holds vulnerabilities you define yourself. Use it for vulnerabilities in internal code or for pre-disclosure tracking. Findings from private vulnerabilities behave the same as findings from public sources.
