Integrate security reports with OSV.dev

[taraspos]

Is your feature request related to a problem? Please describe.
OSV.dev is OpenSource vulnerability database integrated with various tools (like Renovate Bot for example). Currently it lacks data about container image/helm chart vulnerabilities.

Artifacthub.io runs trivy to scan container images¹, would be great to be able to see vulnerability information collected by Artifacthub in osv.dev.

Describe the solution you'd like
OSV.dev has multiple ways to contribute vulnerability information ². ArtifactHub could publish results of trivy scans to the database. As per REST API datasource example, implementation will require two new endpoints, one to list all available CVEs and one to get CVE details:

		// Security
		r.With(compress).Route("/security", func(r chi.Router) {
			r.Route("/osv/", func(r chi.Router) {
				r.Get("/all.json", h.Security.GetAllVulnerabilities)
				r.Get("/{cveID}.json", h.Security.GetCVEDetails)
			})
		})

Vulnerabilities should be formatted in OSV Schema³

Describe alternatives you've considered
N/A

Additional context

• Import container/helm vulnerabilities from ArtifactHub.io google/osv.dev#2666

Footnotes

1. https://artifacthub.io/docs/topics/security_report/ ↩

2. https://google.github.io/osv.dev/faq/#can-i-contribute-data ↩

3. https://github.com/google/osv-scanner/blob/main/pkg/models/vulnerability.go ↩

[andrewpollock]

Greetings from OSV 😄

OSV.dev's onboarding process in a nutshell (actionable feedback welcome):

• Decide if you're going to publish records via a Git repository, GCS bucket or REST endpoint
• Create a PR to reserve a prefix in the OSV-Schema (worked examples: Add Mageia ecosystem ossf/osv-schema#235 Add Malicious Packages and the "MAL" id namespace. ossf/osv-schema#223 Add Ubuntu ecosystem ossf/osv-schema#219)
  • We review the records you start publishing for OSV Schema correctness and quality (the work happening under the OSV Data Quality Program is also relevant here, as an FYI) as part of reviewing and merging that PR
• Create a PR to extend purl_helpers.py (if appropriate)
• Create a PR to start importing the records you are publishing into our test instance of OSV.dev and validate everything is working as intended there (worked example: Add Wolfi feed to test. google/osv.dev#2086)
• Create a PR to start importing the records you are publishing into our production environment (worked example: Add the Ubuntu OSV data source to production google/osv.dev#2105)

Known onboarding rough edges:

• the format of the source{,_test}.yaml files (hopefully the example PRs plus other existing entries will make this reasonably self-evident). Specifically, FYI, the value for type corresponds with those defined at https://github.com/google/osv.dev/blob/381f459de12e181447731beee9ba4b06a513c586/osv/models.py#L783-L787

We're here to help

If you have any questions, please feel free to reach out. If you'd like to discuss interactively, the best preexisting place to catch us is in the OpenSSF Vulnerability Disclosures Working Group monthly call

[tegioz]

Hi @taraspos @andrewpollock 👋

Before moving forward, I'd like to check with you if the data in the security reports Artifact Hub collects would actually be useful to OSV. Let me share some thoughts (and challenges we've encountered 😅) with you to see what you think 🙂.

• Artifact Hub generates security reports for many of the packages published on it using Trivy, which relies on many of the same vulnerabilities databases as OSV. Those security reports are nicely displayed in the UI, organized by targets, to make it easier for users to visualize them. But we don't produce our own vulnerabilities, neither AH publishers can produce them in AH (like they could do in GitHub by creating a security advisory).

• Artifact Hub supports multiple kinds of packages, but I'm not really sure if the AH package concept fits into the "minimum package-level precision" mentioned in the data quality document you shared. Let's take a Helm chart as an example of a package. A Helm chart may reference a few container images. Each container image may use a different base OS, can have installed a number of OS packages on it, plus any additional software added on top of that (i.e. the final application). This means that a single package in Artifact Hub may include vulnerabilities from multiple OS and lots of packages, which sometimes leads to have a large number of them.

• The previous point takes us to another problem (also mentioned in the data quality document): claiming that a vulnerability affects the software described. Unfortunately we cannot tell which, or if any, of the reported vulnerabilities may end up affecting an application deployed from a Helm chart. Some of the vulnerabilities found in the base OS or any of the packages installed may not have any impact on the final application (i.e. a library that's not used at all). Sometimes Artifact Hub publishers opt for disabling the security scanner in their repositories, or whitelisting some of their images, if they feel the security report can be misleading for their users.

• To complicate things a bit more, Helm charts don't provide a mechanism to define the images that a chart may use, so we do our best to try to extract them automatically (but in a way that isn't always accurate). On top of this, the images used in the end will depend on the configuration provided to the Helm chart. A chart may offer an option to enable collecting some metrics using Prometheus, for example, which may mean that another container image will be used. But vulnerabilities on that image would only be relevant to users when that feature is used.

There are some other points worth mentioning as well, but I think I'm extending too much 😅

I thought OSV was more focused on collecting vulnerabilities at a lower level, vulnerabilities in the building blocks, instead of in wide aggregations made by another tool. But if you find value in the information we're collecting for your use case we'd be happy to work with you and make it happen 🙂

[taraspos]

Hi @tegioz!

Thanks for your reply. All the points you've raised make sense. I'd be interested to hear @andrewpollock's opinion on this topic.

I thought OSV was more focused on collecting vulnerabilities at a lower level, vulnerabilities in the building blocks, instead of in broad collections made by another tool. But if you find value in the information we're collecting for your use case we'd be happy to work with you and make it happen

In my case, aggregated data is exactly what I miss in the OSV database, and that's what Artifact Hub provides and does well. While UI ArtifactHub provides is great, my main use case is that I want Renovate Bot to be able to tell me if upgrading certain container images and helm charts fixes certain vulnerabilities (and then potentially group updates by priority, etc). Renovate bot is already integrated with OSV¹² and can fetch vulnerability data for certain package types, but not container images or helm charts.

If we find that integrating ArtifactHub with OSV is not the right direction, we should then think about integrating Renovate Bot with ArtifactHub directly. (cc @rarkins @viceice)

Footnotes

1. https://docs.renovatebot.com/configuration-options/#osvvulnerabilityalerts ↩

2. https://github.com/renovatebot/renovate/discussions/20542 ↩

[andrewpollock]

I thought OSV was more focused on collecting vulnerabilities at a lower level, vulnerabilities in the building blocks, instead of in wide aggregations made by another tool. But if you find value in the information we're collecting for your use case we'd be happy to work with you and make it happen 🙂

We are very interested in facilitating container image scanning, so having vulnerability data for higher level components is also valuable. For example, we have most popular Linux distributions, which makes vulnerability detection in those packages, which may be present in a container image, possible.