Failure of grype image publishing pipeline caused scan job failures
Summary
The pipeline which publishes a new daily image of the grype container scanner failed for several days last week resulting in no new images being pushed for the version 6.6.0 and version 5.5.5. The pipeline which pushes a new image for version 4.6.26 continued to run successfully.
This meant that:
- the version of the vulnerability database that is included with the
:6
and:5
tagged images exceeded the 5 day maximum age limit for a short period of time on 2023-12-22 causing grype scan jobs to fail with the errordb could not be loaded: the vulnerability database was built 5 days ago (max allowed age is 5 days)
- the
grype:latest
tag was pointing to the version 4.4.26 image which uses an old version of grype and when run was unable to pull the image to be scanned, giving aunable to use OciRegistry source: failed to get image descriptor from registry
error
The second item occurred because each of the 3 pipelines run for the 3 versions pushes a :latest
tag which means the last job to complete "wins".
What is the current bug behavior?
- repeated failure of the scanner release process causes db to become outdated and jobs to fail
-
:latest
tag may point to any of the 3 published versions
What is the expected correct behavior?
- scans should continue to be able to complete if no new image is released for 5 days or more
- the
:latest
tag should point to the latest image of the latest version, or not be published at all
This issue arose from a customer support ticket (ZD internal link).