githubactions:S8263 rule should be removed

SonarQube Cloud
1

Correct me if I’m wrong, but I believe the githubactions:S8263 rule is invalid and should be removed.

GitHub actions are not vulnerable to injection attacks in this manner, because the arguments are passed in as parameters. This is according to official GitHub documentation on how to prevent script injection attacks: Secure use reference - GitHub Docs

The example of the compliant solution, I believe is also not valid. I have not confirmed this, but I have never seen this syntax anywhere in GitHub docs. This part of the workflow is not bash though, so I don’t think it would actually work.

    steps:
      - name: Example action call
        uses: ./helloaction
        with:
          message: "PR title: $PR_TITLE"
        env:
          PR_TITLE: ${{ github.event.pull_request.title }}

I think you would have to use the following, which would be subject to same “injection attack” that the rule warns about (though it’s not possible)


```yml
    steps:
      - name: Example action call
        uses: ./helloaction
        with:
          message: "PR title: ${{ env.PR_TITLE }}"
        env:
          PR_TITLE: ${{ github.event.pull_request.title }}

There is zero benefit in doing this over using the github context directly in the parameter value.

5

Hi ReenigneArcher & happy new year,

First of all, thanks for your insightful feedback on this rule!

While the underlying security risk is real, the vulnerability does indeed only manifest under specific conditions:

  1. The called action is a composite action or invokes a shell interpreter indirectly (e.g., via a Docker container)
  2. The input is used inside that action in a shell context (e.g., inside a run block)

For actions within projects scanned by SonarQube, we already provide detection for script injections (S7630), so this rule’s primary value lies in flagging risks in external actions.
However, as we currently cannot verify if the required conditions are met, we have decided to exclude this rule for the upcoming release to minimize noise and we will investigate how we can improve the rule for potential future inclusion.

The compliant solution remains still best practice, as it provides protection even when using external actions that may pass inputs to a shell interpreter.

Thanks again for your feedback!

Best wishes,
Teemu R.

1 Like