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

Library Identification problem (OSV) #6039

Open
lbruun opened this issue Nov 4, 2023 · 1 comment
Open

Library Identification problem (OSV) #6039

lbruun opened this issue Nov 4, 2023 · 1 comment

Comments

@lbruun
Copy link

lbruun commented Nov 4, 2023

One of the issues with this checker (IMO) is that it creates too many false positives. One reason is that (up until now) there has not been a good database with mappings between a CVE and actual library coordinates in various ecosystems (for example Maven, NuGet, etc).

At the moment the analyzers in OWASP DependencyCheck simply look at various strings to see if they match. It would be far more relevant to look at the actual coordinates of the dependencies that a project uses. For example for a Maven project: Look at each GAV coordinate that the project uses and see if there's a match in the vulnerability database. This type of analysis would be a great complement to the analysis the tool is already doing.

This can hopefully avoid the problem where a library (dependency) happens to have a similar name as to another library which has a known CVE on it ... and therefore incorrectly gets flagged.

Describe the solution you'd like

Perhaps look at Google's OSV.dev database which can do this mapping.

@jeremylong
Copy link
Owner

The plan is that next year we would move to a different datasource - be it OSV or GHSA or something else. We should have migrated already but we haven't had time as this is going to be a significant re-write.

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

2 participants