Weston Steimel

@oliverchang, yes I definitely agree on not maintaining our own registry of identifiers if we can possibly avoid it. I think the idea of using the source repo path could...

Hmm, what about something specific for GitHub release artifacts? And maybe something general for source control URLs or just general URLs for published binaries?

@spiffcs , sorry I missed your comment and I had completely forgotten about this one. I think all that was missing is adding some jenkins plugins into the integration test...

Oh, we also need some unit tests for the package type logic (changing the type from being `java-archive` to being `jenkins-plugin`)

@di what do you think about getting these feeding into [PyPA Advisory Database](https://github.com/PyPA/advisory-db)? Then it would feed into OSV and anything else consuming those data sources. Of course it'd also...

I was hoping that the CSAF data would include the data about non-fixed and not affected packages so that we could drop having to also rely on the CVE api,...

It will also end up being more network calls for the CSAF data since each CSAF RHSA is stored as a separate json whereas the OVAL data was stored as...

> Or is the ask here just to make the severity-per-package available to grype-db, and then grype-db can fix its own schema later? Yes

I think adding a column to the vulnerability table in the current grype-db schema could be done without a breaking change, so we should get vunnel supporting it first and...

This isn't really an upstream issue, its just an issue on our end as we're swallowing all exceptions and shouldn't be. A failure to get data should result in the...