ci(security-scan): make trivy-fs print the finding on failure#373
Closed
seonghobae wants to merge 1 commit into
Closed
ci(security-scan): make trivy-fs print the finding on failure#373seonghobae wants to merge 1 commit into
seonghobae wants to merge 1 commit into
Conversation
trivy-fs ran with format:sarif + exit-code:1, so every failure surfaced in the run log only as "Process completed with exit code 1" — the actual CVE/secret/misconfig went to trivy-results.sarif and was never printed. A human reading the log could not tell WHY the required gate failed (verified on ContextualWisdomLab/aFIPC PRs #108/#111/#115/#117: a HIGH AsymmetricPrivateKey secret in a vendored openssl doc, invisible in the log). The scan now writes SARIF with exit-code:0, and a new "Report Trivy findings and gate" step parses the SARIF, prints each FIXABLE CRITICAL/HIGH finding (rule, severity, path:line, message) into the run log, and fails the job when any exist. Same hard-gate behavior, now with a visible reason. SARIF upload to code scanning is unchanged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RTAMs4bpSZS77Xe3RQjv9P
Contributor
Author
|
Superseded by #382 and the narrower Trivy log-printing path folded into it. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem (grounded in real run logs)
The central required
trivy-fsgate runs withformat: sarif+exit-code: "1". When it fails, the run log shows only:The actual finding goes to
trivy-results.sarifand is never printed to the log — a human cannot see WHY the required workflow blocked the PR.Verified on
ContextualWisdomLab/aFIPCPRs #108 / #111 / #115 / #117 (run 28911486111, job 85769621932): the opaque failure is a HIGHAsymmetricPrivateKeysecret in the vendored filepackrat/lib/.../openssl/doc/keys.html(an upstream openssl doc example key — a verified false positive already scoped-suppressed on aFIPCmastervia #116). Nothing in the log said so.Fix
exit-code: "0"(produce results, don't fail here).Report Trivy findings and gatestep parses the SARIF, prints each FIXABLE CRITICAL/HIGH finding —rule / severity / path:line / message— into the run log, andexit 1s when any exist.Same hard-gate behavior; the reason is now always visible. Verified the gate's
jqagainst a real Trivy SARIF (prints both findings) and the clean case (exits 0).actionlintclean, YAML valid.🤖 Generated with Claude Code