Scan on image that has python311-setuptools-67.7.2-150400.3.16.1.noarch installed.
It generates high vulnerability:
$ grype --distro sles:15.5 | grep setuptools
NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY
setuptools 67.7.2 70.0.0 python GHSA-cx63-2mw6-8hw5 High
What you expected to happen:
The custom image has only one rpm installed which is python311-setuptools-67.7.2-150400.3.16.1 rpm.
However, when running Syft on the custom image, it gives 2 inputs related to setuptools.
We believe the second reference setuptools 67.7.2 is an extra package that Syft list it.
And this could be the source of problem on running Grype with SUSE packages.
python311-setuptools 67.7.2-150400.3.16.1 rpm
setuptools 67.7.2 python (THIS CAUSE ISSUE for Grype)
If we look at Grype output, it generate vulnerability solely to setuptools 67.7.2.
But setuptools rpm does not exist in the image.
According to SUSE Advisory CVE-2024-6345
Patch for this CVE is applied from version python311-setuptools-67.7.2-150400.3.16.1.noarch
SUSE Linux Enterprise Server 15 SP5
python311-setuptools >= 67.7.2-150400.3.16.1
Patchnames:
SUSE-SLE-Module-Basesystem-15-SP5-2024-3054
SUSE-SLE-Module-Python3-15-SP5-2024-3055
Conclusion: The installed RPM in the custom image is the same patch level as recommended in SUSE Advisory python311-setuptools >= 67.7.2-150400.3.16.1. No vulnerability is generated for that.
However, Grype instead generate vulnerability on second input from Syft setuptools 67.7.2 which is not exist in the container image.
How to reproduce it (as minimally and precisely as possible):
I can't find the same version in public repository, but below reference is enough to reproduce issue on how Syft generate a second output that cause issue to Grype.
python311-setuptools 67.7.2-150400.3.6.1 0:67.7.2-150400.3.16.1 rpm CVE-2024-6345 High
setuptools 67.7.2 70.0.0 python GHSA-cx63-2mw6-8hw5 High
Note: available public RPM Python311-setuptools 67.7.2-150400.3.6.1 is a bit below SUSE Advisory 67.7.2-150400.3.16.1
It is normal that Grype catch in this case.
What is not normal, is the second output setuptools 67.7.2.
It is considered as noise from Syft thus generate false positive.
So we reproduce the same issue as the custom image describes earlier.
Solely personal opinion to improve the tools:
I suggest to filter output from Syft for Python rpm, we always see double entries.
The second entry is the culprit of most Grype false positive.
The second entry does not have the information of the patch level, therefore. prone to generate vulnerability for non existing rpm in the image.
Here some example list from SYFT
python3-setuptools 44.1.1-150400.9.6.1 rpm (installed RPM)
python311-setuptools 67.7.2-150400.3.9.9 rpm (installed RPM)
setuptools 44.1.1 python (Second entry)
setuptools 67.7.2 python (Second entry)
I hope, it will help your investigation.
Environment:
Output of grype version:
$ grype --version
grype 0.79.4
OS (e.g: cat /etc/os-release or similar):
bash-4.4$ cat /etc/release
NAME="SLES"
VERSION="15-SP5"
VERSION_ID="15.5"
PRETTY_NAME="SUSE Linux Enterprise Server 15 SP5"
ID="sles"
ID_LIKE="suse"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:15:sp5"
DOCUMENTATION_URL="https://documentation.suse.com/"
What happened:
Scan on image that has python311-setuptools-67.7.2-150400.3.16.1.noarch installed. It generates high vulnerability:
$ grype --distro sles:15.5 | grep setuptools
NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY setuptools 67.7.2 70.0.0 python GHSA-cx63-2mw6-8hw5 High
What you expected to happen:
The custom image has only one rpm installed which is python311-setuptools-67.7.2-150400.3.16.1 rpm. However, when running Syft on the custom image, it gives 2 inputs related to setuptools. We believe the second reference setuptools 67.7.2 is an extra package that Syft list it. And this could be the source of problem on running Grype with SUSE packages.
python311-setuptools 67.7.2-150400.3.16.1 rpm setuptools 67.7.2 python (THIS CAUSE ISSUE for Grype)
If we look at Grype output, it generate vulnerability solely to setuptools 67.7.2. But setuptools rpm does not exist in the image.
According to SUSE Advisory CVE-2024-6345 Patch for this CVE is applied from version python311-setuptools-67.7.2-150400.3.16.1.noarch
See with this link: https://www.suse.com/security/cve/CVE-2024-6345.html
SUSE Linux Enterprise Server 15 SP5 python311-setuptools >= 67.7.2-150400.3.16.1 Patchnames: SUSE-SLE-Module-Basesystem-15-SP5-2024-3054 SUSE-SLE-Module-Python3-15-SP5-2024-3055
Conclusion: The installed RPM in the custom image is the same patch level as recommended in SUSE Advisory python311-setuptools >= 67.7.2-150400.3.16.1. No vulnerability is generated for that. However, Grype instead generate vulnerability on second input from Syft setuptools 67.7.2 which is not exist in the container image.
How to reproduce it (as minimally and precisely as possible):
I can't find the same version in public repository, but below reference is enough to reproduce issue on how Syft generate a second output that cause issue to Grype.
1) Create the Dockerfile with this content:
FROM registry.suse.com/suse/sle15:15.5 ADD https://rpmfind.net/linux/opensuse/distribution/leap/15.5/repo/oss/noarch/python311-setuptools-67.7.2-150400.3.6.1.noarch.rpm /tmp RUN zypper in -y --no-recommends /tmp/python311-setuptools-67.7.2-150400.3.6.1.noarch.rpm ENTRYPOINT [""] CMD ["bash"]
2) Build an image from Dockerfile
$ docker build -t "suse15.5_python311-setuptools:v1" .
3) Verify package in the container
$ docker run -it suse15.5_python311-setuptools:v1 bash
rpm -qa | grep setuptools
python311-setuptools-67.7.2-150400.3.6.1.noarch
4) Run Syft $ syft suse15.5_python311-setuptools:v1 | grep setuptools
python311-setuptools 67.7.2-150400.3.6.1 rpm setuptools 67.7.2 python (This will cause issue)
$ grype --distro sles:15.5 suse15.5_python311-setuptools:v1 | grep setuptools
python311-setuptools 67.7.2-150400.3.6.1 0:67.7.2-150400.3.16.1 rpm CVE-2024-6345 High setuptools 67.7.2 70.0.0 python GHSA-cx63-2mw6-8hw5 High
Note: available public RPM Python311-setuptools 67.7.2-150400.3.6.1 is a bit below SUSE Advisory 67.7.2-150400.3.16.1 It is normal that Grype catch in this case. What is not normal, is the second output setuptools 67.7.2.
It is considered as noise from Syft thus generate false positive. So we reproduce the same issue as the custom image describes earlier.
Solely personal opinion to improve the tools:
I suggest to filter output from Syft for Python rpm, we always see double entries. The second entry is the culprit of most Grype false positive. The second entry does not have the information of the patch level, therefore. prone to generate vulnerability for non existing rpm in the image.
Here some example list from SYFT python3-setuptools 44.1.1-150400.9.6.1 rpm (installed RPM) python311-setuptools 67.7.2-150400.3.9.9 rpm (installed RPM) setuptools 44.1.1 python (Second entry) setuptools 67.7.2 python (Second entry)
I hope, it will help your investigation.
Environment:
Output of
grype version:$ grype --version grype 0.79.4
OS (e.g:
cat /etc/os-releaseor similar): bash-4.4$ cat /etc/release NAME="SLES" VERSION="15-SP5" VERSION_ID="15.5" PRETTY_NAME="SUSE Linux Enterprise Server 15 SP5" ID="sles" ID_LIKE="suse" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:suse:sles:15:sp5" DOCUMENTATION_URL="https://documentation.suse.com/"