fix(ci): make the periodic security scan actually report findings - #834
Merged
Conversation
The weekly periodic-security-scan has never filed an issue. Two independent problems, both fixed here. First, the scan steps relied on anchore/scan-action's default fail-build: true with a "low" severity cutoff and no only-fixed, so the SARIF scan failed on essentially any finding and aborted the job. Only "Upload SARIF to GitHub Security" survived via if: always(); the JSON scan, the count check, and the issue-filing step were all skipped. Both scan steps now set fail-build: false so the check step decides the outcome instead of the scanner aborting the job. Second, the thresholds did not match the publish gate. build-containers blocks publishing at severity-cutoff: high with only-fixed: true, while this workflow scanned at low without only-fixed and then filed an issue only when critical > 0. A high finding was therefore enough to block a release but produced no notification, and the already-computed "high" output went unused. Both scan steps now use severity-cutoff: high with only-fixed: true, and should_create_issue is true when critical + high is greater than zero. Also lists the top high-severity findings in the issue body alongside the criticals, and updates step names and summary wording to match the new thresholds. Issue dedup and labels are unchanged. Refs #829 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Aligning both scan steps with the publish gate would have narrowed the Security tab: only-fixed drops findings that have no fix available, and the periodic-grype-* categories currently carry them. Keep only-fixed on the JSON step, which drives the issue-filing decision and should match what blocks a publish, and leave the SARIF feed broad so existing code scanning coverage is unchanged.
Now that a high finding can file an issue, a fixed label array would mark high-only issues as critical. Build the list from the counts instead, so critical and high are applied only when present. security and grype stay unconditional since the dedup query matches on them.
JAORMX
approved these changes
Aug 5, 2026
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
2 participants
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.
Closes #829
The weekly scan has failed every run for at least five weeks and has never filed an issue. Two independent problems, both fixed here.
1. The job aborted before it could report. The SARIF scan step ran at
severity-cutoff: lowwith nofail-build, andanchore/scan-actiondefaults that totrue, so it failed on essentially any finding.Upload SARIFsurvived onif: always(), but the JSON scan, the count check, and the issue creation were all skipped. Both scan steps now setfail-build: falsesoCheck for critical or high issuesdecides the outcome.2. Its alerting threshold sat above the publish gate.
build-containersblocks at high, while this filed issues only on critical, so a finding serious enough to block a publish produced no notification.highwas already computed and then unused. The gate is nowcritical + high > 0, and the JSON step matches the publish gate exactly (severity-cutoff: high,only-fixed: true).The SARIF feed stays deliberately broad. Aligning it too would have narrowed the Security tab, since
only-fixeddrops findings with no available fix and theperiodic-grype-*categories carry them today. It keeps onlyfail-build: false. Worth knowing:severity-cutoffonly feeds grype's--fail-onand does not filter the report, soonly-fixedis the setting that would have cost coverage.Also here: issues are labelled by what was actually found rather than always
critical, and the issue body gained a high-severity detail block, since "5 high" with no specifics is not actionable.Verification
This cannot be exercised without a scheduled run, so the checks are static:
fail-builddoes default to"true", confirming the mechanism;severity-cutoffis only passed as--fail-onand does not filter output, so the jq counts stay correct.actionlintis not installed here, so it was not run..matches, givingshould_create_issue=falserather than an arithmetic error.Upload SARIFandUpload scan resultskeepif: always().🤖 Generated with Claude Code