Root Datasource

[chait-slim]

Hi 👋
We are Root and we are creating images with zero vulnerabilities. Unlike other datasources, we fix the vulnerabilities using the original operating system. That is, we create our Root version of packages for Debian, Ubuntu, Alpine, Rocky, etc.
In addition, we are also creating patches for application level vulnerabilities for all the major languages: Go, Python, JS, etc.
Looking at other implementations, I see this is not standard as most (if not all) feeds address only one ecosystem or one package manager, whereas we are multi-ecosystem + multi-package managers
I would appreciate your guidance on the best way going forward of adding our feeds to osv:

1. Should I create an osv feed per use case (per ecosystem, per package manager)? Or can I "aggregate" feeds (one feed for all os ecosystems + one feed for all package managers)?
2. Should I create multiple ecosystems for Root (i.e, one for APK, DEB, etc.) or just one where I parse it accordingly?
3. Same question as (2) but for package managers

I hope our use case is clear and will be more than happy to explain in more detail if needed

[another-rex]

Hello! Thanks for the interest!

From taking a quick look at your website FAQ, it looks like you don't provide the base images, but patch the existing images with fixed OS/language packages right? This sounds like a use case for VEX statements rather than OSV records.

This has been requested a few times (e.g. by chainguard.dev and lineaje.com). We are currently looking into better support for input VEX statements for our official tooling (osv-scanner and osv-scalibr) to support this exact use case.

Process would look something like this:

1. Vulnerability scanners do the initial scan and get vulnerabilties from osv.dev
2. Those vulnerabilities are then matched against a VEX feed published by Root
3. VEX feed will remove the affected versions that have been patched by Root from the output results

Let us know if this workflow makes sense for what you guys are looking to accomplish.

[benjifin]

Hey @another-rex !
So our use case at Root we is actually pretty well suited for OSV we believe - we both provide our own base images, as well as provide patches on top of existing images. We're looking for a more generic soloution to VEX (i.e. one that's tied to a specific image) as our patches are generically applicable across any image used. In general we're big supporters of OSV, and would love to help contribute to having our own users be able to use it to get actionable info on their images 😄

To help clarify we've done a similar integration already into Trivy's vulnerability feeds, which we believe we could follow a similar pattern here:
aquasecurity/trivy#9073
aquasecurity/vuln-list-update#357
aquasecurity/trivy-db#546

Let me know if this makes, sense or if there's anything we need to further clarify or if we're missing some important context here.

[another-rex]

For base images that you are publishing, having your own OSV ecosystem is definitely the way to go. We do something similar with other similar images.

For custom patches on top of existing images however, I still think VEX is what you are looking for. What I'm thinking here is not tied to a specific image, but a system that works something like this:

1. User calls osv-scanner with: osv-scanner scan image abc:latest --vexfeed="https://root.io/vex/feed/"
2. Scanner will scan through the image, and for every package found (e.g. curl@1.2.3-root-patch-1)
3. Query the vex feed "https://root.io/vex/feed/curl", which will respond with a list of patched versions and what vulns they patch a standard VEX format.
4. Those are excluded from the results.

[chait-slim]

Thanks @another-rex for the detailed response.
This is a plan we can work with. If I understand correctly these are the base tasks that I will implement:

1. Create a Root ecosystem where we will deal with the base images we are publishing
2. Provide a vex feed for user-provided images and work with the flow you've presented.

Is there a suggested list of tasks or PRs I can look at to start working on?

[another-rex]

Yep that looks right:

For 1. take a look at https://google.github.io/osv.dev/data/new which should detail all the steps needed to publish a new source of data.

For 2., on the scanner and scalibr side we still need to get some of this implemented, and it is slightly blocked on a few refactors we are currently doing. Feel free to get started generating the feed on the root.io side, but just know the filtering implementation is still WIP.

[github-actions]

This issue has not had any activity for 60 days and will be automatically closed in two weeks

See https://github.com/google/osv.dev/blob/master/CONTRIBUTING.md for how to contribute a PR if you're interested in helping out.

[chait-slim]

@another-rex its been a while. We have opened PRs for
osv.dev
osv-schema

[github-actions]

This issue has not had any activity for 60 days and will be automatically closed in two weeks

See https://github.com/google/osv.dev/blob/master/CONTRIBUTING.md for how to contribute a PR if you're interested in helping out.