Fix SARIF upload in security workflow#159
Conversation
CVE Lite CLI writes its own partialFingerprints into the SARIF report, and the values differ between runs. GitHub code scanning matches alerts across runs by these fingerprints, so no alert ever matched: every run warned about inconsistent fingerprints and pull requests reported all pre-existing alerts as newly introduced. The upload also pointed at the whole workspace and relied on the timestamped report filename. A new normalize step copies the report to a stable filename and strips the tool fingerprints so the upload action computes consistent ones. Alerts stay distinct through their per-CVE rule IDs.
dosubot
Bot
added
size:XS
WalkthroughThe security workflow now normalizes the newest Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
This PR improves the GitHub Security workflow’s SARIF handling for the OWASP CVE Lite CLI so code scanning alerts remain stable across runs/branches by normalizing the report before upload.
Changes:
- Adds a “Normalize SARIF report” step that copies the newest timestamped CVE Lite SARIF output to a stable
cve-lite.sarif. - Strips
partialFingerprintsfrom SARIF results viajqso the upload action can compute consistent fingerprints. - Uploads SARIF only when a normalized report was actually produced.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| id: sarif | ||
| if: always() | ||
| run: | | ||
| file=$(ls -t cve-lite-scan-*.sarif 2>/dev/null | head -n 1) |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/security.yml:
- Line 38: Update the SARIF file lookup assignment in the workflow step to
tolerate ls returning no matches under set -e and pipefail. Append a safe
fallback so file remains empty and the step continues when no
cve-lite-scan-*.sarif report is produced.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 79e78f5c-0780-493b-a0a9-e65bd2a42466
📒 Files selected for processing (1)
.github/workflows/security.yml
| id: sarif | ||
| if: always() | ||
| run: | | ||
| file=$(ls -t cve-lite-scan-*.sarif 2>/dev/null | head -n 1) |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Prevent step failure when no SARIF report is produced.
GitHub Actions runs bash scripts with set -e -o pipefail by default. If no cve-lite-scan-*.sarif files exist, ls will exit with a non-zero status. Due to pipefail, this causes the assignment and the entire step to fail immediately, breaking your intent to "skip gracefully when no report is produced".
Append || true to the assignment to safely catch the error and allow file to remain empty.
🐛 Proposed fix
- file=$(ls -t cve-lite-scan-*.sarif 2>/dev/null | head -n 1)
+ file=$(ls -t cve-lite-scan-*.sarif 2>/dev/null | head -n 1) || true📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| file=$(ls -t cve-lite-scan-*.sarif 2>/dev/null | head -n 1) | |
| file=$(ls -t cve-lite-scan-*.sarif 2>/dev/null | head -n 1) || true |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/security.yml at line 38, Update the SARIF file lookup
assignment in the workflow step to tolerate ls returning no matches under set -e
and pipefail. Append a safe fallback so file remains empty and the step
continues when no cve-lite-scan-*.sarif report is produced.
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
Problem
The "Code scanning results / CVE Lite CLI" check fails on pull requests, reporting all pre-existing dependency alerts as newly introduced (currently "65 new alerts including 29 errors"), and every Security run emits "inconsistent fingerprint" warning annotations.
CVE Lite CLI writes its own
partialFingerprintsinto the SARIF report, and the values differ between runs. GitHub code scanning matches alerts across runs and branches by these fingerprints, so no alert from a pull request upload ever matches its counterpart onmain— everything counts as new. The upload step also pointedsarif_fileat the whole workspace and relied on the CLI's timestamped report filename.Fix
A normalize step between scan and upload copies the newest report to a stable
cve-lite.sarifand strips the tool'spartialFingerprintswithjq, so the upload action computes consistent, deterministic fingerprints instead. Alerts stay distinct through their per-CVE rule IDs. The upload now targets that exact file and is skipped gracefully if no report was produced.Verified against a locally generated SARIF: all 64 tool fingerprints removed, all results preserved.
Note
The pull request check only settles once this lands on
mainand the Security workflow has run there once, establishing a baseline with consistent fingerprints.Summary by CodeRabbit