saveourtool / cosv4k

Kotlin and Java serialization schema for COSV
https://www.gitlink.org.cn/zone/CCF-ODC/source/7
MIT License
2 stars 0 forks source link

Duplicate fields #1

Open nulls opened 1 year ago

nulls commented 1 year ago

Some fields can be calculated or taken as is from OSV schema:

  1. severity[].level can be calculated from severity[].score -- https://www.balbix.com/insights/understanding-cvss-scores/#CVSS-Qualitative-Ratings-6
  2. severity[].score_num can be calculated from severity[].score -- https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator
  3. contributors[].name can be taken from credits[].name
  4. contributors[].email can be taken from credits[].contact[]
  5. patches_detail[].patch_url can be taken from references[] with type = FIX
  6. patches_detail[].issue_url can be taken from references[] with type = REPORT
  7. cwe_ids[] can be calculated from aliases[] with prefix CWE- cwe and cve are different: https://www.automox.com/blog/vulnerabilities-software-weaknesses-acronym-breakdown, but there is a mapping from CVE to CWE: https://nvd.nist.gov/vuln/detail/CVE-2023-29407 (for example)
nulls commented 1 year ago

@akuleshov7 please review

orchestr7 commented 1 year ago

@JustinB1eber

JustinB1eber commented 1 year ago
nulls commented 1 year ago

7 I didn't get the point, does it matter to add this field because there is already a mapping from CVE to CWE?

We have alias where can be specified mapping to CVE which already has mapping to CWE (like here https://nvd.nist.gov/vuln/detail/CVE-2023-29407).

But looks like it doesn't fit case when we create a new vulnerability which related to some CWE, but it's not alias to some existed CVE.

So please disregard point 7

nulls commented 1 year ago

1 and 2, we added it for convenience of displaying so my suggestion is not to remove it.

Having a field which can be calculated from another leads to additional validation on our side: if severity[].level is set, we should check that it's valid for provided severity[].score and the same for severity[].score_num.

Also, the JSON file is for communication between program (I don't think that human will read it), we can add additional calculated fields on UI only

nulls commented 1 year ago

for 3, 4, using the credits[] filed is good makes it more simplified, and there is a contributors[].contributions field, if we replace 3 and 4 by credits[], we should add a credit[].contributions

Will move then extra fields from contributors[] to credits[].

nulls commented 1 year ago

for 5 and 6 my opinion is we should keep them inside the patched_detail[], so that this filed a more complete object.

Agree, taking into account that we want to move patched_detail[] to range[]