fix(trivy-repo): install Trivy explicitly so setup failures name themselves

[nkg]

The failure

/home/runner/runner/_work/_actions/aquasecurity/trivy-action/.../entrypoint.sh: line 88: trivy: command not found
##[error]Process completed with exit code 127

trivy-action installs Trivy and immediately scans in the same step, so a setup that half-works surfaces as exit 127 from the scan — naming neither the cause nor the step responsible. It reads like a Trivy bug; it isn't.

Root cause

Not a download failure. The cache restore reported success:

Cache hit for: trivy-binary-v0.70.0-Linux-X64
Cache Size: ~45 MB (47163077 B)
Cache restored successfully
Cache restored from key: trivy-binary-v0.70.0-Linux-X64
##[start-action display=Add Trivy binary to $GITHUB_PATH]
  Run echo /home/runner/.local/bin/trivy-bin >> $GITHUB_PATH

…and the binary still wasn't on PATH. The distinguishing detail is the runner layout:

job (same run)	workspace
fs / trivy — failed	/home/runner/runner/_work/...
config / trivy — passed	/home/runner/_work/...

The self-hosted pool is not uniform, and the cached binary path derives from that layout. So the restore succeeded into a path PATH never looked at, and nothing noticed.

Fix

Install Trivy in an explicit step with the binary cache off, and prove it landed before anything scans:

- name: Install Trivy
  uses: aquasecurity/setup-trivy@3fb12ec... # v0.2.6
  with:
    version: ${{ inputs.trivy-version }}
    cache: false

- name: Verify Trivy is on PATH
  run: trivy --version

- name: Trivy scan (table)
  uses: aquasecurity/trivy-action@ed142fd... # v0.36.0
  with:
    skip-setup-trivy: true
    ...

cache: false trades a ~45MB download per run for a restore path that cannot silently no-op. trivy --version then fails at setup, loudly, instead of as a mystery 127 mid-scan.

Applied to both the table-scan and SARIF jobs — they share the failure mode, and fixing only one would be worse than fixing neither, since the surviving path would fail identically while looking addressed.

Pin detail

setup-trivy is pinned to v0.2.6, not the newer v0.3.x — that's the exact SHA trivy-action@0.36.0 pins internally, so the explicit step installs precisely what the action would have installed itself. Bump the two together.

I verified that SHA against the upstream tag list rather than trusting my own annotation, which initially said v0.2.3 and was wrong.

Also

Adds a trivy-version input (default v0.70.0) so the binary is pinned rather than tracking whatever upstream moves to — a scan shouldn't start reporting differently because of an unpinned dependency.

actionlint clean. Changelog updated under [Unreleased].

🤖 Generated with Claude Code

https://claude.ai/code/session_01Soh3XygRSFTojB3mvakDBr