Drastically different reports generated for nginx:latest image in span of 1 day.

[chitti-intel]

What happened:
Scan result for "nginx:latest" returns 0 vulnerability on running grype with "GRYPE_DB_AUTO_UPDATE=false" and using "vulnerability-db_v5_2023-09-29T01:24:33Z_fa7e2e17bf5b75256d23.tar.gz".

On switching to "vulnerability-db_v5_2023-09-30T01:22:53Z_5f6448225b9e81917b9f.tar.gz" grype reported vulnerabilities for nginx:latest.

What you expected to happen:

If the image's digest was the same and the Grype DBs were built a day apart, the reports shouldn't have varied this drastically unless all the CVEs were fixed or added within that day.

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

1. Turn off auto grype db update by setting "GRYPE_DB_AUTO_UPDATE=false"
2. Download "vulnerability-db_v5_2023-09-29T01:24:33Z_fa7e2e17bf5b75256d23.tar.gz" grype db.
3. Import the db by running "grype db import vulnerability-db_v5_2023-09-29T01:24:33Z_fa7e2e17bf5b75256d23.tar.gz "
4. Scan nginx:latest image "grype nginx:latest"

Anything else we should know?:

I have been using the nginx:latest image to test the scanner for a few months. This behavior was observed only for this Grype db built on September 29th 2023. All the previous scans have reported vulnerabilities.

Environment:

• Output of grype version:
  Application: grype
  Version: 0.69.1
  BuildDate: 2023-09-27T16:51:03Z
  GitCommit: dec5636
  GitDescription: v0.69.1
  Platform: linux/amd64
  GoVersion: go1.21.1
  Compiler: gc
  Syft Version: v0.92.0
  Supported DB Schema: 5

• OS (e.g: cat /etc/os-release or similar):
  PRETTY_NAME="Ubuntu 22.04.3 LTS"
  NAME="Ubuntu"
  VERSION_ID="22.04"
  VERSION="22.04.3 LTS (Jammy Jellyfish)"
  VERSION_CODENAME=jammy

[wagoodman]

@chitti-intel thanks for the issue and the details. We merged a PR upstream in vunnel that ended up breaking the debian provider from the 27th through the 29th. We got the fix in on the 29th and rebuilt/republished. We have some future changes inbound in vunnel and the shared vulnerability-match-label data we use in our quality gates to protect against these kinds of regressions in the future. I'll close this for now since the data issue has been resolved, but feel free to shout out more questions about this.