Vulnerability querying service

[oliverchang]

Hi!

We're (Google) planning to release an open source service for finding known vulnerabilities in open source.

The problem we're trying to solve is that there is no single place that can be queried easily for vulnerabilities that affect a user of an open source library, in a way that's convenient for both open source users and automation tools.

We've already built this using data from OSS-Fuzz, and intend to provide an API where a user can query for vulnerabilities by POSTing to our endpoint with queries such as:

{ "commit": "hash" }  // can be a commit hash in any open source project we know about

{"package": {"name": "blah", "ecosystem": "npm"}, "version": "1.0.0"}

We're planning on launching this soon and expanding this with data from other ecosystems (e.g. Go, Node).

For this service, we need a simple schema to present results. As I understand it, the schema at https://github.com/ossf/wg-vulnerability-disclosures/blob/main/src/schema/vulnerability.schema.json is no longer worked on or supported, so we have come up with our own very similar and simplified one.

Draft schema: https://gist.github.com/oliverchang/d38d9382485c146a3774a4cc3d027e17 (in protobuf, will be translated to JSON).

This schema does not intend to compete with other existing schema efforts (e.g. the CVE JSON schema) to present comprehensive information about every vulnerability. Rather, it's intended to be minimal and present the bare-bones information needed for the querying service. This schema can link to other schema if available for more complete information.

Would this project be of any interest to folks here for potential collaboration?

[coderpatros]

I'm interested in how this will differ from something like package URL and OSS Index?

[oliverchang]

Hi,

We haven't decided to adopt package URLs, but they can be potentially quite easily supported.

Our service will be open source, and a key difference is that we want to promote vulnerability tracking closer to the actual open source development process (i.e. using commit hashes/tags to version things).

For each vulnerability we try to have the exact commits which introduce and fix the bug, and longer term will be able to provide a generic bisection infrastructure to automate this. Once we have these two bits of information, we can automatically compute all affected commit ranges and release tags (i.e. versions). This is also useful for language ecosystems where depending on some version of master is common (e.g. C/C++, and Go).

[coderpatros]

Yeah, package URLs aren't much different to that example you gave for querying for an npm package. It should be easy to translate between the two.

[pombredanne]

@oliverchang that's awesome!

I guess this would be redundant with this other project https://github.com/google/vulncode-db by @evonide would it?

Note also that there is an effort from SAP's https://github.com/SAP/project-kb by @copernico that tracks vulnerabilities commits to do interesting things.

And we are also building an open vulnerability database at https://github.com/nexb/vulnerablecode that would welcome your data and we have had in the plans to add OSS-Fuzz data for a while aboutcode-org/vulnerablecode#117

You also wrote:

We haven't decided to adopt package URLs, but they can be potentially quite easily supported.

I am the original author of package URLs so I would of course be cheering loudly for their use, in a totally unbiased way ;)

More practically, this would help a lot with the reuse of your data as @coderpatros pointed out.

[evonide]

Thanks for highlighting Philippe it's really exciting to see so many developments in that space!
I've reached out to Oliver to clarify where we have overlapping goals and where a cooperation would be possible :).

[JasonKeirstead]

Have you looked a SARIF?

SARIF was developed to communicate this type of information (the results of static analysis of code). It was developed by Microsoft, MicroFocus, MITRE, Bank of America and others.

https://www.oasis-open.org/committees/sarif/charter.php
https://docs.oasis-open.org/sarif/sarif/v2.0/sarif-v2.0.html

I am not an expert in SARIF but in the interest of not-reinventing-wheels we should consider it.