Grype is not recognizing python-certifi is patched for GHSA-43fp-rhv2-5gv8

[ssullivan]

What happened:

Grype is detecting that I have an unpatched version of certifi when it is patched. I've seen Grype
report this error on multiple platforms and operating systems. The following logs were generated on a Windows 10 system.

What you expected to happen:

I expected the CVE to not show up in the Grype output.

How to reproduce it (as minimally and precisely as possible):

Test 1

I created a Dockerfile like the following

FROM python:3.10.10-alpine3.16
RUN python -m pip install certifi==2022.12.07

docker build . -t example:latest

$ grype example:latest
NAME         INSTALLED  FIXED-IN    TYPE    VULNERABILITY        SEVERITY
certifi      2022.12.7  2022.12.07  python  GHSA-43fp-rhv2-5gv8  Medium
libcom_err   1.46.5-r0  1.46.6-r0   apk     CVE-2022-1304        High
pip          22.3.1                 python  CVE-2018-20225       High
python       3.10.10                binary  CVE-2007-4559        Medium
python       3.10.10                binary  CVE-2023-24329       High
sqlite-libs  3.38.5-r0              apk     CVE-2022-46908       High

Test 2

I noticed that the python certifi library has defined their version as 2022.12.07 in their
init.py file here like this

from .core import contents, where

__all__ = ["contents", "where"]
__version__ = "2022.12.07"

I decided to create a new Dockerfile like the following to install from source since 2022.12.07 is not
on PYPI and the source repo has the version that Grype says the CVE is patched.

FROM python:3.10.10-alpine3.16
RUN apk add git && python -m pip install git+https://github.com/certifi/python-certifi.git

and got the following output

$ docker build --no-cache --progress=plain -t example:latest .
#1 [internal] load build definition from Dockerfile
#1 sha256:a1283ec5588a18bc133b0e663cbc731257a537d894c1aaaf511240b3a22cd841
#1 transferring dockerfile: 31B done
#1 DONE 0.0s

#2 [internal] load .dockerignore
#2 sha256:1b44120402eebbe7b7f8eaf90cde234cd91cac0b16b12f1a32807f069424c7f0
#2 transferring context: 2B done
#2 DONE 0.0s

#3 [internal] load metadata for docker.io/library/python:3.10.10-alpine3.16
#3 sha256:3dae8c984d13b25620e913f505daeecc9b7f89001a6520d45e9c90a33d32f584
#3 DONE 0.3s

#4 [1/2] FROM docker.io/library/python:3.10.10-alpine3.16@sha256:884085609a2da0054ebaf0392313cd7ceb8bee7d05ed28d5498f521d341a67be
#4 sha256:854495776086ef80cbaecb5f81f8f220d7d5927e863ab55b58d9adeddbceede8
#4 CACHED

#5 [2/2] RUN apk add git && python -m pip install git+https://github.com/certifi/python-certifi.git
#5 sha256:f90d4e421f4e34dea7ba93aed5e3b1a1aa03236354b4691b0694a3c39f88ccd8
#5 0.345 fetch https://dl-cdn.alpinelinux.org/alpine/v3.16/main/x86_64/APKINDEX.tar.gz
#5 0.655 fetch https://dl-cdn.alpinelinux.org/alpine/v3.16/community/x86_64/APKINDEX.tar.gz
#5 0.983 (1/5) Installing brotli-libs (1.0.9-r6)
#5 1.069 (2/5) Installing nghttp2-libs (1.47.0-r0)
#5 1.100 (3/5) Installing libcurl (7.83.1-r6)
#5 1.143 (4/5) Installing pcre2 (10.40-r0)
#5 1.197 (5/5) Installing git (2.36.5-r0)
#5 1.924 Executing busybox-1.35.0-r17.trigger
#5 1.929 OK: 27 MiB in 41 packages
#5 3.734 Collecting git+https://github.com/certifi/python-certifi.git
#5 3.735   Cloning https://github.com/certifi/python-certifi.git to /tmp/pip-req-build-4p2c1eu_
#5 3.737   Running command git clone --filter=blob:none --quiet https://github.com/certifi/python-certifi.git /tmp/pip-req-build-4p2c1eu_
#5 4.326   Resolved https://github.com/certifi/python-certifi.git to commit c211ef482a01aff5f1bc92c4128bfa0c955f4a01
#5 4.329   Preparing metadata (setup.py): started
#5 4.929   Preparing metadata (setup.py): finished with status 'done'
#5 4.933 Building wheels for collected packages: certifi
#5 4.934   Building wheel for certifi (setup.py): started
#5 5.315   Building wheel for certifi (setup.py): finished with status 'done'
#5 5.316   Created wheel for certifi: filename=certifi-2022.12.7-py3-none-any.whl size=154938 sha256=5e5cd4913cc7e69c445299fc327a1e0ea2b4649c170a47375acfd60f1efec896
#5 5.316   Stored in directory: /tmp/pip-ephem-wheel-cache-5ey10do0/wheels/e8/7f/5d/4cc89fdfdfc7500f2d9a4800a90d65fafb0a8a4fa25a5110b5
#5 5.323 Successfully built certifi
#5 5.369 Installing collected packages: certifi
#5 5.396 Successfully installed certifi-2022.12.7
#5 5.396 WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
#5 5.574
#5 5.574 [notice] A new release of pip available: 22.3.1 -> 23.0.1
#5 5.574 [notice] To update, run: pip install --upgrade pip
#5 DONE 5.7s

