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

Use github advisories as a source instead of NVD #4130

Open
javixeneize opened this issue Mar 1, 2022 · 4 comments
Open

Use github advisories as a source instead of NVD #4130

javixeneize opened this issue Mar 1, 2022 · 4 comments

Comments

@javixeneize
Copy link

Hi

There are lots of false positives in Dependency check because of the data pulled from NVD. I have been querying NVD database and it is a nightmare to try to flag a vulnerability against a given library and version, i think this is the root cause for the false positives.

My recommendation is to use github advisories as the database source (if the license of the database allows you to do that). This data is much more clean and reliable and i think false positives will disappear, making this a much better tool.

Thanks

@mprins
Copy link
Contributor

mprins commented Mar 1, 2022

@javixeneize Please point us to comprehensive documentation on using the github advisories as a source of thruth.

@javixeneize
Copy link
Author

Sure. Here is the documentation for the graphql API

https://docs.github.com/en/graphql/reference/objects#securityadvisory

Some other documentation:

https://github.com/github/advisory-database

And an issue i did open there to see if a database can be built instead of querying the API for each library - github/advisory-database#30

I am building a SCA tool (Python) using those advisories as a source, and it is working quite well. If you consider to rewrite dependency check in python using github advisories, i will be pleased to take part on it :)

@jeremylong
Copy link
Owner

This has been on my list of things todo. However, it would not be a re-write - rather an additional source that could help reduce the FP rate. I do not think we would completely abandon the current search mechanism - just reduce its usage some. I'm still determining a plan around this (and other datasources).

A couple of other database include:

@javixeneize
Copy link
Author

yeah, i agree, the problem is with java mainly, i havent seen the same issue in other technologies.
I am not good in java, but if you need a hand to do it in python, count on me!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants