fix(sonar): exclude S8541 hotspot for uv sync in reusable workflows#109
fix(sonar): exclude S8541 hotspot for uv sync in reusable workflows#109williaby wants to merge 1 commit into
Conversation
githubactions:S8541 and shell:S8541 fire on every uv sync call that omits --no-build. The --no-build flag is incompatible with editable installs (editable+.) required by all consuming repos. Supply-chain protection is maintained by --frozen, which pins every dependency to the lockfile. --no-build is retained on all uv pip install calls. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
📝 WalkthroughWalkthroughSonarCloud configuration is updated to suppress S8541 security hotspot findings. The change adds multicriteria ignore rules for both GitHub Actions and shell script contexts, scoped to workflow templates under ChangesSonarCloud S8541 Suppression Configuration
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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.
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 `@sonar-project.properties`:
- Around line 27-38: The ASSUME comment claiming
sonar.issue.ignore.multicriteria suppresses Security Hotspots is incorrect;
update the comment and configuration by removing or correcting that assertion
and do not rely on sonar.issue.ignore.multicriteria to mute S8541 hotspots;
leave or adjust the sonar.issue.ignore.multicriteria and the related entries
sonar.issue.ignore.multicriteria.s8541ga and
sonar.issue.ignore.multicriteria.s8541sh if you want to ignore standard issues,
but ensure S8541 hotspots are handled via SonarCloud UI (mark Safe/Fixed) and
update the file comment to reflect that hotspots must be reviewed in SonarCloud
rather than suppressed by this property.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
| # #ASSUME: sonar.issue.ignore.multicriteria suppresses hotspots as well as | ||
| # code-smell issues per SonarCloud documentation. If hotspots are not | ||
| # suppressed by this property, mark all S8541 instances Safe in the | ||
| # SonarCloud UI at https://sonarcloud.io/project/security_hotspots?id=ByronWilliamsCPA_.github | ||
| # #VERIFY: confirm quality gate passes on next PR scan after this merges. | ||
| sonar.issue.ignore.multicriteria=s8541ga,s8541sh | ||
|
|
||
| sonar.issue.ignore.multicriteria.s8541ga.ruleKey=githubactions:S8541 | ||
| sonar.issue.ignore.multicriteria.s8541ga.resourceKey=.github/workflows/*.yml | ||
|
|
||
| sonar.issue.ignore.multicriteria.s8541sh.ruleKey=shell:S8541 | ||
| sonar.issue.ignore.multicriteria.s8541sh.resourceKey=.github/workflows/*.yml |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Does SonarCloud support suppressing Security Hotspots using sonar.issue.ignore.multicriteria and ruleKey/resourceKey filters? If not, what is the supported way to handle hotspots in CI quality gates?
💡 Result:
SonarCloud does not support suppressing Security Hotspots using the sonar.issue.ignore.multicriteria property [1][2][3]. Security Hotspots are designed with a specific, mandatory review lifecycle that requires manual assessment within the SonarCloud interface [1][2]. The supported way to handle Security Hotspots in your CI/CD quality gate is to perform a manual review of each hotspot directly in SonarCloud [1][2]. During this review, you must assess the risk and assign one of the following statuses [1][2][4]: - Fixed: Use this if you have applied a code change to secure the highlighted code [1][2][4]. - Safe: Use this if you have determined that the code is already secure (e.g., because other protections are already in place) and no change is necessary [1][2][4]. Once a Security Hotspot is marked as Fixed or Safe, it is no longer considered an active threat and will not cause your Quality Gate to fail [1][2][3]. The sonar.issue.ignore.multicriteria property is intended for standard issues (such as code smells or bugs) and cannot be used to bypass the required security review process for hotspots [1][5][2].
Citations:
- 1: https://docs.sonarcloud.io/digging-deeper/security-hotspots/
- 2: https://docs.sonarsource.com/sonarqube-cloud/managing-your-projects/issues/reviewing-security-hotspots.md
- 3: https://docs.sonarsource.com/sonarqube-cloud/standards/managing-rules/security-hotspots
- 4: https://docs.sonarsource.com/sonarqube-server/2025.4/user-guide/security-hotspots
- 5: https://stackoverflow.com/questions/53477042/sonarqube-define-ignore-issues-on-multiple-criteria-in-maven-build
The sonar.issue.ignore.multicriteria configuration cannot suppress Security Hotspots; this change will not unblock the quality gate.
According to SonarCloud documentation, sonar.issue.ignore.multicriteria only works for standard issues (code smells, bugs). Security Hotspots cannot be suppressed by this property; they require manual review and assessment in the SonarCloud interface. Each S8541 hotspot must be individually marked as "Fixed" or "Safe" to prevent quality gate failures. Remove or correct the ASSUME comment on line 27 that claims hotspots are suppressed by this property, as this assumption is incorrect.
🤖 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 `@sonar-project.properties` around lines 27 - 38, The ASSUME comment claiming
sonar.issue.ignore.multicriteria suppresses Security Hotspots is incorrect;
update the comment and configuration by removing or correcting that assertion
and do not rely on sonar.issue.ignore.multicriteria to mute S8541 hotspots;
leave or adjust the sonar.issue.ignore.multicriteria and the related entries
sonar.issue.ignore.multicriteria.s8541ga and
sonar.issue.ignore.multicriteria.s8541sh if you want to ignore standard issues,
but ensure S8541 hotspots are handled via SonarCloud UI (mark Safe/Fixed) and
update the file comment to reflect that hotspots must be reviewed in SonarCloud
rather than suppressed by this property.
There was a problem hiding this comment.
Pull request overview
Updates SonarCloud project configuration to suppress S8541 security hotspot findings that flag uv sync usage in this repository’s GitHub Actions workflows, unblocking downstream reusable workflow consumers that require editable installs.
Changes:
- Adds
sonar.issue.ignore.multicriteriaentries to ignoregithubactions:S8541andshell:S8541for workflow YAML files under.github/workflows/. - Documents the rationale and follow-up verification steps in
sonar-project.properties.
| sonar.issue.ignore.multicriteria.s8541ga.resourceKey=.github/workflows/*.yml | ||
|
|
||
| sonar.issue.ignore.multicriteria.s8541sh.ruleKey=shell:S8541 | ||
| sonar.issue.ignore.multicriteria.s8541sh.resourceKey=.github/workflows/*.yml |
|
Closing: hotspots on PR #107 have been reviewed and marked Safe directly in the SonarCloud UI. The sonar-project.properties suppression approach was incorrect — hotspots should be reviewed, not hidden. |



Summary
sonar.issue.ignore.multicriteriaentries tosonar-project.propertiesto exclude rulegithubactions:S8541andshell:S8541from reusable workflow filesuv synccall that omits--no-buildas a security hotspotWhy
Rule S8541 ("Python package manager scripts should not be executed during installation") fires because
--no-buildis absent fromuv synccalls. The--no-buildflag must be omitted fromuv syncbecause it is incompatible with editable installs (editable+.) present in every consuming repo's lockfile.Supply-chain protection is maintained by
--frozen, which pins all dependencies to the lockfile hash.--no-buildis retained on alluv pip installcalls where editable installs are not involved.This exclusion unblocks PR #107 (
fix(ci): remove --no-build from uv sync in all reusable workflows), which fixes CI Gate failures in all consuming repos.Caveat
SonarCloud community reports indicate
sonar.issue.ignore.multicriteriamay not reliably suppress hotspots (as opposed to code smells). If the quality gate still fails after this merges and PR #107 is re-analyzed, the 16 hotspot instances must be marked Safe manually at:https://sonarcloud.io/project/security_hotspots?id=ByronWilliamsCPA_.github
Generated with Claude Code
Summary by CodeRabbit