-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ensure that distro advisories and aliasing work well together #249
Comments
Thanks for opening this! As #193 points out, With Linux distributions, we're consuming upstream software components and packaging them into our own distinct downstream software components. So if Linux distributions provide OSV records to describe the affect of the vulnerability on their own packages, they cannot use So there's no good option for linux distributions to use to store machine-discoverable links to upstream vulnerabilities. I suggest adding a new field that's a stronger link than implied in To illustrate how this would work, imagine an OSV record from a Linux distribution like this: {
"modified": "2024-03-12T08:12:10Z",
"id": "CGA-pc4f-g53c-c4gq",
"upstream": [
"GHSA-rr6r-cfgf-gc6h"
],
// ... This would have the following ideal outcomes:
|
My initial reactive thought was |
Thank you for the feedback! One of the reasons we went with a more catch-all "related" was it was hard to encapsulate all the different use cases/relationships between vulnerability records. Additionally, having all of these very similar but subtly different fields may complicate and make the schema difficult to understand. That said, if there is a clear, machine-automation use case for a field such as |
👍 These names all sound good to me. And FWIW, I think
This definitely makes sense. I wouldn't want to open the door to N more relationship types each getting their own field, and then it becomes impossible to give guidance on which type is the exact right one for each scenario. One of my favorite traits of the OSV schema is its simplicity, and I hesitate to suggest adding a new field; but I'm just not sure how else to solve this for participants outside of the "language ecosystems" category.
Exactly this! OSV's So, Linux distributions want to be a part of that! ...without causing disruptions to the alias set itself. Speaking on behalf of Wolfi, it would be great for us to be able to weigh on on how a given vulnerability — expressed as another OSV record like This enables security tools to use the distro OSV data for matching, and then other OSV records to do other useful things, like provide users with more context about the vulnerability itself and cross-check the distro's findings with upstream findings. Zooming out, this also makes it easier for general consumers of the OSV database to see how different distros have handled a given vulnerability (it gets very interesting to compare notes like this during triaging!). |
Raised @luhring in google/osv.dev#2374 and capturing here:
The text was updated successfully, but these errors were encountered: