[NautiluX]

• SBOM generation fails during Trivy setup because the upstream install script downloads from get.trivy.dev, which does not resolve. This blocks both checks on charts#2021.
• Download pinned Trivy v0.76.0 directly from GitHub Releases, verify its published SHA-256 checksum before installation, and add its binary directory to the action PATH. Support the same Linux X64/ARM64 runners as the BOM action and retry download failures.

Change summary

Code:           +33 -3
Generated Code:  +0 -0
Tests:           +0 -0
Docs:            +0 -0

[Copilot]

🟡 Changes recommended

The renamed TRIVY_VERSION key no longer matches Renovate’s custom manager, disabling automated Trivy update proposals until the matcher is updated.

1 open issue

• Update Renovate matcher for the TRIVY_VERSION key · New

What changed in this PR

Replaces the upstream Trivy setup action with direct GitHub Release downloads to avoid the get.trivy.dev DNS failure blocking SBOM generation.

Changes:

• Downloads pinned Trivy v0.76.0 for Linux X64 and ARM64, with retries.
• Verifies the published SHA-256 checksum before extracting and installing the binary.
• Adds the installation directory to the action PATH and checks the installed version.

File	Description
generate/​action.yml	Replaces Trivy setup with direct downloads, checksum verification, and PATH registration.

_{Review effort: Balanced}

[tuxerrante]

LGTM. Downloading straight from the GitHub release matches how we install Trivy in security's trivy-image-batch, and charts already runs on this commit.

One non-blocking thing: the Renovate regex in renovate.json only matches \s+version: , so TRIVY_VERSION: v0.76.0 is no longer tracked and Trivy bumps would stop silently. Widening the matchString to \s+(?:version|[A-Z_]+_VERSION): fixes it.

Optional follow-up: security pins the tarball's SHA in the repo instead of trusting checksums.txt from the same release. In #40 I did the same for cyclonedx-cli, with a Renovate post-upgrade script that refreshes the hash.