Skip to content

Bump the actions group with 2 updates #2519

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dependabot wants to merge 1 commit into
base: master
Choose a base branch
from
+4 −4
Open

Bump the actions group with 2 updates #2519

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -41,7 +41,7 @@ jobs:
go-version: "1.25.0"
# Initializes the CodeQL tools for scanning.
- name: Initialize CodeQL
uses: github/codeql-action/init@v4.37.2 #immutable
uses: github/codeql-action/init@v4.37.3 #immutable

@semgrep-code-mongodb semgrep-code-mongodb Bot Jul 29, 2026

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.3 uses a movable ref, so repointing that tag could make this workflow run attacker-controlled action code.

More details about this

github/codeql-action/init is pulled with the tag v4.37.3 instead of a full 40-character commit SHA. If the v4.37.3 ref is ever repointed upstream, this Initialize CodeQL step would run different code in your workflow with this job's contents: read and security-events: write permissions.

A plausible attack looks like this:

  1. An attacker compromises the github/codeql-action release process or gains permission to move the v4.37.3 ref.
  2. They repoint github/codeql-action/init@v4.37.3 to a malicious commit that still looks like a normal CodeQL init step.
  3. When this analyze job runs on master, release/*, feature/*, or the weekly schedule, GitHub downloads and executes that new action code in the Initialize CodeQL step.
  4. That malicious action can read the checked-out repository contents and use the workflow token's security-events: write access to tamper with CodeQL results or hide real findings before the Perform CodeQL Analysis step runs.

To resolve this comment:

✨ Commit fix suggestion

  1. Replace the mutable action reference github/codeql-action/init@v4.37.3 with a full 40-character commit SHA for that exact release, and keep the readable version as a trailing comment, for example uses: github/codeql-action/init@<40-char-sha> # v4.37.3.

  2. Update the matching CodeQL step references in the same workflow to use the same pinning style, such as github/codeql-action/analyze@<40-char-sha> # v4.37.3, so every third-party action is locked to an immutable revision.

  3. Add a short comment near these steps explaining that actions are pinned to full commit SHAs because tags like v4.37.3 can be moved to different code later. This prevents unreviewed upstream changes from being pulled into the workflow without a code change in this repository.

  4. Get the correct SHA from the action’s release page or repository for v4.37.3, and make sure the SHA belongs to the exact version you intend to use.

Alternatively, if you must keep a version label visible for maintenance, keep the SHA in uses: and put the version only in a comment like # v4.37.3, not in the action reference itself.

💬 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: go
build-mode: manual
Expand All @@ -54,6 +54,6 @@ jobs:

go test -v ./internal/test/compilecheck -run '^TestCompileCheck/go:1\.19$'
- name: Perform CodeQL Analysis
uses: github/codeql-action/analyze@v4.37.2 #immutable
uses: github/codeql-action/analyze@v4.37.3 #immutable

@semgrep-code-mongodb semgrep-code-mongodb Bot Jul 29, 2026

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.3 uses a movable tag, so this CI step could run attacker-controlled code if that tag is repointed.

More details about this

Perform CodeQL Analysis pulls github/codeql-action/analyze@v4.37.3, which is a version tag, not a full 40-character commit SHA. If the v4.37.3 tag is ever moved, this workflow would silently run different code during CI with this job's contents: read and security-events: write permissions.

A plausible attack looks like this:

  1. An attacker compromises the github/codeql-action release process or the upstream account that controls the v4.37.3 tag.
  2. They repoint analyze@v4.37.3 to a new commit that adds malicious logic to the action.
  3. The next time this analyze job runs, the Perform CodeQL Analysis step fetches and executes that new commit automatically because uses: github/codeql-action/analyze@v4.37.3 trusts the movable tag.
  4. That malicious action code can read the checked-out repository contents available in the job and misuse the workflow token permissions, for example by altering uploaded code scanning results via security-events: write or exfiltrating source code over the network during the action run.

Because the reference here is mutable, the code executed in CI can change without any change to this repository.

To resolve this comment:

✨ Commit fix suggestion

  1. Replace the mutable version reference in the uses: line with a full 40-character commit SHA for the same action release.
    Change github/codeql-action/analyze@v4.37.3 to github/codeql-action/analyze@<full-commit-sha> # v4.37.3.

  2. Resolve the SHA from the action’s v4.37.3 release page or release commit, and use that exact commit hash instead of the tag.
    The goal is to pin uses: to a value like github/codeql-action/analyze@0123456789abcdef0123456789abcdef01234567 # v4.37.3.

  3. Keep the trailing version comment after the SHA so future updates are easier to review.
    Pinning to a commit SHA prevents a tag like v4.37.3 from being silently moved 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:
category: "/language:go"
4 changes: 2 additions & 2 deletions .github/workflows/scorecard.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -35,7 +35,7 @@ jobs:
with:
persist-credentials: false
- name: "Run analysis"
uses: ossf/scorecard-action@4eaacf0543bb3f2c246792bd56e8cdeffafb205a # v2.4.3
uses: ossf/scorecard-action@2d1146689b8cda280b9bc96326124645441f03bc # v2.4.4
with:
results_file: results.sarif
results_format: sarif
Expand Down Expand Up @@ -66,6 +66,6 @@ jobs:
# Upload the results to GitHub's code scanning dashboard (optional).
# Commenting out will disable upload of results to your repo's Code Scanning dashboard
- name: "Upload to code-scanning"
uses: github/codeql-action/upload-sarif@v4.37.2 #immutable
uses: github/codeql-action/upload-sarif@v4.37.3 #immutable

@semgrep-code-mongodb semgrep-code-mongodb Bot Jul 29, 2026

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:

Upload to code-scanning uses github/codeql-action/upload-sarif@v4.37.3, which is a movable tag rather than an exact commit. If that tag is repointed, the workflow could silently run attacker-controlled code with this job's access.

More details about this

github/codeql-action/upload-sarif@v4.37.3 pulls the upload-sarif action by tag name, not by a full 40-character commit SHA. If someone who can publish github/codeql-action retags v4.37.3 to a different commit, this Upload to code-scanning step would run that new code with this workflow's permissions and access to results.sarif.

A plausible attack looks like this:

  1. An attacker compromises the action's release process or maintainer account for github/codeql-action.
  2. They move the v4.37.3 tag to a commit that adds malicious code inside upload-sarif.
  3. On the next workflow run, uses: github/codeql-action/upload-sarif@v4.37.3 fetches the attacker's commit because the workflow trusts the tag name.
  4. That malicious action runs in the Upload to code-scanning step and can read files available in the job, including results.sarif, inspect environment values, and use the job's GitHub token to send data out or make repository API calls.
  5. From the repository's point of view, this happens during a normal scan upload, so the malicious behavior is easy to miss.

To resolve this comment:

✨ Commit fix suggestion

  1. Replace the mutable version reference in the uses: line with a full 40-character commit SHA for the same github/codeql-action release.
    Change github/codeql-action/upload-sarif@v4.37.3 to github/codeql-action/upload-sarif@<40-character-commit-sha>.

  2. Keep the human-readable version as a trailing comment so future upgrades are easier to track, for example:
    uses: github/codeql-action/upload-sarif@<40-character-commit-sha> # v4.37.3

  3. Get the SHA from the exact upstream release or tag you intend to trust, and make sure it is the commit that v4.37.3 currently points to.
    Pinning to a commit SHA prevents the action owner from silently moving the tag to different code later.

  4. Update any nearby workflow comment that says this reference is immutable, because @v4.37.3 is still a movable tag and does not satisfy this rule unless it is replaced with the full commit SHA.

💬 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: results.sarif
Loading