#6 exporting to image
#6 sha256:e8c613e07b0b7ff33893b694f7759a10d42e180f2b4dc349fb57dc6b71dcab00
#6 exporting layers
#6 exporting layers 0.2s done
#6 writing image sha256:d94d589283da632e530e437cfd5c1e948ae9c41f1616481dbcc92a9ca3dc8264 done
#6 naming to docker.io/library/example:latest done
#6 DONE 0.2s

pip is indicating that the version installed is

#5 5.396 Successfully installed certifi-2022.12.7

I believe this is because under the hood distutils is parsing the version and converting the 07 to 7

$ winpty python
Python 3.9.13 (tags/v3.9.13:6de2ca5, May 17 2022, 16:36:42) [MSC v.1929 64 bit (
AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from distutils.version import StrictVersion
>>> StrictVersion("2022.12.07")
StrictVersion ('2022.12.7')
>>>

Grype still says that the version of certifi has a CVE despite installing from source

$ grype example:latest
NAME         INSTALLED  FIXED-IN    TYPE    VULNERABILITY        SEVERITY
certifi      2022.12.7  2022.12.07  python  GHSA-43fp-rhv2-5gv8  Medium
git          2.36.5-r0              apk     CVE-2022-41953       High
git          2.36.5-r0              apk     CVE-2023-22743       High
libcom_err   1.46.5-r0  1.46.6-r0   apk     CVE-2022-1304        High
pip          22.3.1                 python  CVE-2018-20225       High
python       3.10.10                binary  CVE-2007-4559        Medium
python       3.10.10                binary  CVE-2023-24329       High
sqlite-libs  3.38.5-r0              apk     CVE-2022-46908       High

Anything else we need to know?:

Environment:

• Output of grype version:
• OS (e.g: cat /etc/os-release or similar):

$ grype version
Application:          grype
Version:              0.59.1
Syft Version:         v0.74.1
BuildDate:            2023-03-09T14:57:12Z
GitCommit:            29b646568901d1ef48a528cf35f67f3cead49c9f
GitDescription:       v0.59.1
Platform:             windows/amd64
GoVersion:            go1.19.6
Compiler:             gc
Supported DB Schema:  5

[daecabhir]

Please note that this is now also being called out for CVE-2022-23491, and continues to be a false positive.

[tgerla]

Hi @ssullivan, thank you for reporting this and for the detailed info. I've reproduced it on my side and we will take a closer look as soon as we can.

[willmurphyscode]

I just did a little digging here, and I think I see why grype is confused:

❯ cat Dockerfile.grype1172
FROM python:3.10.10-alpine3.16
RUN python -m pip install certifi==2022.12.07
❯ docker build . -t grype1172:latest -f Dockerfile.grype1172
❯ docker run grype1172:latest cat /usr/local/lib/python3.10/site-packages/certifi-2022.12.7.dist-info/METADATA | gre
p ^Version
Version: 2022.12.7

So even in site-packages in the image that gets built, certifi's own metadata file includes the version string 2022.12.7. Also, on PyPi, the December 7, 2022 release is identified the same way: https://pypi.org/project/certifi/2022.12.7/

So it seems like 2022.12.7 is a reasonably correct string for this version of certifi. But the GHSA record has 07 in the fix version. Interestingly, the NVD record has Up to (excluding) 2022.12.7. I am curious why the GHSA record has the extra zero; I don't see it anywhere else (besides in the init.py file that @ssullivan posted above).

I'm open to suggestions as to how grype could compensate for this, since PyPi and GHSA don't agree on how the patched version should be labeled. Are there other packages that use dates in their version strings? Maybe we should just suggest an update to the GHSA?

[westonsteimel]

@willmurphyscode - it's the same as with #1034 and #986 - we really just need to implement a PEP 440 version comparer in grype - #986 (comment)