Not applying Alpine secdb data correctly for "edge"

[luhring]

Summary

Grype does not handle apk matching correctly for "edge" versions of Alpine.

When scanning a container image that uses an "edge" version of Alpine (i.e. a version beyond the last official release), Grype does not apply any secdb fixes to its matching (when it should apply fixes from the "edge" secdb data, that is, from https://secdb.alpinelinux.org/edge/).

This behavior results in false positives.

Example

We can look at the alpine:edge image on Docker Hub. Here's the distro information from Syft:

$ syft -q registry:alpine:edge -o json | jq '.distro'
{
  "prettyName": "Alpine Linux edge",
  "name": "Alpine Linux",
  "id": "alpine",
  "versionID": "3.17_alpha20220715",
  "homeURL": "https://alpinelinux.org/",
  "bugReportURL": "https://gitlab.alpinelinux.org/alpine/aports/-/issues"
}

We know this image uses an "edge" version of Alpine, because the latest release of Alpine (today) is 3.16, yet this image is using 3.17_alpha20220715.

Here's what Grype reports for this image:

$ grype -q registry:alpine:edge
NAME        INSTALLED   FIXED-IN  TYPE  VULNERABILITY   SEVERITY
busybox     1.35.0-r18            apk   CVE-2022-28391  High
ssl_client  1.35.0-r18            apk   CVE-2022-28391  High
zlib        1.2.12-r1             apk   CVE-2022-37434  Critical
zlib        1.2.12-r1             apk   CVE-2018-25032  High

For this example we'll look at the first reported vulnerability, busybox being affected by CVE-2022-28391 (although you can follow these steps for the fourth reported vulnerability (CVE-2018-25032), too).

We can look up the secfixes data for busybox:

$ curl -s https://secdb.alpinelinux.org/edge/main.json | jq '.packages[] | select(.pkg.name == "busybox")'
...
      "1.35.0-r7": [
        "ALPINE-13661",
        "CVE-2022-28391"
      ]
...

This shows that for busybox, the vulnerability CVE-2022-28391 was resolved as of 1.35.0-r7. The version of busybox installed in the image is 1.35.0-r18, which is beyond the fix version and this not affected by CVE-2022-28391, but it's still showing up in Grype's output.

Feel free to ping me if you have any questions!

[spiffcs]

I did some work this morning on this issue and found that after updating to match against the edge feed there are some new dragons here.

New vulnerability list from grype when matching against the edge data

NAME          INSTALLED  FIXED-IN   TYPE  VULNERABILITY   SEVERITY
libcrypto1.1  1.1.1q-r0  3.0.3-r0   apk   CVE-2022-1473   High
libcrypto1.1  1.1.1q-r0  3.0.6-r0   apk   CVE-2022-3358   High
libcrypto1.1  1.1.1q-r0  3.0.3-r0   apk   CVE-2022-1434   Medium
libcrypto1.1  1.1.1q-r0  3.0.5-r0   apk   CVE-2022-2097   Medium
libcrypto1.1  1.1.1q-r0  3.0.2-r0   apk   CVE-2022-0778   High
libcrypto1.1  1.1.1q-r0  3.0.3-r0   apk   CVE-2022-1343   Medium
libcrypto1.1  1.1.1q-r0  3.0.1-r0   apk   CVE-2021-4044   High
libssl1.1     1.1.1q-r0  3.0.1-r0   apk   CVE-2021-4044   High
libssl1.1     1.1.1q-r0  3.0.3-r0   apk   CVE-2022-1434   Medium
libssl1.1     1.1.1q-r0  3.0.3-r0   apk   CVE-2022-1473   High
libssl1.1     1.1.1q-r0  3.0.6-r0   apk   CVE-2022-3358   High
libssl1.1     1.1.1q-r0  3.0.2-r0   apk   CVE-2022-0778   High
libssl1.1     1.1.1q-r0  3.0.3-r0   apk   CVE-2022-1343   Medium
libssl1.1     1.1.1q-r0  3.0.5-r0   apk   CVE-2022-2097   Medium
zlib          1.2.12-r1  1.2.12-r2  apk   CVE-2022-37434  Critical

@luhring it looks like packages like libcrypto1.1 are derivatives of openssl1.1
https://pkgs.alpinelinux.org/package/edge/main/x86/libcrypto1.1#
pinned at commit cfbbe2c099a742aa856f0a2960ee927bd18e94cd

Since it's a smaller slice of the library and cut from < 3.0.0 we're matching against the WHOLE of upstream openssl.

Do you know if packages like libcrypto1.1 or libssl1.1 have any annotation data somewhere that would say something like:

"Yes, we are cut from openssl at comitt=xxxxx, BUT CVE-xxx does not apply since we don't import the (cypher, library, etc) that would the reported vulnerability apply"

On the positive side the other FP have gone away and I believe the final zlib entry to be a True Positive

zlib          1.2.12-r1  1.2.12-r2  apk   CVE-2022-37434  Critical

[spiffcs]

Looking more at this it might also be that syft is getting the upstream wrong here
openssl vs openssl1.1-compat

Let me see if we can update these packages to use the more precise upstream to show how that affects the data

[spiffcs]

When parsing the DB entry in syft for libcrypto1.1 on alpine:edge I see:

C:Q1zUKUHoVTQsk0LZwMYMB55/5cWm0=
P:libcrypto1.1
V:1.1.1q-r0
A:x86_64
S:1210788
I:2764800
T:Crypto library from openssl
U:https://www.openssl.org/
L:OpenSSL
o:openssl <--------------------
........

I think this should be updated to openssl1.1-compact (also updated for libssl1.1)

This will narrow the surface area of the edge feed so we can match it against the correct upstream package the libraries were cut from:

Here is an example of the results where this upstream data has been fixed and is openssl1.1-compact instead of openssl

 ✔ Vulnerability DB        [no update available]
 ✔ Parsed image            
 ✔ Cataloged packages      [14 packages]
 ✔ Scanned image           [2 vulnerabilities]
NAME  INSTALLED  FIXED-IN   TYPE  VULNERABILITY   SEVERITY 
zlib  1.2.12-r1  1.2.12-r2  apk   CVE-2022-37434  Critical  

[spiffcs]

This is interesting:

• https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/openssl/APKBUILD <--- This derives libcrypto and libssl, but from:

pkgname=openssl
pkgver=3.0.5

• https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/main/openssl1.1-compat/APKBUILD <--- This also derives libcrypto and libssl

pkgname=openssl1.1-compat
pkgver=1.1.1q

When I go to https://pkgs.alpinelinux.org/package/edge/main/x86/libcrypto1.1# I see it's derived from openssl1.1-compat so I'm thinking I need to learn a bit more about where that o: - origin (corresponds to origin in PKGINFO), optional field is being set in edge so I can make the correct patch so go from o: openssl => o:openssl1.1-compact to remove these FP.

[luhring]

@spiffcs @wagoodman I think this can maybe be simplified a bit.

I've gotten clarification that official releases of Alpine always have three digits -> x.y.z. If you find a version ID value with literally anything else, it's edge. Always.

This means there's no need to look specifically for "alpha", or other version format variations, or an empty string, etc.

I know there's a related problem (but distinct from this bug report) where the distro version isn't making it into Grype when the version can't be parsed by hashiVer. As I understand the situation, we can defer solving that, because that results an empty string, which should be recognized as edge because it's not x.y.z. In the future when that other bug is fixed, edge would continue to be used (correctly) because the version value would be something like 3.17_alpha20220715, which again is not x.y.z.

Re: upstream/origin matching, I'm not sure what's going on there, but I'm assuming that's a separate problem from the idea of using edge secfixes. Let me know if I've misunderstood here!