Support patched versions in affected[].ranges[]

[alowayed]

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 #31 (comment) 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]

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?

[alowayed]

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?

It is. The concrete issue we're facing is as follows:

1. Corporation Z uses the OSV schema and public data to power vulnerability scanning.

   Specifically, corporation Z maintain a mirror of OSV's vuln data. Let's say it's the all.zip file from the GCS data dump.

2. An open source package Foo is used within corporation Z.

3. OSV public vuln data shows that Foo versions [0, 2.0] are affected by CVE-123

   {
      id: "CVE-123",
      affected: [
         {
            package: {
               name: "Foo",
               ecosystem: "Some-Ecosystem"
            }
         },
         ranges: [
            {
               type: "ECOSYSTEM",
               events: [
                  {
                     introduced: "0"
                  },
                  {
                     last_affected: "2.0"
                  }
               ]
            }
         ]
      ]
   }
   

4. Corporation Z fork the open source package and create version 1.0+patched which fixes CVE-123

5. Corporation Z want to represent this patched version within their internal vulnerability data. Something like this could work:

   {
      id: "CVE-123",
      affected: [
         {
            package: {
               name: "Foo",
               ecosystem: "Some-Ecosystem"
            }
         },
         ranges: [
            {
               type: "ECOSYSTEM",
               events: [
                  {
                     introduced: "0"
                  },
                  {
                     patched: "1.0+patched"
                  },
                  {
                     last_affected: "2.0"
                  }
               ]
            }
         ]
      ]
   }
   

   This would allow them to represent that the internal patch is not vulnerable within the raw data. Right now, this is done outside of the data layer.

It's not linear, which is the annoying part. This is essentially a fork off the main version line:

            -> 1.0+patched
          /
0.0 -> 1.0 -> 2.0

[alowayed]

After some offline discussion with @oliverchang , using VEX might be a better approach than changing the OSV schema. Specifically, using a VEX statement that says something like:

{
  "statements": [
    {
      "vulnerability": {
        "name": "CVE-1337"
      },
      "products": [
        {"@id": "pkg:pypi/[email protected]+patched"},
      ],
      "status": "fixed"
    }
  ]
}

Then updating our internal scanning to account for these VEX statement as a second step of vulnerability scanning after comparing against the public data.

Marking this as closed since there are no actionables on the OSV side. Appreciate the discussion :)