Must-share information (formatted with Markdown):
-
which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
Using SonarQube 10.3, but it does not matter for the issue at hand. -
how is SonarQube deployed: zip, Docker, Helm
Docker -
what are you trying to achieve
Calling sonarqube-scan-action from a GitHub workflow. -
what have you tried so far to achieve this
N/A
Do not share screenshots of logs – share the text itself (bonus points for being well-formatted)!
An example of how to get a description for the analysis is to send the first line of the git commit message as the sonar.projectDescription property. I.e.
- name: SonarQube Scan
uses: sonarsource/sonarqube-scan-action@master
env:
SONAR_TOKEN: the-sonar-token
SONAR_HOST_URL: http://the-sonar-host.url/
with:
args: >
-Dsonar.projectKey=myrepo
-Dsonar.projectDescription='${{env.git_message}}'
-Dsonar.projectVersion='${{env.git_hash}}'
Where env.git_message and env.git_hash is prepared to contain the message and commit hash.
As the commit message can contain any characters, it can contain back-ticks, parenthesis, quotation etc that will be interpreted by the shell in the actions’ entrypoint.sh.
As the GitHub action that is doing the scanning likely have privileged access to the SonarQube service, an ill minded user could craft a commit message is such a way that could cause a DoS attack on the service.
Please note that commit message is just an example of why an eval of the $INPUT_ARGS variable is a bad solution in the entrypoint.sh script. Any argument supplied to the GitHub action that is coming from the analyzed code tree could introduce similar problems.