ci(pre-commit): fetch Trivy installer from pinned release tag

[cristim]

Problem

Code-review finding INF-07 (#1187): the Install Trivy step in .github/workflows/pre-commit.yml fetched contrib/install.sh from the mutable main branch of aquasecurity/trivy and piped it straight into sh:

curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin v0.69.3

A compromised or accidentally broken install.sh on trivy main would execute arbitrary code on the CI runner, the exact supply-chain weakness the adjacent tflint step in the same workflow already guards against by pinning its installer to a release tag.

Fix

• Fetch the installer from the same pinned release tag as the Trivy binary (v0.69.3), introduced as a single TRIVY_VERSION env var so the pin lives in one place.
• Download the script to a file and execute it from there instead of piping a network stream into sh, matching the tflint installer pattern.
• curl -fsSL plus set -euo pipefail so transport errors fail loudly instead of feeding an HTML error page into the shell.

Test evidence

• actionlint .github/workflows/pre-commit.yml passes.
• Verified contrib/install.sh exists at the v0.69.3 tag and ran the pinned-tag installer end-to-end with the same arguments (sh install.sh -b <dir> v0.69.3); it installed a working trivy reporting Version: 0.69.3.

Closes #1187

🤖 Generated with claude-flow

[coderabbitai]

Warning

Review limit reached

@cristim, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 22 minutes and 12 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 30c60c47-ea97-4f37-bb3f-132dc00c1907

📥 Commits

Reviewing files that changed from the base of the PR and between 451a70f and 616b310.

📒 Files selected for processing (1)

• .github/workflows/pre-commit.yml

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch ci/inf-07-fix

---

_{Comment @coderabbitai help to get the list of available commands.}

[cristim]

@coderabbitai review

[coderabbitai]

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[cristim]

@coderabbitai review

[coderabbitai]

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[cristim]

Adversarial review notes

Reviewed this as a CI supply-chain surface (any code path that lands an installer script on the runner is a CI compromise vector). Findings:

No actionable changes needed

The fix is sound and matches the tflint pattern already in this workflow. Walked the supply chain end-to-end:

• Tag-pinned, not branch-pinned. TRIVY_VERSION=v0.69.3 resolves to a release tag, not main/master/HEAD. The mutable-branch attack INF-07 was filed against is closed.
• File-then-execute, not pipe-to-sh. curl -fsSL -o /tmp/trivy-install.sh ... && sh /tmp/trivy-install.sh ... removes the truncation-execution class the prior curl ... | sh opened (network cut mid-stream can no longer leave a half-written script that still partly executes).
• set -euo pipefail upgrade is intentional. Previous step was set -eo pipefail — adding -u catches an unset TRIVY_VERSION (or a typo'd env var) at expansion time instead of silently fetching https://raw.githubusercontent.com/aquasecurity/trivy//contrib/install.sh which 404s but only after curl already retried. Defensive, no behavior regression.
• Binary-side verification is intact. Pulled the pinned install.sh at v0.69.3: it http_downloads both the tarball and the published .sig/checksum file from the same release, then hash_sha256_verifys the tarball before installing. Tag-pinning the script + script SHA-verifying the binary = pinned end-to-end. The only residual attack is a force-push of v0.69.3 that rewrites BOTH install.sh AND the published checksum file — not realistic for aquasecurity/trivy, and explicitly the same residual risk the tflint step already accepts.
• tag_to_version() doesn't unpin. install.sh's github_release() hits https://github.com/aquasecurity/trivy/releases/v0.69.3 (not .../latest) when a tag is passed; the v0.69.3 arg is positional and quoted at the call site. No silent "latest" fallback path.

Considered, no change needed

• feedback_ci_tool_version_pin.md family compliance. Swept every workflow file in .github/workflows/*.yml for curl .*github\.com, wget .*github\.com, @latest, @HEAD, @main, @master outside comments. Zero remaining unpinned installers. Both surviving @latest mentions are in comments warning against it.
• feedback_sha_pin_current_major.md applicability. This step doesn't use a GitHub Action (no uses: aquasecurity/trivy-action@<sha>), it shells out, so the SHA-pin-the-major rule doesn't apply here. The separate ci.yml Trivy step already uses aquasecurity/trivy-action@ed142fd0673e97e23eac54620cfb913e5ce36c25 # v0.36.0 correctly.
• CI cache staleness. Trivy isn't in any cache key — it lands in /usr/local/bin and re-installs every run. The adjacent go-tools-...-gosec-v2.22.4-gocyclo-v0.6.0 cache is correctly versioned and doesn't include trivy. Version-bump-stale-cache class doesn't trigger.
• SHA256-pinning install.sh itself. Mentioned in the risk surface — declined for scope parity with the existing tflint step (same install model, same residual risk). If we want to lift this baseline, do it as a single follow-up that pins BOTH install.sh files by content hash and re-verifies on bump, not as a one-off here.
• UNSTABLE is pre-existing on main, not PR-caused. This PR's only diff is .github/workflows/pre-commit.yml, and the pre-commit workflow itself passes (Run pre-commit hooks → success). The three failing checks (Lint Code, Integration Tests, Security Scanning) all belong to CI - Build & Test, which is red on main@451a70f73 with the same three failures — verified against run 27833571269 (the main-push run for that SHA). Lint Code is reporting 2,875 pre-existing golangci-lint issues across 17 linters; Integration Tests and Security Scanning (npm audit) are pre-existing red. Not in scope to fix in this PR.

Out-of-scope follow-ups

None. The PR's scope is exactly the INF-07 closure — leaving the broader CI red surface for the workflows that own those checks.

CR re-requested.

[cristim]

@coderabbitai review

[coderabbitai]

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.