Description
The publish-release job re-scans the promoted image with Grype before pushing release tags. If new CVEs emerge between the build-{sha} scan on main and the tag push, the scan fails — leaving an immutable tag (due to tag protection rules) with no corresponding Docker image published.
Problem
The existing Container Scan required check on main already gates the tag ruleset — a tag cannot be pushed unless that scan passed. Re-scanning at publish time introduces a second window where the result can differ from the one that qualified the release.
Expected behaviour
The scan on main is the authoritative gate. publish-release should trust the already-scanned build-{sha} digest and promote it directly without re-scanning. A new CVE discovered after the tag is cut is a separate incident — not a reason to leave a dangling immutable tag with no image.
Suggested fix
Remove the Grype scan step from publish-release. Rely solely on the Container Scan job that runs as a required check on main.
Description
The
publish-releasejob re-scans the promoted image with Grype before pushing release tags. If new CVEs emerge between thebuild-{sha}scan on main and the tag push, the scan fails — leaving an immutable tag (due to tag protection rules) with no corresponding Docker image published.Problem
The existing
Container Scanrequired check on main already gates the tag ruleset — a tag cannot be pushed unless that scan passed. Re-scanning at publish time introduces a second window where the result can differ from the one that qualified the release.Expected behaviour
The scan on main is the authoritative gate.
publish-releaseshould trust the already-scannedbuild-{sha}digest and promote it directly without re-scanning. A new CVE discovered after the tag is cut is a separate incident — not a reason to leave a dangling immutable tag with no image.Suggested fix
Remove the Grype scan step from
publish-release. Rely solely on theContainer Scanjob that runs as a required check on main.