Towards a centralized vulnerability database for Dependency-Track #4122
Labels
enhancement
New feature or request
help wanted
Extra attention is needed
p2
Non-critical bugs, and features that help organizations to identify and reduce risk
size/XL
Higher effort
Current Behavior
When Dependency-Track came into existence around 2013, the only public and widely accepted vulnerability database was the NVD. Since its inception, DT has supported
mirroring of the NVD.
Over the past decade, multiple other public vulnerability databases came into existence:
Those databases filled a large gap in the vulnerability intelligence space: They support Package URL. To this date, the NVD still operates exclusively on CPE, which is understood to be problematic.
Further, more and more entities maintain their own databases, which may or may not feed into the larger databases listed above, for example:
The NVD is a database provided by the US government. Other nation states or regions
May provide their own equivalent - The EU discussed this possibility, and China already has one. Vendors selling products in these regions will likely need to analyze their products using such databases to comply with regulations.
The situation is further complicated by the fact that multiple sources can provide information for the same vulnerability: While the NVD will only report CVEs, and GitHub Security Advisories only GHSAs, OSV may report both. This can lead to conflicting information, since vulnerability metadata may vary across data sources: descriptions, severities, risk ratings, affected version ranges, fixed versions, and more.
Currently, DT tries to avoid surfacing conflicting information to users by enforcing which source can modify what kind of vulnerability. For example, the NVD is considered the authoritative source for CVEs, GitHub for GHSAs, and so on. This system fails when, like it happened with the NVD, upstream databases lag behind in providing up-to-date information. A problem which could be avoided by taking the data of all databases into consideration.
Finally, by having each instance of Dependency-Track download all this data over and over again, we’re putting public infrastructure such as the NVD under unnecessary stress. The NVD experienced major availability issues at the beginning of 2024, and the many DT instances downloading data from it certainly played their part in this.
Related issues:
vers
version ranges and ecosystem-specific version comparisons #2826Related discussions:
Proposed Behavior
The primary goal is to establish a centrally managed, pre-compiled vulnerability database, that all DT instances can consume. Users should receive more accurate, more complete data out-of-the-box, without having to tweak any settings.
Further details are documented here: https://docs.google.com/document/d/1DVV4ik7NGOBc6u-fdPlPVKoplNmSpzDT6iC4FJAFYi0/edit?usp=sharing
Note
Please request edit permissions if you'd like to add comments or suggest changes.
Checklist
The text was updated successfully, but these errors were encountered: