Skip to content
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

Duplicate fields #1

Open
nulls opened this issue Aug 14, 2023 · 7 comments
Open

Duplicate fields #1

nulls opened this issue Aug 14, 2023 · 7 comments

Comments

@nulls
Copy link
Member

nulls commented Aug 14, 2023

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
Copy link
Member Author

nulls commented Aug 14, 2023

@akuleshov7 please review

@orchestr7
Copy link
Member

@JustinB1eber

@JustinB1eber
Copy link

  • 1 and 2, we added it for convenience of displaying so my suggestion is not to remove it.
  • 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
  • for 5 and 6 my opinion is we should keep them inside the patched_detail[], so that this filed a more complete object.
  • 7 I didn't get the point, does it matter to add this field because there is already a mapping from CVE to CWE?

@nulls
Copy link
Member Author

nulls commented Aug 31, 2023

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
Copy link
Member Author

nulls commented Aug 31, 2023

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
Copy link
Member Author

nulls commented Aug 31, 2023

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
Copy link
Member Author

nulls commented Aug 31, 2023

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[]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants