GSD data format about gsd-tools

[kurtseifried]

I would like to see something like what I tried for CVE JSON where basically:

1. We had core required data defined (e.g. you MUST have the ID, affected, description, etc.), the expectation that any publisher MUST provide this and any consumer MUST support processing this
2. We have supported data that was defined (e.g. notes, etc), the expectation being that publishers CAN publish this and that consumers SHOULD support this
3. Everything else, Publishers CAN publish this, and consumers are free to support it or ignore it. Essentially this allows for experimentation and changes to happen

with the ultimate goal being "what defines a valid HTTP header? a lot of servers and clients decide to support it" style of data schema/definition (aka let the market decide).

[westonsteimel]

@joshbressers I was unable to access https://groups.google.com/access-error?continue=https://groups.google.com/a/groups.cloudsecurityalliance.org/g/uvi. Is it still active or is the discussion happening elsewhere? I'd definitely be interested in joining in and learning more about GSD in general. Thanks!

[westonsteimel]

Ah, sorry I found it https://groups.google.com/a/groups.cloudsecurityalliance.org/g/gsd

[joshbressers]

Thanks for catching this @westonsteimel

I edited my original comment with the proper URL

I'm sure there are other things we've missed in the great renaming, if you run across them please let me know

[joshbuker]

When it comes to vuln id formatting, we've settled on OSV. When it comes to some of the GSD specific aspects, such as namespacing and related policies, that has yet to be solidified.

[joshbuker]

See also #54, which will add an explicit schema for GSD IDs. (currently a WIP)

[joshbuker]

This is defined at: https://github.com/cloudsecurityalliance/gsd-tools/tree/main/gsd-schema

We can create new issues for updating the data format as needed.