[SYNPY-1764] Add Trivy container vulnerability scanning

[BryanFauble]

Summary

• Add Trivy vulnerability scanning to gate Docker image publication on GHCR, following Sage's Container Vulnerability Scanning guidelines
• Restructure both release and develop Docker jobs from single build+push steps into a build → scan → push pattern — images are only pushed if no Critical/High unfixed vulnerabilities are found
• Add daily periodic scan of the latest published image with auto-remediation (patch version bump + rebuild) when new vulnerabilities are detected

New workflow files

File	Purpose
trivy.yml	Reusable Trivy scanning workflow — scans tar or remote image, uploads SARIF to GitHub Security tab
docker_build.yml	Reusable build/scan/push workflow for periodic rebuilds
trivy_periodic_scan.yml	Daily rescan of latest published image with auto-remediation

Key Trivy settings

• ignore-unfixed: true — only actionable vulnerabilities
• severity: CRITICAL,HIGH — skip Medium/Low
• exit-code: 1 — fail builds on findings
• SARIF upload to GitHub Security tab for triage
• Alternate Trivy DB repos (public.ecr.aws) to avoid rate limits

Test plan

• Push to develop branch and verify the build → Trivy scan → push flow completes successfully
• Verify SARIF results appear in the repo's Security tab (Code Scanning)
• Verify Docker image is pushed to GHCR only after Trivy scan passes
• Manually trigger trivy_periodic_scan.yml via workflow_dispatch and verify it scans the latest published image
• Create a pre-release to verify the release Docker flow works end-to-end

🤖 Generated with Claude Code

[BryanFauble]

Pre-review: documentation comments on complex areas to help reviewers.

Note: These comments were generated with AI assistance to help reviewers understand complex areas.

[BryanFauble]

This is the central reusable scanning workflow — called from both build.yml (pre-push scan) and trivy_periodic_scan.yml (post-publish rescan). It supports two modes:

Mode	SOURCE_TYPE	How it gets the image	Used by
Pre-push	tar	Downloads artifact from calling workflow, loads via docker load	build.yml, docker_build.yml
Post-publish	image	Trivy pulls directly from GHCR	trivy_periodic_scan.yml

The EXIT_CODE input controls whether findings fail the workflow (1) or just report (0). Both build.yml and the periodic scan use 1 so vulnerabilities are blocking.

The alternate Trivy DB repos (public.ecr.aws/aquasecurity/trivy-db:2) are important — the default GitHub-hosted DB gets rate-limited due to high download volume across the ecosystem.

SARIF results are uploaded even when Trivy finds vulnerabilities (the success() || steps.trivy.conclusion == 'failure' condition), so findings always land in the Security tab for triage regardless of whether the build passes.

Note: This comment was drafted with AI assistance and reviewed by me for accuracy.

[BryanFauble]

This workflow rescans the latest published image daily to catch newly disclosed CVEs. The flow has a multi-job conditional chain that's worth understanding:

graph TD
    A[get-image-reference] -->|"latest tag from mathieudutour/github-tag-action"| B[periodic-scan]
    B -->|clean| C[Done — no action needed]
    B -->|"trivy_conclusion == 'failure'"| D[bump-tag]
    D -->|"new patch version tag"| E[update-image]
    E -->|"calls docker_build.yml"| F[Rebuild + Trivy scan + push]

Loading

The !cancelled() condition on bump-tag and update-image is important — without it, these jobs would be skipped when the scan fails (since needs.periodic-scan would have a failure result, and GitHub Actions skips downstream jobs by default on failure). The !cancelled() override lets them run, and the trivy_conclusion == 'failure' check ensures they only run when there are actual findings.

The rebuild via docker_build.yml includes its own Trivy scan, so the patched image is only published if the rebuild actually remediates the vulnerabilities.

Note: This comment was drafted with AI assistance and reviewed by me for accuracy.

[linglp]

See news about trivy scan: https://socket.dev/blog/trivy-under-attack-again-github-actions-compromise
Also, should we merge this branch to develop rather than add-claude-md?

[jaymedina]

Review: Trivy Container Vulnerability Scanning

Good overall structure — the reusable trivy.yml, docker_build.yml, and daily trivy_periodic_scan.yml follow the Sage Container Vulnerability Scanning guidelines cleanly. One critical correctness issue needs fixing before merge, plus a few smaller items.

Issues

• 🔴 Critical — Push jobs in build.yml rebuild the image from scratch instead of loading and pushing the scanned tar. The scanned artifact is abandoned, so the image that reaches GHCR was never verified. docker_build.yml's push-image job shows the correct pattern: download → load → tag → push.
• 🟡 Moderate — YAML \ line continuation in IMAGE_REFERENCES preserves newlines and leading spaces, producing a tag with a leading space that will fail on docker push.
• 🔵 Minor — Third-party actions pinned to floating tags (@v6.2, @v1) rather than commit SHAs.
• 🔵 Minor — get-image-reference job carries deployments: write and security-events: write permissions it does not need.
• 🔵 Minor — ghcr-push-on-develop relies on implicit skip from needs: rather than an explicit if: condition.

[jaymedina]

Great architectural direction — the build → scan → push pattern is exactly the right approach, and the reusable trivy.yml workflow is well designed. There are two bugs that need to be fixed before merging:

1. Push jobs rebuild the image instead of loading the scanned artifact (both ghcr-push-on-release and ghcr-push-on-develop in build.yml): the image that gets pushed to GHCR is a fresh rebuild, not the artifact that Trivy scanned. docker_build.yml correctly solves this by loading from tar — the same pattern needs to be applied here.

2. ${{ env.repo_name }} in the job outputs section won't capture the runtime env var (trivy_periodic_scan.yml:33): env vars set via $GITHUB_ENV are not accessible in the jobs.<job>.outputs expression context. This will produce an empty string, causing the periodic scan to target the wrong image.

Note: This comment has been generated with AI assistance and reviewed by the author.

[BryanFauble]

Keeping add-claude-md as the base for now — this PR is part of a stacked set of changes on that branch. It'll merge to develop once the parent PR lands.

On the Trivy supply chain concern — updated to pin to the safe SHA (v0.35.0). All other third-party actions have been SHA-pinned as well.

Note: This comment was drafted with AI assistance and reviewed by me for accuracy.

[linglp]

Just a comment about ignore-unfixed: true. I am a bit concerned that if there's a fix in a higher version of the dependency, the code would trigger a rebuild loop

[Copilot]

Pull request overview

Adds Trivy container vulnerability scanning to the GitHub Actions CI/CD pipeline so Docker images are scanned before publication to GHCR, and introduces a daily rescan workflow that can auto-remediate by rebuilding with a patch bump when new vulnerabilities appear.

Changes:

• Introduces a reusable Trivy scanning workflow that can scan either a local tarball image or a remote registry image and upload SARIF results.
• Refactors the release and develop GHCR publishing flows into build → scan → push so publication is gated on the Trivy result.
• Adds a scheduled “periodic scan” workflow that scans the latest image daily and attempts an automated rebuild + tag bump on failures.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.

File	Description
.github/workflows/trivy.yml	New reusable Trivy scan workflow producing SARIF output for GitHub code scanning.
.github/workflows/docker_build.yml	New reusable build/scan/push workflow used for automated rebuilds after periodic scans.
.github/workflows/trivy_periodic_scan.yml	New scheduled workflow that scans the latest image daily and triggers rebuild/tagging on findings.
.github/workflows/build.yml	Refactors existing release/develop Docker publishing into build → scan → push using the reusable Trivy workflow.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[linglp]

LGTM! Just some minor comments!