OSV and Custom Fixes to Open Source Packages

[Indermeet Gandhi]

Hi OSV Team,

 

I came across the group’s details while looking for contacts at OSV. I'm a Product Manager at Lineaje, and we've developed a solution called Gold Open Source. It focuses on securing open-source projects by addressing vulnerabilities that haven't been fixed yet and enabling backporting for older versions.

 

Part of this work involves ensuring that our fixes for these vulnerabilities are recognized by other security scanners like Snyk or Grype. This way, users won't encounter false positives when scanning packages that include fixes we've implemented through Lineaje's versioned packages .

 

One approach we're considering is publishing these fixed versions through OSV as security advisories. Would you happen to know if this is a viable way to achieve our goal? If so, could you share any guidance on how we could move forward with this?

 

Thanks,

Inder

[Jason Shepherd]

Hi Inder,

If I understand this product correctly it is forking vulnerable open
source libraries, patching them and releasing fixed versions? If that
is the case, the package location and other particulars such as the
Package URL are likely to different to the open source library being
patched. I'm not sure how the OSV project would handle such a case,
although if you had some sort of unique identifier for the Gold fix,
perhaps it could be incorporated as an external reference of some
sort.

Are the patched versions available for anyone in the open source
community to use? Is the community able to utilize a git patch itself
to patch its own version of the library? I think these are things we
would consider before including any form of external reference in the
OSV records.

Regards,
Jason Shepherd

> --
> You received this message because you are subscribed to the Google Groups "osv-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to osv-discuss...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/osv-discuss/BY1P220MB2013FCBEBE1B36278118199AB16CA%40BY1P220MB2013.NAMP220.PROD.OUTLOOK.COM.

[Oliver Chang]

Even aside from the question on if the patches are publicly available, I wonder if OSV is the wrong place for this kind of thing. To me it feels like VEX is a better place for expressing private patches. i.e. along with the registry mirror to provide the patched versions of packages, publish a VEX feed to encode private patches for CVEs.

For example, say there's a package foo at version 1.0.0 vulnerable to CVE-1337, which has a fix in 2.0.0:

{
  "id": "CVE-1337",
  "affected": [
     {
        "package": {"name": "foo", "ecosystem": "PyPI"},
        "ranges": [
          {"type": "ECOSYSTEM", "events": [{"introduced": "0"}, {"fixed": "2.0.0"}]}
         ]
     }
  ]
}

Someone (e.g. Gold Open Source) comes in and patches this for 1.x, releasing 1.0.0+patched, along with a VEX statement saying 1.0.0+patched specifically isn't impacted by CVE-1337 (using OpenVEX as an example format):

{
  "statements": [
    {
      "vulnerability": {
        "name": "CVE-1337"
      },
      "products": [
        {"@id": "pkg:pypi/f...@1.0.0+patched-by-gold"},
      ],
      "status": "fixed"
    }
  ]
}

If a user's project has 1.0.0+patched-by-gold, the matching process would look like:
1) 1.0.0+patched-by-gold is vulnerable according to the upstream CVE-1337 advisory because it's <2.0.0
2) However, we also take into account the VEX statement, which says that 1.0.0+patched-by-gold isn't affected, so we don't consider this a real match.

This has the added benefit of not having to duplicate existing upstream vulnerability feeds and shoving in patched versions, which might introduce other conflicts. The VEX feed would essentially be an override layer on top of scanning against the upstream vulnerability feed. 

--

Oliver

To view this discussion visit https://groups.google.com/d/msgid/osv-discuss/CAJ8bJ-Tb%3D7bMWW3AytmwGTpqmKiXUECd2knVziR6EeSbtTbb4A%40mail.gmail.com.