anchore
False negative: vulns in AL2023 rpm packages were reported but then disappeared
What happened:
One day our nightly audit run flagged 4 x rpm vulns in an Amazon Linux 2023 based image (13 Dec 2024, ~21:00)
+ grype -o template -t grypeoutput.tmpl --fail-on low my-image:myversion
TYPE NAME INSTALLED VULN SEVERITY FIXED? FIXED IN UPSTREAM PACKAGE DATASOURCE
python Django 4.2.16 GHSA-m9g8-fxxm-xg86 High fixed 4.2.17 https://github.com/advisories/GHSA-m9g8-fxxm-xg86
python Django 4.2.16 GHSA-8498-2h75-472j Medium fixed 4.2.17 https://github.com/advisories/GHSA-8498-2h75-472j
rpm libxml2 2.10.4-1.amzn2023.0.6 ALAS-2024-783 Medium fixed 2.10.4-1.amzn2023.0.7 https://alas.aws.amazon.com/AL2023/ALAS-2024-783.html
rpm python3 3.9.16-1.amzn2023.0.9 ALAS-2024-770 High fixed 3.9.20-1.amzn2023.0.1 {python3.9 3.9.16-1.amzn2023.0.9} https://alas.aws.amazon.com/AL2023/ALAS-2024-770.html
rpm python3-libs 3.9.16-1.amzn2023.0.9 ALAS-2024-770 High fixed 3.9.20-1.amzn2023.0.1 {python3.9 3.9.16-1.amzn2023.0.9} https://alas.aws.amazon.com/AL2023/ALAS-2024-770.html
rpm python3-pip-wheel 21.3.1-2.amzn2023.0.9 ALAS-2024-781 Medium fixed 21.3.1-2.amzn2023.0.10 {python-pip 21.3.1-2.amzn2023.0.9} https://alas.aws.amazon.com/AL2023/ALAS-2024-781.html
--
Results for: my-image:myversion
Scanned by: grype v0.74.6
Vuln DB date: 2024-12-13 01:32:17 +0000 UTC
--
discovered vulnerabilities at or above the severity threshold
but then the next day on the same code, those reported vulns were no longer reported (14 Dec 2024, ~21:00)
+ grype -o template -t grypeoutput.tmpl --fail-on low my-image:myversion
TYPE NAME INSTALLED VULN SEVERITY FIXED? FIXED IN UPSTREAM PACKAGE DATASOURCE
python Django 4.2.16 GHSA-m9g8-fxxm-xg86 High fixed 4.2.17 https://github.com/advisories/GHSA-m9g8-fxxm-xg86
python Django 4.2.16 GHSA-8498-2h75-472j Medium fixed 4.2.17 https://github.com/advisories/GHSA-8498-2h75-472j
--
Results for: my-image:myversion
Scanned by: grype v0.74.6
Vuln DB date: 2024-12-14 01:31:37 +0000 UTC
--
discovered vulnerabilities at or above the severity threshold
However the vulnerable package versions e.g. libxml2 version 2.10.4-1.amzn2023.0.6 are still present in the image.
(The Django vulns are irrelevant to this bug report)
I have checked with latest grype v0.86.4 and the rpm vulns are still not reported, so it seems like the Vuln DB is the only thing that changed between these 2 runs above.
What you expected to happen:
The vulnerabilities should still be reported by grype, until we patch them.
How to reproduce it (as minimally and precisely as possible):
I believe the following command repros it, though I can't go back in time to check if it would have shown the libxml2 and other vulns on 13th December, but this does not report any vulns, whereas I think it should:
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock anchore/grype:v0.86.1 amazonlinux:2023.6.20241121.0
For comparison, Docker Scout does find the vulns which grype previously reported (but no longer does)
Anything else we need to know?:
Environment:
- Output of
grype version: see above, it occurred on v0.74.6 but still repros on:
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock anchore/grype:v0.86.1 version
Application: grype
Version: 0.86.1
BuildDate: 2024-12-13T19:32:52Z
GitCommit: 5c4fee7b1170976ab435de052fc3611bc955f1f1
GitDescription: v0.86.1
Platform: linux/amd64
GoVersion: go1.23.4
Compiler: gc
Syft Version: v1.18.1
Supported DB Schema: 5
- OS (e.g:
cat /etc/os-releaseor similar): Windows 11 but running grype in Docker Desktop linux container using official grype image
Trying to reproduce this on my local machine, which has no had a grype db update since last week.
What version of DB do I have?
grype db status
Location: /home/alan/.cache/grype/db/5
Built: 2024-12-12 01:32:26 +0000 UTC
Schema: 5
Checksum: sha256:12498468d2fe3a45c23e35d681e9b9b3a80e1590782b257bf2ee8561417af043
Status: valid
Check with the currently installed DB.
GRYPE_DB_AUTO_UPDATE=false grype amazonlinux:2023.6.20241121.0
✔ Loaded image amazonlinux:2023.6.20241121.0
✔ Parsed image sha256:4e24a4e616bb9928209da85eb4d989dc91cbf785c4687947d51fd75fde578dd9
✔ Cataloged contents 177870a058c8f8b2c6907144bce7a332dacb84a757318790492e4cc757f27d01
├── ✔ Packages [109 packages]
├── ✔ File digests [5,056 files]
├── ✔ File metadata [5,056 locations]
└── ✔ Executables [272 executables]
✔ Scanned for vulnerabilities [4 vulnerability matches]
├── by severity: 0 critical, 2 high, 2 medium, 0 low, 0 negligible
└── by status: 4 fixed, 0 not-fixed, 0 ignored
NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY
libxml2 2.10.4-1.amzn2023.0.6 2.10.4-1.amzn2023.0.7 rpm ALAS-2024-783 Medium
python3 3.9.16-1.amzn2023.0.9 3.9.20-1.amzn2023.0.1 rpm ALAS-2024-770 High
python3-libs 3.9.16-1.amzn2023.0.9 3.9.20-1.amzn2023.0.1 rpm ALAS-2024-770 High
python3-pip-wheel 21.3.1-2.amzn2023.0.9 21.3.1-2.amzn2023.0.10 rpm ALAS-2024-781 Medium
Update the database.
grype db update
✔ Vulnerability DB [updated]
Vulnerability database updated to latest version!
grype db status
Location: /home/alan/.cache/grype/db/5
Built: 2024-12-16 01:31:49 +0000 UTC
Schema: 5
Checksum: sha256:ac1801a30dd386afde62d76f1cb138649133bb2f8aa09ad19c4a92954ab67ae4
Status: valid
Try the test again.
grype amazonlinux:2023.6.20241121.0
✔ Loaded image amazonlinux:2023.6.20241121.0
✔ Parsed image sha256:4e24a4e616bb9928209da85eb4d989dc91cbf785c4687947d51fd75fde578dd9
✔ Cataloged contents 177870a058c8f8b2c6907144bce7a332dacb84a757318790492e4cc757f27d01
├── ✔ Packages [109 packages]
├── ✔ File digests [5,056 files]
├── ✔ File metadata [5,056 locations]
└── ✔ Executables [272 executables]
✔ Scanned for vulnerabilities [0 vulnerability matches]
├── by severity: 0 critical, 0 high, 0 medium, 0 low, 0 negligible
└── by status: 0 fixed, 0 not-fixed, 0 ignored
No vulnerabilities found
Confirmed they're gone.
Indeed. Grype gets the data via vunnel, pulled from the upstream provider, where these vulnerabilities disappear. We've contacted the security team there to find out what's happening. Stand by :)
No word from maintainers of the data yet, but https://alas.aws.amazon.com/alas2023.html shows that ALAS-2024-783 and ALAS-2024-781 are back.
Today's grype db now has those:
$ grype -q amazonlinux:2023.6.20241121.0 | rg -e NAME -e ALAS-2024-783 -e ALAS-2024-770 -e ALAS-2024-781
NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY
libxml2 2.10.4-1.amzn2023.0.6 2.10.4-1.amzn2023.0.7 rpm ALAS-2024-783 Medium
python3-pip-wheel 21.3.1-2.amzn2023.0.9 21.3.1-2.amzn2023.0.10 rpm ALAS-2024-781 Medium
Grype now finds ALAS-2024-783 and ALAS-2024-781 again. Interestingly, ALAS-2024-770 is still listed at its own URL, just not in the index; I suppose grype could just guess URLs instead of trusting the index, but I'd like to wait to hear from the maintainers of this data before making such a change.
I just wanted to post a quick update here. We've emailed the maintainers of the ALAS website, and they've assured us that the issue is resolved, but only 2 of the 3 vulnerabilities were actually restored to the index file at https://alas.aws.amazon.com/alas2023.html. ALAS-2024-770 still shows up at https://alas.aws.amazon.com/AL2023/ALAS-2024-770.html but is not listed in the index file, which seems unintentional. @westonsteimel is there something we can do next, after emailing the upstream data maintainers?
I think this will be fixed by https://github.com/anchore/vunnel/issues/776