Over-riding rule parameter in custom quality profile not working for GitHub Actions rule S7637

[andyn-ff (Andy Normington)]

Make sure to read this post before raising a thread here:

How to Report a False-positive / False-negative

Hey SonarSource Community! False-positives happen, as do false-negatives, and we’re eager to fix them. We are thrilled when our users report problems, so we can make our products better. What is a false-positive (FP)? A false-positive is when an issue is raised unexpectedly on code that should not trigger an issue, or where the suggested action doesn’t make any sense for the code. What is a false-negative (FN)? A false-negative is when an issue should be raised on a piece of code, but isn’t. …

Then tell us:

• What language is this for?
• Which rule?
• Why do you believe it’s a false-positive/false-negative?
• Are you using
  • SonarQube Cloud?
  • SonarQube Server / Community Build - which version?
  • SonarQube for IDE - which IDE/version?
    • in connected mode with SonarQube Server / Community Build or SonarQube Cloud?
• How can we reproduce the problem? Give us a self-contained snippet of code (formatted text, no screenshots)

I am using SonarQube Cloud and have a false-positive showing up because my custom quality profile is not taking effect.

Rule affected: githubactions:S7637 - language GitHub Actions

I want this rule to be applied only to third-party actions, and not when referencing actions internally. The rule provides a trustedPrefixes parameter which I have over-ridden in my custom quality profile to add to the list of trusted prefixes.

Built-in ‘Sonar way’ quality profile has trustedPrefixes ./,actions/,github/

My custom quality profile has trustedPrefixes ./,actions/,github/,MyOrgName/

I have tried applying this custom quality profile for the github-actions language to specific projects, and then applying it as the default across the organisation. In both cases, I still see security hotspots raised against this rule, for snippets like the below:

- name: Checkout
  uses: actions/checkout@v4
  with:
    submodules: recursive
    token: ${{ secrets.MY_SECRET }}
- uses: MyOrgName/shared-actions/.github/actions/setup-just@main

The security hotspot is raised against the 2nd action here. The first action is ignored properly as it begins with actions/ and that’s in trustedPrefixes.

[Marcin_Stachniuk]

Hi @andyn-ff Thank you for your report and welcome to the community!

I created a ticket Jira and quickly fixed it. It will be available in SonarQube Cloud in few days, depends on when we release our analyzer.

In the meantime please change MyOrgName/ in trustedPrefixes to lowercase: myorgname/. The actions are case insensitive and the issue was in the way how we split trustedPrefixes (the String.lowecase() call was missing).

Best

Marcin