Support RedHat vulnerabilities

[fingeromer]

Currently OSV supports a few operating system ecosystems like Debian & Alpine.
We would like to open a feature request for supporting RedHat ecosystem vulnerabilities.

Thanks, have a nice day.

[fingeromer]

Hi, is adding RedHat datasource on your roadmap?

[github-actions]

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

[andrewpollock]

is adding RedHat datasource on your roadmap?

We're largely dependent on Red Hat to provide the data in the OSV format, conversations are ongoing...

/cc @mprpic

[mprpic]

The Red Hat ecosystem is large and varied so we're still working out the kinks on how to best structure the data in the OSV schema, but it's in progress! Since there is interest in this data, I'll ask here @fingeromer, are you mostly interested in data on vulnerabilities affecting RPMs shipped on RHEL? Or other Red Hat products as well?

[andrewpollock]

The onboarding process is a little bit bespoke and toilsome at the moment, but something we're continuously improving on and streamlining with each new data source onboarded. I would like to get it to the point of being much more checklist/cookbook driven than it currently is. My detailed response here is an (ongoing) experiment at further process improvement and seeks to address some recent actionable feedback received by another data source onboarding. Your actionable feedback is also very welcome.

In a nutshell:

• Decide if you're going to publish records via a Git repository, GCS bucket or REST endpoint (I'm going to assume a Git repository?)
• 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. #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 #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

  osv.dev/osv/models.py

  Lines 783 to 787 in 381f459

  	class SourceRepositoryType(enum.IntEnum):
  	"""SourceRepository type."""
  	GIT = 0
  	BUCKET = 1
  	REST_ENDPOINT = 2

[jasinner]

We going to publish the records at a new REST endpoint https://access.redhat.com/security/data/osv/

Add Red Hat Ecosystem in osv-schema repo.

[jasinner]

I guess we don't need to adjust purl_helpers because we include purls with our OSV records.

[andrewpollock]

I guess we don't need to adjust purl_helpers because we include purls with our OSV records.

Correct.

[jasinner]

Reserved an ecosystem prefix Red Hat

[mprpic]

Now available: https://openssf.org/blog/2024/11/01/red-hats-collaboration-with-the-openssf-and-osv-dev-yields-results-red-hat-security-data-now-available-in-the-osv-format/. I think this issue can be closed now :-)

[oliverchang]

Indeed! Thanks again @jasinner @mprpic for making this happen!