Document the properties of a high quality OSV record #2193
Conversation
andrewpollock
force-pushed
the
document_quality_bar
branch
from
e64bb03
to
12cd78b
Compare
Co-authored-by: Jon <darakian@github.com>
Feedback was that it was possible to perceive this as known unfixed vulnerabilities as being of lower quality than ones with known/available fixes, and that is not the case, as such known unfixed vulnerabilities can and do legitimately exist (as is the case when the vulnerable package is orphaned). These are a legitimate true positive with no available fixed version.
Co-authored-by: Chris Bloom <chrisbloom7@github.com>
Co-authored-by: Chris Bloom <chrisbloom7@github.com>
Co-authored-by: Chris Bloom <chrisbloom7@github.com>
Co-authored-by: Chris Bloom <chrisbloom7@github.com>
Co-authored-by: Chris Bloom <chrisbloom7@github.com>
Co-authored-by: Chris Bloom <chrisbloom7@github.com>
Co-authored-by: Chris Bloom <chrisbloom7@github.com>
Co-authored-by: Chris Bloom <chrisbloom7@github.com>
Co-authored-by: Chris Bloom <chrisbloom7@github.com>
Reviewer feedback.
…ev into document_quality_bar
"Managing the Perishability of OSV Records" is in the early ideation phase.
Co-authored-by: Jon <darakian@github.com>
Feedback was that it was possible to perceive this as known unfixed vulnerabilities as being of lower quality than ones with known/available fixes, and that is not the case, as such known unfixed vulnerabilities can and do legitimately exist (as is the case when the vulnerable package is orphaned). These are a legitimate true positive with no available fixed version.
Reviewer feedback.
Co-authored-by: Chris Bloom <chrisbloom7@github.com>
Co-authored-by: Chris Bloom <chrisbloom7@github.com>
Co-authored-by: Chris Bloom <chrisbloom7@github.com>
Co-authored-by: Chris Bloom <chrisbloom7@github.com>
Co-authored-by: Chris Bloom <chrisbloom7@github.com>
Co-authored-by: Chris Bloom <chrisbloom7@github.com>
Co-authored-by: Chris Bloom <chrisbloom7@github.com>
Co-authored-by: Chris Bloom <chrisbloom7@github.com>
Co-authored-by: Chris Bloom <chrisbloom7@github.com>
"Managing the Perishability of OSV Records" is in the early ideation phase.
I realised I'd omitted the `events[]` array in the JSON path when talking about `introduced` and `fixed`/`last_affected`. Explicitly refer to commits *and* versions when discussing temporal ordering of `introduced` and `fixed`/`last_affected`.
…ev into document_quality_bar
Based on feedback from Duy Truong about Android's patching approach.
|
|
||
| ## Rationale | ||
|
|
||
| OSV.dev seeks to be a comprehensive, accurate and timely database of known vulnerabilities that is highly automation friendly. In order to meet this accuracy goal, a quality bar needs to be both defined and sustainably enforced. |
There was a problem hiding this comment.
We'll have to cross that bridge when we get to it, I think.
There was a problem hiding this comment.
Got it. As far as I understand it should be addressed in #2188 one way or another. Until then it would maybe make sense to mention that the quality bar isn't enforced yet. It should hopefully help to prevent treating all OSV entries as vulnerabilities. I'm 99% sure that bogus CVEs based on OSV data popped up because the OSV database was (and still is) advertised in a way that doesn't (always) match reality.
There was a problem hiding this comment.
I think this discussion is separate to the intention of this document here.
This document is meant to serve as a reference for how to properly structure and format an OSV record. It doesn't go into whether or not a record is worthy of being considered a vulnerability. That would be a separate discussion :)
There was a problem hiding this comment.
It doesn't go into whether or not a record is worthy of being considered a vulnerability
Currently the documentation says "It is also assumed that the vulnerability discussed in the OSV record is valid and affects the software described" and looking at #2193 (comment) I think it implies that OSV records are vulnerabilities.
Either way I agree that this discussion can be moved elsewhere. Just to clarify I think OSS-Fuzz is great and OSV is great. It's just that they don't interact well with each other yet and get misused from time to time by some organizations.
|
|
||
| ## Rationale | ||
|
|
||
| OSV.dev seeks to be a comprehensive, accurate and timely database of known vulnerabilities that is highly automation friendly. In order to meet this accuracy goal, a quality bar needs to be both defined and sustainably enforced. |
There was a problem hiding this comment.
I think this discussion is separate to the intention of this document here.
This document is meant to serve as a reference for how to properly structure and format an OSV record. It doesn't go into whether or not a record is worthy of being considered a vulnerability. That would be a separate discussion :)
https://github.com/google/osv.dev/actions/runs/9933115405/job/27435624106 causes a modification to go.work.sum which then breaks the workflow. Revert modification to go.work.sum
Reference from existing documentation on data.
Part of #2186