Existing artifact vuln scanners, databases, and specs?

[westurner]

What are the existing [container] artifact vuln scanners, databases, and specs?

tools, vuln databases

awesome-docker-security >
Container [vuln] scanning:

• @aquasecurity/#Trivy
• @quay/#Claire
• @project_harbor/#Harbor #CNCF
• @anchore/#Syft
• @anchore/#Grype
• #Dagda works w/ Falco
• @falco_org/#Falco #CNCF #sysdig
• @snyksec/#Snyk sends PRs
  https://github.com/myugan/awesome-docker-security#container-scanning

• List of CNCF open source security projects:
  https://landscape.cncf.io/card-mode?category=security-compliance&grouping=category&license=open-source
• https://analysis-tools.dev/tag/security
• https://github.com/TaptuIT/awesome-devsecops#dependency-management
• Trivy data sources:
  https://github.com/aquasecurity/trivy#data-sources
• https://github.com/anchore/grype
  • syft scans and generates a SBOM, grype does lookups etc
  • https://github.com/anchore/grype/tree/main/grype/matcher
• https://github.com/DependencyTrack
• https://github.com/eliasgranderubio/dagda
  • https://github.com/jeremylong/DependencyCheck
    • https://www.owasp.org/index.php/OWASP_Dependency_Check

      Dependency-Check is a Software Composition Analysis (SCA) tool that attempts to detect publicly disclosed vulnerabilities contained within a project’s dependencies. It does this by determining if there is a Common Platform Enumeration (CPE) identifier for a given dependency. If found, it will generate a report linking to the associated CVE entries.

  • ClamAV, Falco

standards

SBOM standards:

• https://cyclonedx.org/

[westurner]

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?

[rschultheis]

👋 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 security-advisories@github.com if you would ever like to discuss any details.

[oliverchang]

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!

[Shnatsel]

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@.

[cniweb]

Hello,

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

Thanks
Christian

[oliverchang]

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

[westurner]

• 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.