False negative: vulns in AL2023 rpm packages were reported but then disappeared

[sparrowt]

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-release or similar): Windows 11 but running grype in Docker Desktop linux container using official grype image

[popey]

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.

[sparrowt]

Interesting, seems like it is indeed a regression in the Vuln DB then 🤔

[popey]

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 :)

[willmurphyscode]

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.