fix(ci): run Trivy via Docker Hub image instead of github.com tarball
CI / load-versions (pull_request) Successful in 15s
CI / push-validation (pull_request) Successful in 27s
CI / lint (pull_request) Successful in 48s
CI / quality (pull_request) Successful in 52s
CI / typecheck (pull_request) Successful in 1m7s
CI / build (pull_request) Successful in 32s
CI / security (pull_request) Successful in 1m21s
CI / helm (pull_request) Successful in 44s
CI / unit_tests (pull_request) Successful in 4m39s
CI / docker (pull_request) Failing after 2m1s
CI / integration_tests (pull_request) Failing after 10m18s
CI / coverage (pull_request) Successful in 9m42s
CI / status-check (pull_request) Failing after 3s

The docker gate has been failing on `curl: (22) ... error: 404` against
the v0.58.0 GitHub release tarball even after pinning the version. The
helm gate's kubeconform download from github.com/yannh/kubeconform works
in the same workflow, so it's a Trivy-asset-path-specific 404 (URL/CDN
state we don't control), not a blanket github.com block.

Switch to `aquasec/trivy:0.58.0` pulled from Docker Hub:

- Docker Hub is already proven reachable by the preceding `docker build`
  steps (server image base layers pull successfully in this same dind
  job).
- A pinned tag's manifest digest is itself the verifiable artifact — no
  separate checksum file fetch and grep dance.
- Trivy runs against the just-built `cleveragents-server:test` image
  via the mounted dind docker socket.
- Same severity gating (`--severity HIGH,CRITICAL --exit-code 1`) and
  same trailing detailed-report step are preserved verbatim.

ISSUES CLOSED: #1927
This commit is contained in:
2026-06-17 22:32:55 -04:00
committed by drew
parent ae9bd860c5
commit 03c8e5fa53
+25 -17
View File
@@ -621,27 +621,35 @@ jobs:
- name: Security scan Dockerfile.server image with Trivy
run: |
# Install Trivy at a pinned version with checksum verification.
# v0.58.0 is the first stable release after v0.57.0; v0.57.1 does
# not exist as a Trivy release tag.
# Run Trivy via the pinned upstream Docker image instead of
# downloading the GitHub release tarball. The previous tarball
# approach hit persistent 404s from this runner's network path
# to github.com release assets (kubeconform on github.com works,
# so it isn't a blanket block — the Trivy asset path is the
# one that fails). Docker Hub access is already proven by the
# preceding docker build steps in this same dind job, and
# pulling a pinned tag yields a content-addressable manifest
# digest — no separate checksum bookkeeping needed.
set -euo pipefail
apk add --no-cache curl tar
TRIVY_VERSION="0.58.0"
TRIVY_TARBALL="trivy_${TRIVY_VERSION}_Linux-64bit.tar.gz"
TRIVY_BASE_URL="https://github.com/aquasecurity/trivy/releases/download/v${TRIVY_VERSION}"
curl -fsSL "${TRIVY_BASE_URL}/${TRIVY_TARBALL}" -o "/tmp/${TRIVY_TARBALL}"
curl -fsSL "${TRIVY_BASE_URL}/trivy_${TRIVY_VERSION}_checksums.txt" -o /tmp/trivy_checksums.txt
( cd /tmp && grep " ${TRIVY_TARBALL}\$" trivy_checksums.txt | sha256sum -c - )
tar -xzf "/tmp/${TRIVY_TARBALL}" -C /usr/local/bin trivy
trivy --version
TRIVY_IMAGE="aquasec/trivy:0.58.0"
docker pull "${TRIVY_IMAGE}"
# Scan the Dockerfile.server image for vulnerabilities
# Exit with non-zero status if HIGH or CRITICAL vulnerabilities are found
trivy image --severity HIGH,CRITICAL --exit-code 1 cleveragents-server:test
# Mount the dind docker socket so Trivy can inspect the
# cleveragents-server:test image we just built. Fail the gate
# on HIGH or CRITICAL findings.
docker run --rm \
-v /var/run/docker.sock:/var/run/docker.sock \
"${TRIVY_IMAGE}" image \
--severity HIGH,CRITICAL --exit-code 1 \
cleveragents-server:test
# Also generate a detailed report for visibility
# Also surface a detailed (non-failing) report for visibility.
echo "=== Detailed Trivy Scan Report ==="
trivy image --format table cleveragents-server:test || true
docker run --rm \
-v /var/run/docker.sock:/var/run/docker.sock \
"${TRIVY_IMAGE}" image \
--format table \
cleveragents-server:test || true
helm:
needs: load-versions