False positive: GHSA-g3rq-g295-4j3m (CVE-2020-28493), GHSA-h75v-3vvj-5mfj (CVE-2024-34064), GHSA-h5c8-rqwp-cp95 (CVE-2024-22195) python3-Jinja2 in SLES 15.5 Ecosystem, noise from Syft

[sekveaja]

What happened:
Scan on image that has python3-Jinja2-2.10.1-3.10.2.noarch installed.
It generates vulnerabilities:

NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY
Jinja2 2.10.1 3.1.4 python GHSA-h75v-3vvj-5mfj Medium
Jinja2 2.10.1 3.1.3 python GHSA-h5c8-rqwp-cp95 Medium
Jinja2 2.10.1 2.11.3 python GHSA-g3rq-g295-4j3m Medium

What you expected to happen:

According to SUSE Advisory CVE-2020-28493
Patch for this CVE is applied from version python3-Jinja2-2.10.1-3.10.2

See with this link: https://www.suse.com/security/cve/CVE-2020-28493.html

 SUSE Linux Enterprise Server 15 SP5
 python3-Jinja2 >= 2.10.1-3.10.2
 Patchnames:
 SUSE Linux Enterprise Module for Basesystem 15 SP5 GA python-Jinja2-2.10.1-3.10.2

Installed version in the container: python3-Jinja2-2.10.1-3.10.2.noarch

  # rpm -qf /usr/lib/python3.6/site-packages/Jinja2-2.10.1-py3.6.egg-info/PKG-INFO
  python3-Jinja2-2.10.1-3.10.2.noarch

Conclusion: Installed version meet the minimal requirement patch from SLES 15.5 but Grype generate vulnerabilities.

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

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/python3-Jinja2-2.10.1-3.10.2.noarch.rpm /tmp
RUN zypper in -y --no-recommends /tmp/python3-Jinja2-2.10.1-3.10.2.noarch.rpm

ENTRYPOINT [""]
CMD ["bash"]

2. Build an image from Dockerfile

$ docker build -t "suse15.5_python3-jinja:v1" .

3. Test with Grype now

$ grype --distro sles:15.5 suse15.5_python3-jinja:v1

NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY
Jinja2 2.10.1 3.1.4 python GHSA-h75v-3vvj-5mfj Medium (Problem reproduced)
Jinja2 2.10.1 3.1.3 python GHSA-h5c8-rqwp-cp95 Medium (Problem reproduced)
Jinja2 2.10.1 2.11.3 python GHSA-g3rq-g295-4j3m Medium (Problem reproduced)

4. Test with Syft
   $ syft suse15.5_python3-jinja:v1 | grep -i jin

jinja2 2.10.1 python (this is not what is installed)
python3-Jinja2 2.10.1-3.10.2 rpm

** It is observed that Python package, Syft always generate 2 output and one of them lead to false positive for Grype as it is not up to recommended patch level.**

Environment:
$ grype --version
grype 0.78.0

In container image eco-system:
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/"

[willmurphyscode]

Hi @sekveaja this will be fixed by anchore/vunnel#626

[sekveaja]

Thanks @willmurphyscode for the update.
Would you know what is the estimated timeframe that will be implemented.

[kzantow]

Blocked on anchore/vunnel#626

[willmurphyscode]

@sekveaja - I don't have a particular time estimate right now. We just learned that SUSE also has a CSAF 2.0 vulnerability feed, and were recommended to migrate to it. We may end up switching to parsing CSAF and fixing the logic to include the "affected" (i.e. not fixed / wont fix) and not just patched/released vulnerabilities and switch parser at the same time.

The CSAF work has become more urgent because there are other providers that want to only provider the data we need in CSAF.

[sekveaja]

It is observed that Python package, Syft always generate 2 outputs and one of them lead to false positive for Grype as it is not up to recommended patch level from the OS distributor.

[willmurphyscode]

This will be fixed either by #1426 or by anchore/vunnel#635 and a small follow-up change to grype, whichever lands first.

The reason Syft presently emits both a PyPI and an RPM package is that Syft has no way of knowing which has better vulnerability data; excluding either could result in a false negative in Grype. #1426 will fix this by allowing Grype to detect the following situation:

1. An RPM (or dpkg, or apk, or whatever) owns the files that are evidence of the PyPI package, so they are "the same package" in some sense.
2. The distro feed lists the RPM as "fixed"
3. The GHSA feed lists the PyPI package as "vulnerable"

In this situation, Grype should do the right thing and let the "fixed" RPM package override the "vulnerable" PyPI package, but right now Grype doesn't detect this situation, so it's a bit of a big change.