Closed zacchiro closed 7 months ago
Thanks for the question!
limit
came about due to feedback from some of our data providers. For instance, the https://github.com/cloudsecurityalliance/gsd-database folks wanted to issue separate OSV entries for each affected branch of a particular Linux vulnerability.
More generally, I do agree we should encourage more use of fixed
. The challenge here comes from the fact that while false negatives are bad, users of vulnerability scanners are already grappling with floods of potential false positives in their reports for various reasons, and we don't want to make that particular problem worse either.
limit
came about due to feedback from some of our data providers. For instance, the https://github.com/cloudsecurityalliance/gsd-database folks wanted to issue separate OSV entries for each affected branch of a particular Linux vulnerability.More generally, I do agree we should encourage more use of
fixed
. The challenge here comes from the fact that while false negatives are bad, users of vulnerability scanners are already grappling with floods of potential false positives in their reports for various reasons, and we don't want to make that particular problem worse either.
I see, thanks for this information. If you have references to the specific cases of gsd-database where vulnerabilities where branch-specific, I'd love to look into them, because they seem really weird to me.
Great that you agree that fixed
should be used more (than limit
), as the data in the OSV.dev seems to be going in a different direction.
If welcome, I can prepare and submit a (small) PR for the spec, with a recommendation that goes in this direction.
Thanks again @zacchiro for contributing https://github.com/ossf/osv-schema/pull/221. Would you consider this issue resolved?
Yeah, sounds good, thanks. Closing.
Hello, the semantics of limit events in the spec is very clear, but the logic behind it, and hence how to use it correctly in the real world, way less so. I haven't found it documented anywhere, so I'm asking here in the hope the answer will be useful to others as well.
Consider the canonical example in the specification, where![git_graph](https://github.com/ossf/osv-schema/assets/216766/48b4df90-205a-47d9-8c2c-14abc6f4886a)
limit
is used instead offixed
in the following git history:A security bug is introduced in commit X and resolved in commit Y. How could it be possible that commits D, E, and F (letting cherry picks aside) are not vulnerable? Any change made in those commits might also fix the vulnerability as a side effect, but the most common case I can imagine in the real world is that those commits are vulnerable.
Encouraging the use of
limit
overfixed
for git range optimizes for the least plausible case, making spec implementations return false negatives, which seems undesirable (because dangerous).For what is worth, this is not marginal in the OSV.dev data: more than half of git ranges there use
limit
events instead offixed
. Should they befixed
instead (aside from a few marginal cases), and should the spec strongly encourage favoringfixed
overlimit
?Thanks for this great project!