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.

[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]

I think this is too much implementation detail for the README.

The README should stay focused on what this project provides and how to use it. Details about Trivy, SARIF, the severity policy, architectures and QEMU are internal details of the CI implementation and can make the README grow every time we change the tooling.

I think it is enough to briefly say that the published images are scanned for vulnerabilities and keep the local command for contributors:

make scan-images

The scan policy itself is already documented by trivy.yaml and the implementation.