ci(security): Trivy misconfig + fs scan gate (split from #1463)

[ktursunov]

Goal

Stand up Trivy as its own security-scan CI gate for the Insight repo — misconfiguration
(IaC / Dockerfile) scanning plus filesystem vulnerability scanning. Split out of the
now-closed omnibus PR #1463 so Trivy can be triaged and ratcheted to blocking independently,
per the acceptance criteria of the security-scanner umbrella #1478 (report-only first → gate
once the baseline is agreed with the team).

Proposed approach

Lift the trivy-config job from the closed PR #1463 (.github/workflows/security-gates.yml)
into its own workflow/job, pinned to aquasecurity/trivy-action by commit SHA:

• Config scan — scan-type: config, scan-ref: ., severity: CRITICAL,HIGH (Trivy IaC +
  Dockerfile misconfiguration).
• Filesystem scan — scan-type: fs, severity: CRITICAL,HIGH, ignore-unfixed: true.
• Waivers live in .trivyignore, tracked in Security: trivy-config HIGH misconfigurations — root containers + frontend Deployment securityContext (waivers) #1340 — remove each as the underlying issue is fixed:
  • AVD-DS-0002 — container runs as root (build/test/tooling images)
  • AVD-DS-0029 — apt-get without --no-install-recommends (toolbox build image)
  • AVD-KSV-0118 — frontend Deployment missing securityContext
  • AVD-KSV-0014 — frontend Deployment root FS not read-only

Start report-only, triage the baseline, then flip exit-code: "1" to make CRITICAL/HIGH
block once findings are agreed with the team.

Acceptance criteria

• Trivy config + fs scan runs on PRs to main and on a nightly schedule, surfaced in checks / job summary.
• .trivyignore present with documented, tracked waivers only.
• Baseline findings triaged; follow-up issues filed for anything actionable.
• Gate threshold (what blocks) agreed with the team before flipping to blocking.

---

Split from #1463 (closed). Part of #1478 (security-scanner umbrella) → Quality Framework Security vector.