Existing artifact vuln scanners, databases, and specs? about osv.dev HOT 7 CLOSED

👋 Hello from the GitHub Advisory Database team!

This project looks really neat, and also quite similar to what we are hoping to do with GitHub Advisory Database long term: make a comprehensive and timely database of all the vulnerabilities in all of open-source.

Our current advisory data is available through our API and anyone is welcome to use it, including for commercial purposes.

We do not currently support the C ecosystem unfortunately, and it appears the initial data in OSV is focussed on C. When do add support for C we will reach out about importing the data from OSV. If there is some way we could modify our data to better support the goals of OSV I would love to hear those ideas.

Generally I would love for GitHub and Google to collaborate on some standards for what metadata is important. In particular I would like to know what metadata is important for supporting container scanning. The GitHub database is not really setup currently to support container scanning (though the trivy scanner does use our data to scan containers). Our data was initially tailored for our own Dependabot scanner, but we ultimately want to ultimately support all kinds of scanners.

You can find us at [email protected] if you would ever like to discuss any details.

from osv.dev.

Hello from the Secure Code working group of the Rust programming language! We maintain a machine-readable database of vulnerabilities in Rust libraries ('crates' in Rust parlance) published on crates.io, Rust's central package repository. The data is in the public domain, stored in a Github repo in TOML format.

We already track the precise ranges of affected versions and provide automated tooling to scan projects for vulnerabilities. Our tooling assumes the Cargo build system. We'd be very happy to make our data available more broadly, e.g to Linux distros or to companies that don't use Cargo.

You can check out the schema and browse the actual data here. Our contacts can be found here. Googlers can contact me internally at sdavydov@.

from osv.dev.

Closing, as we document all our data sources in https://github.com/google/osv.dev/blob/master/README.md.

from osv.dev.

It's worth pushing for CodeMeta Schema.org JSON-LD for general [software, research] object metadata. https://github.com/codemeta/codemeta/blob/master/codemeta.jsonld

https://codemeta.github.io/

All of these catalogs could be linked data with a common schema at the sources someday.

Practically, how do I link from the CodeMeta metadata for a https://schema.org/SoftwareApplication with an @id and https://schema.org/url s (mapped from the native package metadata to the CodeMeta JSON-LD @context with CodeMeta crosswalks) to the https://schema.org/identifier s in each of the respective vuln databases?

from osv.dev.

Hi @rschultheis Thank you for reaching out! It's awesome to see the work that you've already done in this space and the similar goals :)

We are very very interested to collaborate in this space (in particular defining a standard format for interchange and scanning). I'll reach out to the email you provided soon to discuss in more detail!

from osv.dev.

Hello,

can you support Sonatype OSS Index:
https://ossindex.sonatype.org
REST-API:
https://ossindex.sonatype.org/doc/rest

Thanks
Christian

from osv.dev.

• https://codemeta.github.io/ for reading SoftwareApplication metadata from an expanding set of software package formats

  • https://github.com/codemeta/codemeta :

    Minimal metadata schemas for science software and code, in JSON-LD

    CodeMeta contributors are creating a minimal metadata schema for science software and code, in JSON and XML. The goal of CodeMeta is to create a concept vocabulary that can be used to standardize the exchange of software metadata across repositories and organizations. CodeMeta started by comparing the software metadata used across multiple repositories, which resulted in the CodeMeta Metadata Crosswalk. That crosswalk was then used to generate a set of software metadata concepts, which were arranged into a JSON-LD context for serialization.

from osv.dev.