google / osv.dev

Open source vulnerability DB and triage service.
https://osv.dev
Apache License 2.0
1.5k stars 186 forks source link

Feature Request : Add support for Wolfi Linux #1003

Closed fproulx-boostsecurity closed 2 weeks ago

fproulx-boostsecurity commented 1 year ago

You currently support Debian and Alpine.

More and more people are looking at switching to Wolfi (Chainguard). Last month trivy added support for Wolfi https://github.com/aquasecurity/trivy/pull/3215

andrewpollock commented 1 year ago

Looks like the source of truth is https://packages.wolfi.dev/os/security.json and from eyeballing it and seeing "apk" mentioned plus some other references to Alpine in https://github.com/aquasecurity/vuln-list-update/blob/main/wolfi/wolfi.go makes me think this might be trivial to reuse (some of) the existing Alpine plumbing, WDYT @another-rex?

another-rex commented 1 year ago

We can probably reuse much of the alpine version ordering logic, but it looks like parsing the security vulnerabilities and enumerating the package versions will have to be done from scratch. (Only had a quick look though, might be wrong)

kaniini commented 1 year ago

makes me think this might be trivial to reuse (some of) the existing Alpine plumbing, WDYT @another-rex?

You should be able to reuse almost all of it, this is the standard apk security fixes feed format that all the apk-based distros are using.

oliverchang commented 1 year ago

makes me think this might be trivial to reuse (some of) the existing Alpine plumbing, WDYT @another-rex?

You should be able to reuse almost all of it, this is the standard apk security fixes feed format that all the apk-based distros are using.

Thanks @kaniini ! Is there any chance you'd be open to supporting OSV natively in Wolfi?

Our custom conversion pipelines add a fair bit of maintenance burden and we may also make incorrect assumptions / get things wrong from time to time.

kaniini commented 1 year ago

In the apk distribution community we are largely looking at OpenVEX as the mechanism for distributing advisory data, but it may be possible to reflect that in a way that OSV can consume directly.

cc @luhring for his thoughts.

oliverchang commented 1 year ago

That would be amazing to see, if the OSV format can be embedded or linked from there somehow. I think there would be a lot of community interest in getting Wolfi added to the growing ecosystem of vuln DBs supporting OSV (e.g. Rocky Linux which recently added support).

luhring commented 1 year ago

This sounds cool! I think it'd be possible to produce OSV data from our advisory data. I think it's something worth considering at some point in the near future.

For now, +1 to what @kaniini said, Wolfi's secdb is just like Alpine's (same JSON format), so I'd imagine the dev work and additional maintenance burden might not be too bad. The key differences are:

  1. The data comes from https://packages.wolfi.dev/os/security.json (as @andrewpollock points out)
  2. There's just one continuous release branch and thus a single secdb — there aren't multiple release branches like Alpine has (e.g. Alpine 3.13, 3.14, 3.15, edge, etc.).
amdawson commented 6 months ago

Chainguard is now publishing OSV data for Wolfi and Chainguard images. I think osv.dev is ingesting the Wolfi feed and is still working on the chainguard feed

wolfi - https://packages.wolfi.dev/os/osv/all.json chainguard - https://packages.cgr.dev/chainguard/osv/all.json

oliverchang commented 6 months ago

Wolfi advisories are being ingested into our test instance: https://test.osv.dev/list?ecosystem=Wolfi&q=

andrewpollock commented 2 months ago

The data is now available in Production.

https://osv.dev/blog/posts/announcing-chainguard/

github-actions[bot] commented 2 weeks ago

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.