Grype: the database date is part of the result

The row is only as current as the database

Grype compares a package list with a vulnerability database. The row means that database associated the package version with an advisory. A database built last month does not contain advisories published after it. A database built today can list an advisory the older one did not.

The built time is not on the vulnerability row itself. It is in the database status you record beside the scan. A note that omits it cannot be compared with another note.

Do not explain a new row as a new image

If the image digest is the same and the database built time changed, a new row is a change in the database. It is not evidence the image was rebuilt or that a package version changed. Check the digest before you write either of those.

If the digest also changed, say both facts. Do not fold them into “the image got worse” without showing which one moved.

What to file

File the database built time, the image digest or the SBOM filename, the package, the installed version, and the advisory id. If the built time was not recorded, write “database date not recorded” and do not compare the row with another scan.

Worked case: the same digest, a newer database

Monday’s note lists no openssl row and does not record a database date. Wednesday’s scan of the same image digest lists openssl as High, and the database status says it was built Wednesday. A draft says the image was rebuilt and picked up a vulnerable openssl.

The note records both built times once Monday’s status is recovered from the job log: the Monday database was built in October. The digest did not change. The new row is the newer database. The image was not rebuilt. The package version in the image is the one already there, now matched.

image digest: same on Monday and Wednesday
Monday database built: October, from the job log
Wednesday database built: Wednesday
row: openssl, High, advisory id as printed
write: the database changed
not: the image was rebuilt