ci: scan app and web images with Trivy

[tomatotomata]

Summary

• Scan both final runtime images (app and web) with Trivy using one shared policy: HIGH and CRITICAL vulnerabilities fail when a fix is available, and end-of-life base OS versions fail.
• Keep the existing multi-architecture publication path unchanged. Pull requests build and load linux/amd64 images locally in CI, then run the same scan script and save SARIF reports; pushes upload available SARIF reports to code scanning.
• Add make scan-images and document the local equivalent.

Validation

• actionlint .github/workflows/docker-image.yml passed.
• bash -n scripts/scan-images.sh passed.
• make -n scan-images passed.
• git diff --check passed.
• Trivy v0.74.0 scanned a remote Alpine image under both labels, produced valid SARIF for each, and returned failure for its HIGH vulnerability with an available fix, as configured.

Local limitation

Docker Desktop's Linux engine is not available in this WSL environment, so I could not build this repository's app and web images locally. The PR workflow builds and scans those actual images. I left this as a draft until that CI run completes.

[tomatotomata]

The local validation is now complete on 628f603. make test-hooks passes, both images build, and make scan-images writes SARIF reports. The app scan exits non-zero for one HIGH fixed finding, CVE-2026-41992 in gzip 1.13-1 (fixed by Debian package 1.13-1+deb13u1); the web image has no findings. I kept the scan policy unchanged, so I am leaving this as a draft rather than marking a failing scan ready. I have not expanded the PR into OS package remediation. Let me know if you think that should be a separate follow-up or part of this change.

[vitormattos]

One note about the PR workflow here.

While the PR is marked as draft, we understand that the implementation is still in progress. When it is ready for code review, please mark it as Ready for review.

I reviewed this one early because it is your first contribution here and I wanted to give some direction before you continue.

After addressing review comments and pushing the changes, please re-request the review so we know it is ready for another pass.

[tomatotomata]

The verification and publish jobs are split now, and both amd64 and arm64 must pass the Trivy gate before publishing either image. The local checks passed on 6347691; the app scan still finds the existing fixed gzip CVE, while the web image is clean. I marked the PR ready. GitHub would not let me re-request your review from my account, and the workflow still shows action_required, so the hosted image build and scans have not run yet. I kept the package update out of scope for now, but let me know if you want that handled here.
Update (Sep 18): PR #56 has merged into main at c25a86d, adding the separate gzip package change. PR #55 was two commits behind main, so I updated its branch; current head is af5deee. The failed run 35193679415 predates that merge and reports gzip 1.13-1 on Debian 13.6, with 1.13-1+deb13u1 listed as fixed. A fresh verification run (35376679253) is now running on the updated branch. The Trivy policy is unchanged, and I will only call the finding resolved if this current-head scan passes.

[vitormattos]

Thanks. The two review points look addressed now.

For the gzip vulnerability, I think it is better to handle the package fix separately from this PR. The scanner is doing what we expect by finding it, so we should not change or relax the Trivy policy here.

We need to fix that vulnerability before merging this PR, otherwise the new publish gate will immediately block the image workflow.

I will first approve the workflow run so we can validate the new CI flow.

[vitormattos]

The implementation looks good now and the CI is passing. The previous technical points are resolved.

There is only one review comment still pending: the README section. Please simplify that part as discussed, then this should be ready.

One small Git tip for future PRs: I noticed you merged main into your branch to update it. This works, but for a feature branch I usually recommend rebasing on main instead:

git fetch origin
git rebase origin/main

This keeps the PR history cleaner and avoids an extra merge commit that only exists to update the branch.

After the README change, please re-request the review.

[vitormattos]

Everything from my review is addressed now.