Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Towards a centralized vulnerability database for Dependency-Track #4122

Open
2 tasks done
nscuro opened this issue Sep 4, 2024 · 0 comments
Open
2 tasks done

Towards a centralized vulnerability database for Dependency-Track #4122

nscuro opened this issue Sep 4, 2024 · 0 comments
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

Comments

@nscuro
Copy link
Member

nscuro commented Sep 4, 2024

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:

Related 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

@nscuro nscuro added 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 labels Sep 4, 2024
@nscuro nscuro pinned this issue Sep 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Projects
None yet
Development

No branches or pull requests

1 participant