Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions .github/workflows/static-analysis.yml
Original file line number Diff line number Diff line change
Expand Up @@ -88,13 +88,13 @@ jobs:

- name: Upload SARIF report
if: ${{ github.event_name != 'workflow_dispatch' }}
uses: github/codeql-action/upload-sarif@v4
uses: github/codeql-action/upload-sarif@v4.37.3

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Semgrep identified an issue in your code:

github/codeql-action/upload-sarif@v4.37.3 uses a mutable tag, so the action owner or an attacker who compromises that repo could silently swap in different code. That code would run during the SARIF upload step with your CI job’s access to the workspace, token, and workflow data.

More details about this

github/codeql-action/upload-sarif@v4.37.3 is pulled by a version tag, not an exact commit, in the Upload SARIF report step. If the owner of github/codeql-action or anyone who compromises that repository repoints v4.37.3 to different code, this workflow will run the new action code with this job’s permissions when it uploads phpstan.sarif.

A plausible attack looks like this:

  1. An attacker gains control of the github/codeql-action repository or its release process.
  2. They move the v4.37.3 tag so uses: github/codeql-action/upload-sarif@v4.37.3 now resolves to attacker-controlled code.
  3. Your workflow reaches the Upload SARIF report step after composer install and ./vendor/bin/phpstan analyse ... > phpstan.sarif have already run, so the malicious action executes inside your CI job.
  4. That action can read files in the workspace such as phpstan.sarif, inspect environment variables, and use the job’s GitHub token or other available secrets to make API calls.
  5. In the workflow_dispatch path, it also receives ref: ${{ inputs.ref }} and sha: ${{ env.CHECKED_OUT_SHA }}, which gives the attacker extra context about what commit is being analyzed while they exfiltrate data or tamper with results.

Because the reference is mutable, the code that runs in CI can change silently without any workflow diff in your repository.

To resolve this comment:

✨ Commit fix suggestion
  1. Replace the mutable action reference with a full 40-character commit SHA in the uses: line.
  2. Keep the released version as a comment so the pinned commit is still easy to identify, for example: uses: github/codeql-action/upload-sarif@<full-40-char-sha> # v4.37.3.
  3. Get the correct commit SHA from the github/codeql-action repository release or tag page for v4.37.3, and use that exact commit instead of the version tag. Pinning to a commit prevents the action owner from silently changing what runs for the same tag.
💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

  • /fp <comment> for false positive
  • /ar <comment> for acceptable risk
  • /other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by github-actions-mutable-action-tag.

🛟 Help? Slack #semgrep-help or go/semgrep-help.

Resolution Options:

  • Fix the code
  • Reply /fp $reason (if security gap doesn’t exist)
  • Reply /ar $reason (if gap is valid but intentional; add mitigations/monitoring)
  • Reply /other $reason (e.g., test-only)

You can view more details about this finding in the Semgrep AppSec Platform.

with:
sarif_file: phpstan.sarif

- name: Upload SARIF report
if: ${{ github.event_name == 'workflow_dispatch' }}
uses: github/codeql-action/upload-sarif@v4
uses: github/codeql-action/upload-sarif@v4.37.3

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Semgrep identified an issue in your code:

The github/codeql-action/upload-sarif@v4.37.3 step uses a mutable tag, so a repointed tag could make this workflow run attacker-controlled code.

More details about this

github/codeql-action/upload-sarif@v4.37.3 is not pinned to a full 40-character commit SHA, so this workflow trusts whatever code the v4.37.3 tag points to when the Upload SARIF report step runs.

A plausible attack looks like this:

  1. An attacker compromises the github/codeql-action repository or its release process.
  2. They move the v4.37.3 tag to a new commit that keeps the action name the same but adds malicious behavior.
  3. Your workflow reaches uses: github/codeql-action/upload-sarif@v4.37.3 after ./vendor/bin/phpstan analyse creates phpstan.sarif.
  4. The malicious action now runs in your GitHub Actions job with access to the job token and workspace contents, including files produced earlier in the job and values passed in with: such as sarif_file: phpstan.sarif.
  5. In the workflow_dispatch path, the same action also receives ref: ${{ inputs.ref }} and sha: ${{ env.CHECKED_OUT_SHA }}, which could help an attacker tie stolen data or malicious updates to a specific revision.

Because the reference is mutable, the code executed here can change later without any change to this workflow file.

To resolve this comment:

✨ Commit fix suggestion
  1. Replace the mutable action reference github/codeql-action/upload-sarif@v4.37.3 with a full 40-character commit SHA for the exact release you intend to use.
  2. Keep the version as a comment next to the SHA so the workflow stays readable, for example: uses: github/codeql-action/upload-sarif@<full-40-char-sha> # v4.37.3.
  3. Apply the same change to both Upload SARIF report steps, since both currently use the same mutable tag.
  4. Get the correct commit SHA from the github/codeql-action repository release or tag page for v4.37.3, and make sure you use the full SHA, not a shortened one. Pinning to a commit SHA prevents the action owner from silently moving the tag to different code later.
💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

  • /fp <comment> for false positive
  • /ar <comment> for acceptable risk
  • /other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by github-actions-mutable-action-tag.

🛟 Help? Slack #semgrep-help or go/semgrep-help.

Resolution Options:

  • Fix the code
  • Reply /fp $reason (if security gap doesn’t exist)
  • Reply /ar $reason (if gap is valid but intentional; add mitigations/monitoring)
  • Reply /other $reason (e.g., test-only)

You can view more details about this finding in the Semgrep AppSec Platform.

with:
sarif_file: phpstan.sarif
ref: ${{ inputs.ref }}
Expand Down