#7438: feat: add container vulnerability scanning before push

## What Add container vulnerability scanning to the Docker release workflow using Trivy. ## Why Current workflow publishes images without vulnerability scanning, creating a supply-chain security gap where vulnerable dependencies could ship to production undetected. ## Changes - **Build → Scan → Push** flow: Images are scanned before pushing to GHCR - **Fail on vulnerabilities**: `exit-code: 1` blocks push on CRITICAL/HIGH CVEs - **Multi-scanner**: Scans for both vulnerabilities and secrets (`scanners: vuln,secret`) - **GitHub Security integration**: SARIF results uploaded to Security tab - **Pinned action**: `aquasecurity/trivy-action@0.28.0` for reproducibility - **Cache optimized**: GHA build cache reused between local build and push ## Design Decisions - **Only amd64 scanned**: Vulnerabilities are OS/package level and shared across architectures. Scanning both would double CI time without benefit. - **Double build mitigated**: Uses GHA cache so the push step reuses layers from the local build. - **SARIF upload always runs**: Uses `if: always()` so results are available even on failure. ## Impact - Adds ~2-3 minutes to build time - Prevents vulnerable images from being published - Enables security visibility in GitHub Security tab <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR updates the Docker release workflow to insert a Trivy scan step before publishing the amd64 image to GHCR, and uploads a SARIF report to GitHub Security. The workflow now does a local amd64 build (loaded into the runner), scans that image with Trivy (vuln + secret scanners, failing on HIGH/CRITICAL), then performs a separate push build using Buildx/GHA cache. arm64 behavior is unchanged except for a comment. Key things to double-check are that the “double build” is actually mitigated in practice (the local `load` build doesn’t necessarily share layers with the subsequent Buildx push), and that SARIF upload doesn’t introduce noisy secondary failures if the scan output file isn’t produced. <h3>Confidence Score: 3/5</h3> - This PR is generally safe but may add unexpected CI cost and some workflow flakiness in failure cases. - Changes are confined to a single GitHub Actions workflow and don’t affect runtime code, but the new build→scan→push sequence can still rebuild from scratch and the unconditional SARIF upload can fail if the SARIF file isn’t generated, obscuring root causes. - .github/workflows/docker-release.yml <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->