@another-rex I think the issue is maybe a bit more complicated, and something I've be aware of for a while but not brought up since it didn't seem to be a high priority.

The OSV spec says for the Alpine ecosystem:

The Alpine package ecosystem; the name is the name of the source package. The ecosystem string must have a :v suffix to scope the package to a particular Alpine release branch (the v prefix is required). E.g. v3.16.

My interpretation of that is the ecosystem string must always have a suffix, which seems to be the case for ecosystem fields but not the purl fields; though noting it could be that this is meant as an "if" kind of condition (i.e. "The ecosystem string must have a ... suffix if the package is to be scoped to ...") - that doesn't fix the problem outright but would change what/where the fix could be.

Assuming my current interpretation is correct if we use CVE-2022-48174 as an example, which is returned by the API when scanning fixtures/sbom-insecure/alpine.cdx.xml, the entry has the following affected[0].package:

"package": {
  "name": "busybox",
  "ecosystem": "Alpine:v3.18",
  "purl": "pkg:apk/alpine/busybox?arch=source"
},

and when we scan our test SBOM, we get the following PURL for the busybox package:

pkg:apk/alpine/busybox@1.35.0-r29?arch=x86_64&upstream=busybox&distro=alpine-3.17.2

When we're preparing the osv "query" for comparison, we build package details which favors the PURL if present; and in that case we use whatever ecosystem we're given from models.PURLToPackage, which in this case is just returning Alpine.

Later when determining if the package is affected by the osv, we only check against the ecosystem regardless of if there's a PURL and so we end up comparing Alpine to Alpine:v3.18.

I think this resolves around the importance of the suffix, and that's something I think ideally should be mentioned in the spec too i.e. it is safe enough to just ignore the suffix if you can't be confident in determining it on both sides of the comparison?

If the answer is yes, then that's what the scanner should do: whenever it compares a "suffixable" ecosystem, it should first compare the major ecosystem and (if that matches) it should compare the suffix if provided by both OSV and package

If the answer is no, then that should be required in the PURL - it seems like it should doable (though I don't know if it would be considered robust or acceptable) via the distro param; and then all advisories should be updated to include that in their PURL.

Missing vulnerabilities for debian purls for --experimental-local-db #769

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions