fix trivy vulnerability DB update outage

.gitea/workflows/image-security-checks.yml

@@ -61,10 +61,34 @@ jobs:
 
           FULL_IMAGE="${{ secrets.DOCKER_REGISTRY }}/${{ inputs.image_name }}:${{ inputs.image_tag }}"
 
+          # Trivy's default vulnerability-DB source (mirror.gcr.io/aquasec/trivy-db) is a
+          # Google-hosted cache of the upstream GHCR image, used to dodge GHCR's unauthenticated
+          # rate limits. That cache occasionally 404s on a specific layer digest (a known,
+          # recurring upstream issue: aquasecurity/trivy). Point at the canonical GHCR source
+          # instead, and retry the DB download alone a few times — trivy exits 1 both for "DB
+          # download failed" and for "vulnerabilities found", so the download is a separate step
+          # from the scan to keep those two outcomes distinguishable.
+          export TRIVY_DB_REPOSITORY="ghcr.io/aquasecurity/trivy-db:2"
+          export TRIVY_JAVA_DB_REPOSITORY="ghcr.io/aquasecurity/trivy-java-db:1"
+
+          echo "=== Ensuring vulnerability DB is up to date ==="
+          db_attempt=1
+          db_max_attempts=3
+          until trivy image --download-db-only; do
+            if [ "$db_attempt" -ge "$db_max_attempts" ]; then
+              echo "=== Failed to download the Trivy vulnerability DB after ${db_max_attempts} attempts ==="
+              exit 1
+            fi
+            echo "=== DB download failed, retrying (${db_attempt}/${db_max_attempts})... ==="
+            db_attempt=$((db_attempt + 1))
+            sleep $((db_attempt * 5))
+          done
+
           echo "=== Scanning ${FULL_IMAGE} (fail on fixable ${{ inputs.scan_severity }}) ==="
           trivy image \
             --exit-code 1 \
             --severity "${{ inputs.scan_severity }}" \
             --ignore-unfixed \
+            --skip-db-update \
             --scanners vuln,secret \
             "${FULL_IMAGE}"