Question: Number of critical CVEs

[blixhavn]

Hey guys!

I'm really not trying to be snarky here, and I'm honestly wondering: Why does one of the latest non-rc docker image for python (3.10.5-bullseye) have 55 critical CVEs, some of which are from 2017 (and even one from 2015).

Is most of it non-upgradeable dependencies, is it time consuming or hard to fix, or is it just not a priority?
Would it be possible/feasible to make my own python image with less CVEs?

[wglambert]

See https://github.com/docker-library/faq#why-does-my-security-scanner-show-that-an-image-has-cves
And docker-library/openjdk#449 (comment), docker-library/postgres#286 (comment) docker-library/openjdk#161, docker-library/openjdk#112, docker-library/postgres#286, docker-library/drupal#84, docker-library/official-images#2740, docker-library/ruby#117, docker-library/ruby#94, #152, docker-library/php#242, docker-library/buildpack-deps#46, docker-library/openjdk#185.

A CVE doesn't imply having an actual vulnerability, and often is even a false positive (given how most distributions handle versioning/security updates in stable releases). If there are actionable items we can resolve, we're happy to do so (and do so actively). We update all Debian based images to include any updates in apt packages at least monthly (we regenerate the base images and then rebuild all dependent images).

The image's packages are fully up to date

$ docker run -it --rm python:3.10.5-bullseye bash
Unable to find image 'python:3.10.5-bullseye' locally
3.10.5-bullseye: Pulling from library/python
d836772a1c1f: Already exists
66a9e63c657a: Already exists
d1989b6e74cf: Already exists
c28818711e1e: Already exists
5084fa7ebd74: Pull complete
7f162c881e4f: Pull complete
e3f48ccb2876: Pull complete
315a1520c10e: Pull complete
eba0bda87095: Pull complete
Digest: sha256:f0621f54da3e393b3ace00dd2f2e8b9919a913f3cadf843ba7e203dbac68b376
Status: Downloaded newer image for python:3.10.5-bullseye
root@c71fa9bc3453:/# apt update && apt list --upgradable
Get:1 http://deb.debian.org/debian bullseye InRelease [116 kB]
Get:2 http://deb.debian.org/debian-security bullseye-security InRelease [44.1 kB]
Get:3 http://deb.debian.org/debian bullseye-updates InRelease [39.4 kB]
Get:4 http://deb.debian.org/debian bullseye/main amd64 Packages [8182 kB]
Get:5 http://deb.debian.org/debian-security bullseye-security/main amd64 Packages [166 kB]
Get:6 http://deb.debian.org/debian bullseye-updates/main amd64 Packages [2592 B]
Fetched 8550 kB in 2s (5398 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
Listing... Done

[yosifkit]

So, the packages from Debian are currently as up to date as possible (and we continue to rebuild the Debian-based images on an approximately 30 day cycle).

Going to Debian's security tracker (like https://security-tracker.debian.org/tracker/CVE-2022-27405) and swapping in a specific CVE, it is possible to see the Debian Security Team notes on why a fix might not be applied (like minor issue in the above link), why the CVE might not apply, or that it is already applied via a patch to an older version. It is very common to backport security fixes to keep the package with a consistent API/ABI/version within a stable OS release (Buster, Bullseye, etc) to keep the OS actually stable.

[blixhavn]

I see. Thanks for the elaborate reply :)