Investigate intermittent Trivy SAST failures on Forgejo runners #255

Open
opened 2026-05-30 08:26:50 +00:00 by simon · 0 comments
Owner

What happened

On PR #254, the SAST workflow reported failures for both Trivy jobs:

  • SAST / trivy (filesystem) failed after 1m42s
  • SAST / trivy (config / IaC) failed after 1m41s

The Forgejo public run page shows the failing steps are the Trivy scan commands themselves, but does not expose step logs without an authenticated web session. Other checks for the PR passed, including gitleaks, web lint/type/build, web Docker image, semgrep, gosec, crypto-lint, and Docker image detection.

Evidence

I reproduced the same Trivy version locally on the replacement branch feat/ct-automation-credential-management-v2 using equivalent commands:

docker run --rm -v "$PWD:/work" -v /tmp/ct-ops-trivy-cache:/root/.cache/trivy -w /work aquasec/trivy:0.70.0 fs --format sarif --output /tmp/trivy-fs.sarif --severity CRITICAL,HIGH,MEDIUM --ignore-unfixed --exit-code 0 --skip-dirs .git --skip-dirs node_modules .
docker run --rm -v "$PWD:/work" -v /tmp/ct-ops-trivy-cache:/root/.cache/trivy -w /work aquasec/trivy:0.70.0 config --format sarif --output /tmp/trivy-config.sarif --severity CRITICAL,HIGH,MEDIUM --exit-code 0 .

Both local commands exited 0. The workflow commands also specify --exit-code 0, so vulnerability or misconfiguration findings should not fail these jobs. This points to runner registry/cache/network behavior, Trivy DB/check bundle download behavior, or missing logs/access rather than the PR diff.

Suggested fix

Inspect the authenticated Trivy step logs for run 2228 on PR #254 and make the SAST workflow resilient to transient Trivy DB/check bundle fetch failures if that is the cause. Also consider publishing enough log output in the public page or artifact to distinguish scanner findings from infrastructure failures.

## What happened On PR #254, the SAST workflow reported failures for both Trivy jobs: - `SAST / trivy (filesystem)` failed after 1m42s - `SAST / trivy (config / IaC)` failed after 1m41s The Forgejo public run page shows the failing steps are the Trivy scan commands themselves, but does not expose step logs without an authenticated web session. Other checks for the PR passed, including gitleaks, web lint/type/build, web Docker image, semgrep, gosec, crypto-lint, and Docker image detection. ## Evidence I reproduced the same Trivy version locally on the replacement branch `feat/ct-automation-credential-management-v2` using equivalent commands: ```bash docker run --rm -v "$PWD:/work" -v /tmp/ct-ops-trivy-cache:/root/.cache/trivy -w /work aquasec/trivy:0.70.0 fs --format sarif --output /tmp/trivy-fs.sarif --severity CRITICAL,HIGH,MEDIUM --ignore-unfixed --exit-code 0 --skip-dirs .git --skip-dirs node_modules . docker run --rm -v "$PWD:/work" -v /tmp/ct-ops-trivy-cache:/root/.cache/trivy -w /work aquasec/trivy:0.70.0 config --format sarif --output /tmp/trivy-config.sarif --severity CRITICAL,HIGH,MEDIUM --exit-code 0 . ``` Both local commands exited 0. The workflow commands also specify `--exit-code 0`, so vulnerability or misconfiguration findings should not fail these jobs. This points to runner registry/cache/network behavior, Trivy DB/check bundle download behavior, or missing logs/access rather than the PR diff. ## Suggested fix Inspect the authenticated Trivy step logs for run 2228 on PR #254 and make the SAST workflow resilient to transient Trivy DB/check bundle fetch failures if that is the cause. Also consider publishing enough log output in the public page or artifact to distinguish scanner findings from infrastructure failures.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
carrtech/ct-ops#255
No description provided.