Proposed evolution of the vulnerability schema for discussion #44
Conversation
* More prescriptive definition for advisories * Support multiple sources for each vulnerability * Allow ratings to have a named source
Also makes the score object more precise, to match CVSS
|
@garethr Do you already have an example JSON file for this you can share? |
|
@coderpatros Yes, I'd linked in the original thread and not here. Here's a simple example https://gist.github.com/garethr/b069d9bf84ca80635cd506e74c8e2247 |
|
@stevespringett do you see any blockers here? |
|
No, I don't see any blockers here. I think there's some good ideas in here, but would like to see side-by-side examples of what can be done with 1.0 vs 2.0. Looking at the schema, I see there's a bit more flexibility in some regards, like having multiple sources for a vulnerability. |
|
+1 on more examples. Do you have a batch of v1.0 examples? I'd be happy to port those for comparison. I think the other question is, are there other backwards incompatible changes that would be good to make now for a major? |
| { | ||
| "type": "object", | ||
| "title": "Score", | ||
| "description": "Defines the numerical risk score of a vulnerability", |
There was a problem hiding this comment.
You mentioned in your FOSDEM talk that you wanted to support more than CVSS, but is this not exactly CVSS scoring?
There was a problem hiding this comment.
See the addition of "oneOf" above and the number type https://github.com/CycloneDX/specification/pull/44/files#diff-da04b5360b00e6b44767824827b36a44cf40f651723db0db12d1e70ea8e353a6R68
This means cores are either a CVSS score, or a number. This might want to be broader still. Collecting examples of simple and complex scores would be useful.
There was a problem hiding this comment.
I'm not sure what CVSSv4 will bring, and even if we'll continue to have base, impact, and exploitability scores. But the interesting thing is, this information is actually redundant. The scoring type is specific and if the vector is also specified, the scores can be recomputed. We can likely simplify this to a single score. This is what I'm planning to do with v1.4
| "vector": { | ||
| "type": "string", | ||
| "title": "Vector", | ||
| "description": "Textual representation of the metric values used to score the vulnerability see attack vector in https://www.first.org/cvss/v3.1/specification-document" |
There was a problem hiding this comment.
Are you not assuming then that all rating systems use CVSS and a vector?
There was a problem hiding this comment.
None of these are required fields, which is a bit of a design decision with CycloneDX I feel based on some of the questions I asked previously. So ratings here can be any of these individually or together.
|
@garethr Due to the extensibility issues with JSON, we will be moving the vulnerability extension into the core spec. This is scheduled for v1.4 which is already in progress. I'd love to get your feedback on it when a proposal is available. I'll take into consideration the design elements you've included in this PR. |
| "type": "string", | ||
| "title": "ID", | ||
| "description": "The id of the vulnerability as defined by the risk scoring methodology. For example CVE-2019-15842 (of https://nvd.nist.gov/vuln/detail/CVE-2019-15842)" | ||
| }, |
There was a problem hiding this comment.
@garethr I'm curious why you have a single ID, but have multiple sources. Wouldn't each source potentially have its own ID?
CVE-xxxx-xxxx
aka
SNYK-xxxxxxxxx
aka
SONATYPE-xxxxxxxx
There was a problem hiding this comment.
Also, wouldn't it be possible that each source could potentially have slightly different ratings as well? I'm thinking of VulnDB for example which makes a ton of corrections and enhancements to the NVD and its not uncommon for them to provide both the NVD scores as well as their own.
Are you trying to capture the ability to specify that a vulnerability will be known by different names across different sources?
|
Closing as vulnerability support has been greatly expanded and incorporated into the core spec - thus available for JSON and Protobuf. See #91 |
WIP based on discussions in #38
I've started with the JSON Schema just to iterate on ideas and get feedback. Would update examples and XSD and other parts before moving out of draft.