Docker Scout, one of a constellation of scanners available for checking software package security, detects many vulnerabilities in the latest AWS CLI image (as of today, in the image with manifest digest f83aa3fc886c):
> docker scout quickview amazon/aws-cli
SBOM of image already cached, 235 packages indexed
Target │ amazon/aws-cli:latest │ 0C 46H 69M 0L
digest │ ff2eb7d99b2d │
Base image │ amazonlinux:2023 │ 0C 0H 0M 0L
Refreshed base image │ amazonlinux:2023 │ 0C 0H 0M 0L
(The digest referred to here is the image ID; I’m thinking there are too many hashes available for referencing practically the same Docker object.)
Note that the vulnerabilities turn up only in the AWS CLI image and not in its base, Amazon Linux 2023 (a.k.a. AL2023).
The 46 high-severity and 69 medium-severity issues (total: 115) boil down to these five CVEs, each found in 23 packages (times 5 CVEs, equals 115):
- CVE-2023-31486
- CVE-2023-31484
- CVE-2023-47100
- CVE-2023-47038
- CVE-2025-40909
The interesting pattern is that all 23 packages are various versions of rpm/amazonlinux/perl. All five CVEs are also fixable (have available patches now). I determined that these scan results are false-positives: I picked the latest CVE (the 2025 one), looked it up in the Amazon Linux Security Center, and then read ALAS2023-2025-1007, the Amazon Linux Security Advisory relevant to AL2023.
There, I randomly picked some of the fixed package version strings, and inspected the image until I found a match. I found a hit with perl-File-Basename-2.85-477.amzn2023.0.7.noarch:
> docker run --rm -it --entrypoint "" amazon/aws-cli sh
sh-5.2# dnf list --installed perl-File-Basename*
Installed Packages
perl-File-Basename.noarch 2.85-477.amzn2023.0.7 @amazonlinux
Looking at the advisory for one of the older CVEs, ALAS2023-2023-448, I saw that the fixed package has a lesser version string, perl-File-Basename-2.85-477.amzn2023.0.6.noarch (ending in 0.6 instead of the now-installed 0.7).
What’s happening here apparently is that Docker Scout’s heuristics are failing in Amazon Linux, an RPM-based distribution. From the Docker official images FAQs:
Why does my security scanner show that an image has CVEs?
…For many of the Official Images, a security analyzer might show CVEs, which can happen for a variety of reasons:…
The listed CVE is a false positive
- In order to provide stability, most OS distributions take the fix for a security flaw out of the most recent version of the upstream software package and apply that fix to an older version of the package (known as backporting).
e.g., CVE-2020-8169 shows thatcurlis flawed in versions7.62.0though7.70.0and so is fixed in7.71.0. The version that has the fix applied in Debian Buster is7.64.0-4+deb10u2(see security-tracker.debian.org and DSA-4881-1)…The security scanners can’t reliably check for CVEs, so it uses heuristics to determine whether an image is vulnerable. Those heuristics fail to take some factors into account:
- …If the image is not supported by the security scanner, it uses wrong checks to determine whether a fix is included.
- e.g., For RPM-based OS images, the Red Hat package database is used to map CVEs to package versions. This causes severe mismatches on other RPM-based distros.
For CVE-2025-40909, for example, Docker Scout says that the affected version range is <5.32.1-477.amzn2023.0.7, while the fixed version is 5.32.1-477.amzn2023.0.7. But this version string applies only to the head perl package, and Perl modules have separate versioning. Scout is apparently picking up some of these modules with their lesser version strings and mistaking them as vulnerable, when in fact Amazon has already backported the fixes to these separately packaged modules.
Perhaps Scout will have its scanning logic fixed eventually for these images, but in the meantime, at least for these CVEs, they can be ignored or marked for exceptions with VEX.