search

ossf / osv-schema

Open Source Vulnerability schema.
https://ossf.github.io/osv-schema/
Apache License 2.0
187 stars 85 forks source link

Support patched versions in affected[].ranges[] #318

Open alowayed opened 1 day ago

alowayed commented 1 day ago

Problem

There doesn't seem to be a way to mark a single version as unaffected without knowing the previous or next version. For example, if package foo is vulnerable to CVE-123 between the ranges [0, 2.0]:

{"introduced": "0"},
{"fixed": "2.0"}

It's hard to mark some patched version 1.0+patched as unaffected. One could do:

{"introduced": "0"},
{"fixed": "1.2.3+patched"},
{"introduced": "1.2.4"},
{"fixed": "2.0"}

But this runs the risk of 1.2.3+unpatched not being reported as vulnerable because:

{"fixed": "1.2.3+patched"} < `1.2.3+unpatched` < {"introduced": "1.2.4"}

Prior Arts

Solutions for this have been touched on in #75, #35 and https://github.com/ossf/osv-schema/issues/31#issuecomment-1036266822 by introducing a first_not_affected / versionStartExcluding field to describe the > operator.

This would address the problem by allowing:

{"introduced": "0"},
{"first_not_affected": "1.2.3+patched"},
{"fixed": "2.0"}

to represent that only 1.2.3+patched, if I'm understanding it correctly. I'm not attached to this for the multiple reasons mentioned in the other issues against a > operator. So another approach would be to enumerate these unaffected version similar to how affected versions can be enumerated: https://ossf.github.io/osv-schema/#affectedversions-field. I'm wary of the confusion this might cause in how to reconcile these unaffected versions with the affected ranges, so it's not a great approach either.

Use Case

This problem is arising outside the open source community. Specifically with users that maintain proprietary patches to public packages and use OSV tooling.

andrewpollock commented 1 day ago

without knowing the previous or next version

I think this is the crucial part of this that I'd like to explore further.

There's an expectation that versions are linear.

introduced may be unknown, in which case 0 is used, to mean everything prior to fixed or last_affected should be considered vulnerable

This issue discusses the need to assert that a particular version is not vulnerable, so that version should appear as fixed.

Are you saying that there are then versions after the fixed version that should still be considered to be vulnerable? I think this is counter to the expectation that versions (or ranges) are linear?