Map packages against Google OSV

[ESultanik]

• Extend the it-depends API to associate vulnerabilities with packages
• Use Google OSV as a data source to automatically assign vulnerabilities to packages
• Provide a command line option similar to npm audit that reports the known vulnerabilities for a project

[hbrodin]

Google OSV have a term ecosystem that describes the context for a package. There are a number of them e.g. npm, PyPI, crates.io - these have fairly straightforward mapping to our resolvers (npm, pip and cargo).

How to map the the rest of our resolvers to their ecosystems is not straightforward.

I have not seen that many false positives so far since package names are kind of unique (especially in combination with version). One exception is tar:1.30.0+dfsg which returns information from the npm echosystem.

My suggestion is that we accept the current situation since it is not very clear how to get confidence in the mapping. E.g. what do a OSS-Fuzzing/*-project map to?

Any thoughts on this?

[ESultanik]

I think that's reasonable. For resolvers that don't have an associated context in Google OSV, I think we can eventually switch to another source of information like CVEdb, although that might have more false positives