Grype doesn't detect CVE-2023-21930 on an Alpine 3.17 Docker image

[dbrugman]

What happened:
While scanning a Docker image based on Alpine 3.17 with OpenJDK (apk) version 11.0.18_p10-r0 installed, Grype did not detect CVE-2023-21930, which affects all versions < 1.0.19_p7-r0.

The following APK packages are installed:
openjdk11-jre, version:11.0.18_p10-r0
openjdk11-jre-headless:11.0.18_p10-r0

I ran Grype as follows: grype --by-cve <alpine 3.17 image with openjdk 11.0.18 installed>

What you expected to happen:
I would expect that CVE-2023-21930 gets detected since OpenJDK 11.0.18 is affected

How to reproduce it (as minimally and precisely as possible):
grype --by-cve <alpine 3.17 image with openjdk 11.0.18 installed> | grep 'CVE-2023-21930'

Anything else we need to know?:
I looked in the Grype DB (vulnerability-db_v5_2023-05-12T01:31:37Z_73cf586defd28f955838.tar.gz), and noticed that the package name for CVE-2023-21930 on alpine:3.17 is called 'openjdk11', while the installed packages are called 'openjdk11-jre' and 'openjdk11-jre-headless'. So I suspect that it doesn't get detected because the package name doesn't match.

Environment:

• Output of grype version:
  Application: grype
  Version: 0.61.1
  Syft Version: v0.79.0
  BuildDate: 2023-04-21T17:11:07Z
  GitCommit: 3caabc8
  GitDescription: v0.61.1
  Platform: linux/amd64
  GoVersion: go1.19.8
  Compiler: gc
  Supported DB Schema: 5
• OS (e.g: cat /etc/os-release or similar):
  NAME="Ubuntu"
  VERSION="20.04.6 LTS (Focal Fossa)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu 20.04.6 LTS"
  VERSION_ID="20.04"
  HOME_URL="https://www.ubuntu.com/"
  SUPPORT_URL="https://help.ubuntu.com/"
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
  PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
  VERSION_CODENAME=focal
  UBUNTU_CODENAME=focal

[westonsteimel]

Thanks @dbrugman . So in this case there is a typo upstream in the alpine secfixes db for 3.17. They have the fixed in version for openjdk11 as 1.0.19_p7-r0 rather than 11.0.19_p7-r0

[westonsteimel]

I think their source for that is somewhere in GitLab, but will have to try and find it again to see if we can issue a correction

[westonsteimel]

I think maybe it is this line that would need to be changed, though I am not completely certain if they still generate the fix db from that source

[dbrugman]

@westonsteimel - thanks a lot, and it seems you're right. I overlooked the fixed version number, I read it as 11.0.19_p7-r0, even though it's indeed 1.0.19_p7-r0 in the DB file. I don't know where this information is sourced from, but the file / line you linked seems a likely candidate

[dbrugman]

@westonsteimel - I've raised this as an issue on the Alpine aports project:

https://gitlab.alpinelinux.org/alpine/aports/-/issues/14919

But - to your point - I don't know if fixing it in that file will cause existing DB entries to get updated

[westonsteimel]

Thanks, based on my reading of https://security.alpinelinux.org/, I believe that updating the aports file should cause the secdb json file that we consume for building the grype-db to be rebuilt with the correct info

[westonsteimel]

@dbrugman , https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/47113 got merged, so it should regenerate the alpine fixdb within a day, so hopefully the grypedb for tomorrow will contain the corrected data

[dbrugman]

Great! Many thanks for this @westonsteimel !

[westonsteimel]

The alpine fix db rebuilt quickly, so we have just published a new grype db with the fixed information. You should be able to do a grype db update to get the latest version with checksum sha256:22f47d2077e44652d9c155e98d1b7979089ac4de7bb9974eb458edfd80b8855a now. Thanks again for the report!

[dbrugman]

@westonsteimel - I just checked: it indeed gets detected now! Thanks again for the quick response!