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/codeql.yml
Original file line number Diff line number Diff line change
Expand Up @@ -35,7 +35,7 @@ jobs:
submodules: recursive

- name: Initialize CodeQL
uses: github/codeql-action/init@v4
uses: github/codeql-action/init@v4.37.1

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/init@v4.37.1 uses a mutable tag, so a retagged release could make this workflow run attacker-controlled code.

More details about this

github/codeql-action/init is referenced by the mutable tag v4.37.1 in the Initialize CodeQL step instead of a specific commit. If the owner of github/codeql-action or anyone who compromises that repository retags v4.37.1, this workflow will run different code on ubuntu-latest with this job's contents: read and security-events: write permissions.

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.1 tag so github/codeql-action/init@v4.37.1 points to a new malicious commit.
  3. When this workflow runs on main, on the weekly schedule, or via workflow_dispatch, the Initialize CodeQL step fetches and executes the attacker's code.
  4. That code runs inside the analyze job and can read the checked-out repository from the earlier actions/checkout@v6 step.
  5. It can also misuse the job token allowed by contents: read and security-events: write, for example by exfiltrating repository contents or uploading fake CodeQL results to hide real problems.

To resolve this comment:

✨ Commit fix suggestion
  1. Replace the mutable action reference with a full 40-character commit SHA in the uses line for this step.
    Change github/codeql-action/init@v4.37.1 to github/codeql-action/init@<40-character-commit-sha>.

  2. Keep the current version as a comment after the SHA so the pinned release is still clear.
    For example: uses: github/codeql-action/init@<40-character-commit-sha> # v4.37.1

  3. Pin the matching CodeQL analyze step to a full commit SHA as well, so both CodeQL steps use immutable references.
    Change github/codeql-action/analyze@v4.37.1 to github/codeql-action/analyze@<40-character-commit-sha> # v4.37.1

  4. Use the commit SHA published for the v4.37.1 release of github/codeql-action, rather than a branch or tag name. This prevents the referenced code from changing without a workflow change.

  5. Alternatively, if you intentionally want to upgrade CodeQL at the same time, pin both steps to the new release’s commit SHA and update the trailing version comment to match.

💬 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:
languages: ${{ matrix.language }}
config: |
Expand All @@ -49,6 +49,6 @@ jobs:
- 'scripts/**'

- name: Perform CodeQL Analysis
uses: github/codeql-action/analyze@v4
uses: github/codeql-action/analyze@v4.37.1

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/analyze@v4.37.1 uses a mutable tag, so a repointed release tag could make this workflow run attacker-controlled code.

More details about this

Perform CodeQL Analysis pulls github/codeql-action/analyze using the tag v4.37.1, not a full 40-character commit SHA. If the owner of github/codeql-action or anyone who can publish that tag repoints v4.37.1 to a different commit, this workflow will run the new code automatically the next time this job starts.

A plausible attack looks like this:

  1. An attacker gains the ability to change the action release tag v4.37.1 in github/codeql-action/analyze.
  2. Your workflow runs uses: github/codeql-action/analyze@v4.37.1 during the Perform CodeQL Analysis step, so GitHub fetches whatever commit that tag points to at that moment.
  3. The attacker-controlled action code executes inside this job with the workflow's permissions, including security-events: write and access to the checked-out repository from the earlier actions/checkout step.
  4. That code could exfiltrate repository contents, read workflow-provided tokens, or submit fake analysis results while appearing to come from your normal CodeQL scan.

Because v4.37.1 is mutable, this step trusts future code changes outside this repository.

To resolve this comment:

✨ Commit fix suggestion
  1. Replace the mutable action reference with a full 40-character commit SHA instead of the version tag.
    Change uses: github/codeql-action/analyze@v4.37.1 to uses: github/codeql-action/analyze@<full-commit-sha>.

  2. Keep the current version as a comment after the SHA so future updates stay readable.
    For example, use uses: github/codeql-action/analyze@<full-commit-sha> # v4.37.1.

  3. Get the SHA from the official github/codeql-action release that corresponds to v4.37.1, and pin exactly that commit rather than a branch or tag name.
    This prevents the referenced action code from changing unexpectedly without a workflow change.

💬 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:
category: "/language:${{matrix.language}}"
Loading