We are very happy to announce that we have released a new analyzer today on SonarQube Cloud for the Shell family of languages.
This analyzer targets shell scripts (sh & bash) and offers 21 code quality rules for now, 16 of which are active by default in SonarWay. We will be adding code security rules in the very near future to complement this initial offering. At this time, this analyzer will only run on a linux-x64 system. Support for more platforms will come.
These rules are released in beta for the time being, and only in SonarQube Cloud, until we are satisfied with their quality.
We would be extremely grateful if you took the time to enter a comment and share it with us when you report a False-Positive or when you accept an issue, to help us fine-tune the rules for general availability.
Please feel free to post in the community to give us your feedback and viewpoint on these rules and on the analyzer itself in general.
I donât think I ever elected beta rules, when this beta got release it stared breaking all our builds. Is there a way to decline beta rules in the future?
For POSIX shell scripts (those that have a #!/bin/sh shebang) it is failing by requiring use of â[[â instead or â[â ⊠but â[[â is not defiend or supported by POSIX.
Following some reports that the issues raised by this new Shell analyzer are sometimes identified as being on New Code even for old files, we have decided to remove the analyzer until we understand the problem better.
We will communicate again once we know more and are sure we can deploy this analyzer without issues.
I want to apologize for anyone who experienced this behavior and was impacted in their work.
At this time there is no mechanism to disable beta rules by default. We will look into how to make that experience better in the future. As it is, you have the option of disabling the shell analysis completely from the UI, the project properties or the scanner arguments using the sonar.dre.shell.activate property and setting it to false.
I apologize for the disruption. As stated in my second message, we discovered some problem that raised issues in ânew code evenâ though the files had been there for a while and they should have been considered âoverall codeâ, which created more problems for Quality Gates. Was that your case?
And thank you for the feedback on [ vs [[. We will correct that before re-releasing the analyzer!
shelldre:S7674 has the same high security/reliability/maintainability level when it has a functional effect versus when it does not. Contexts like a bare variable assignment foo=$bar and a case statement case $baz in do not perform splitting in any case. While it may be desirable to add quotes anyway, omitting them is not a bug. For contexts like assignment builtins export foo=$bar and redirections <$bar (pathname generation only) the effect depends on the shell.
Also on shelldre:S7674, it is not entirely clear how to deal with cases where splitting is desired. This is moderately common, and do these all need to be marked as false positive?
Also on shelldre:S7674, it incorrectly triggers on things like "${bar:-$baz}". As is, the $baz is quoted because the outer expansion is; changing it to "${bar:-"$baz"}" makes it unspecified by POSIX and some shells will split $baz (e.g. FreeBSD sh sh: Do IFS splitting on word in ${v+word} and ${v-word}. · freebsd/freebsd-src@048f266 · GitHub ). This applies to "${bar:-$baz}", "${bar:+$baz}", "${bar:=$baz}" and "${bar:?$baz}" (and the varieties without the colon). Substring processing like "${bar#$baz}" and "${bar%$baz}" provides a separate quoting state for the inner part, and nested parameters need to be quoted if *, ?, [ and the like are supposed to be literal.
I personally do not agree with shelldre:S7680 (require ${foo} instead of $foo) and would disable the rule.
Thanks for taking the time to post a detailed feedback on those rules!
We are reviewing those two rules. We did reach the conclusion that S7680 should be moved out of SonarWay and thus disabled by default, which will be effective when we deploy the next version.
As for S7674, we are currently taking a good look at it, and your precisions are very much appreciated!
Looking forward to getting this in the normal Sonar Server edition.
We currently use shellcheck, as Iâm sure do many others - what is the crossover with this?
Indeed have you considered integrating shellcheck rules into Sonar so that we can get a consistent experience whether we are using just shellcheck locally or are running Sonar analyses in our CI environment.
Also will this analysis cover code embedded in github actions .yml files?
We plan to use our shell analyzer to scan shell content within Dockerfiles and GitHub Actions as well. This is targeted for completion before the end of 2025. In fact, wherever shell code appears, our shell engine should be able to analyze it.
We explored the possibility of relying on ShellCheck, but its license made this approach unfeasible. While Sonarâs shell rules will overlap with some of ShellCheckâs rules, we will not provide a one-to-one mapping. Our next batch of rules will focus on security issues that ShellCheck does not address.
Once we complete our work on Shell (sh/bash), PowerShell will be our next target.
Ok thanks for that - great that you will be looking at embedded code too.
It would be great if you supported importing shellcheck rules as 3rd part rules even if you canât support them natively. It makes for a much more seamless experience for engineersâŠ
Looking forward to this and powershell (using PSScriptAnalyzer??) in the server edition!
Did this get re-released yesterday? I did not see any communication on it, but we got several PRs (in private repos) failing quality gates in files that arentâ new or changed.
Do you mean you saw issues in files that have been in the repo for a long time? If that is the case, can you tell me if you use shallow or depth-limited clones in your analysis?
If you do, the scanner sometimes fails to discover that the file was always there and considers it ânewâ because
it is the first time it is actually analyzed
it cannot see in the git log when the file was added to the repo and cannot backdate the issue
Our checkout is necessarily shallow, yes. The repo is too large to checkout with full history.
We do see issues in existing files. We also see the new analyzer find issues in files that are downloaded as part of the build and not tracked by git at all though.
Can you please calrify if this scanner logic is specific to the new shell analyzer.
Weâve never had either of the two mentioned kinds of issue with the others, so overall this seems surprising to me.
I donât suppose thereâs a setting to opt-in to only analyze git-tracked files?
Should we generally expect these types of announcements to only be on the community forum and not in right-hand-side panel for âProduct Newsâ?
IMO you should not be assuming a) that people are using github and b) that they will always checkout the .gitignore file in order for your functionality to work.
In a CI environment, you typically have no reason to checkout .gitignore because you arenât changing and checking things in as part of the build.
In large and/or mono repos, you are likely to be very selectively checking out as little as possible to keep the checkout times down, and you ordinarily would not have any reason to include this file.
