ci(grype): install pinned grype by checksum, drop scan-action

[thomasboni]

Supersedes #294 by @stephrobert, recreated because the original fork branch has "Allow edits by maintainers" disabled and the author is currently unreachable, so the pending review suggestion could not be applied there. His change is included verbatim (credited as co-author on the commit) plus the one addition from the review.

Problem

anchore/scan-action, though pinned by SHA, downloads and executes install.sh from anchore/grype@main at every run. That moving ref is not covered by the pin, so the code actually executed in CI could change with no change to this repo.

Fix (from #294)

Install the pinned grype release directly and verify it against a sha256 committed in this workflow, then run the scan with the same severity gate as before (--fail-on high --only-fixed, matching the action's fail-build: true + severity-cutoff: high + only-fixed: true).

To bump grype: update GRYPE_VERSION and GRYPE_SHA256 together (the hash is published in the release's checksums.txt; verifying that file with cosign verify-blob at bump time is a good habit).

Added on top of #294

GRYPE_CHECK_FOR_APP_UPDATE: "false" on the scan step. The removed action set this; without it grype makes a phone-home update check on every scan.

Verification

The pinned sha256 was verified independently: a fresh download of the official grype_0.114.0_linux_amd64.tar.gz release asset hashes to the committed value, matching the release's checksums.txt. The full chain (checksum OK, grype version, scan completing with the gate applied) already ran green on #294's CI.

🤖 Generated with Claude Code

[cursor]

PR Summary

Low Risk
CI workflow-only change that tightens supply-chain trust for the scanner; no application runtime or auth/data paths affected.

Overview
Container scanning no longer uses anchore/scan-action. CI now downloads grype v0.114.0 from GitHub releases, verifies the tarball with a committed SHA256, installs it, and runs grype "plumber:ci" --fail-on high --only-fixed so the gate matches the old action (fail-build + high severity + only fixed).

The scan step sets GRYPE_CHECK_FOR_APP_UPDATE=false so grype does not phone home for updates (behavior the action used to enforce). Workflow comments document why the action was dropped: its SHA pin still pulled install.sh from grype@main at runtime.

^{Reviewed by Cursor Bugbot for commit 38fd6f0. Bugbot is set up for automated code reviews on this repo. Configure here.}