Are you affected?
Your workflow may be vulnerable if it passes user-controlled or computed values into the args field of the sonarqube-scan-action using shell variable syntax. For example:
- name: SonarQube Scan
uses: SonarSource/sonarqube-scan-action@v5.3.0
env:
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
SONAR_HOST_URL: ${{ vars.SONAR_HOST_URL }}
with:
args: >
-Dsonar.branch.name=${{ github.head_ref }}
If the value of github.head_ref were constructed to include a shell command, that command would have been executed when the action calculated the value for sonar.branch.name. v5.3.1 prevents this by treating the entire input as a literal string, which mitigates the vulnerability.
Additional Resources:
Do I need to update my workflow beyond upgrading the action version?
Most users will only need to make sure that they are using a patched version of sonarqube-scan-action. However, some users may have been intentionally using inline shell commands which will no longer work. You must now precompute such values earlier in your workflow.
Example of required workflow change:
Previously (v5.3.0):
- name: SonarQube Scan
uses: SonarSource/sonarqube-scan-action@v5.3.0
env:
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
SONAR_HOST_URL: ${{ vars.SONAR_HOST_URL }}
with:
args: >
-Dsonar.projectKey=prefix_$(basename "${{ github.repository }}")
After upgrading (v5.3.1):
- name: Compute project key
run: |
PROJECT_SUFFIX=$(basename "${{ github.repository }}")
echo "PROJECT_KEY=prefix_${PROJECT_SUFFIX}" >> "$GITHUB_ENV"
- name: SonarQube Scan
uses: SonarSource/sonarqube-scan-action@v5.3.1
env:
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
SONAR_HOST_URL: ${{ vars.SONAR_HOST_URL }}
with:
args: >
-Dsonar.projectKey=${{ env.PROJECT_KEY }}