Skip to content
Open
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
2 changes: 1 addition & 1 deletion .github/workflows/release.yml
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ jobs:
release_created: ${{ steps.release.outputs.release_created }}
steps:
- id: release
uses: googleapis/release-please-action@v4
uses: googleapis/release-please-action@v5

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:

googleapis/release-please-action@v5 is a mutable tag, so if v5 is repointed, your release workflow will run attacker-controlled code with repository write permissions.

More details about this

release_please runs googleapis/release-please-action@v5, which is a movable tag, not a fixed commit. Anyone who can repoint v5 in that action's repository can change what code runs in this workflow the next time push to main or workflow_dispatch triggers it.

A plausible attack looks like this:

  1. An attacker compromises the googleapis/release-please-action project or one of its maintainers and retags v5 to a malicious commit.
  2. Your release workflow starts and the release step pulls that new code because it uses googleapis/release-please-action@v5.
  3. That step runs with contents: write and pull-requests: write, so the malicious action can use the job token to push code, alter tags, or open/update release PRs in this repository.
  4. Because release_please feeds the rest of the release pipeline, the attacker can turn a normal release run into a repository takeover or ship a tampered release from your main branch.

The risk here is not theoretical: this exact line allows whatever commit v5 points to at runtime to execute with write access in your release process.

To resolve this comment:

✨ Commit fix suggestion
  1. Replace the mutable action tag with a full 40-character commit SHA in the uses line for googleapis/release-please-action.
    Change uses: googleapis/release-please-action@v5 to uses: googleapis/release-please-action@<40-character-commit-sha>.

  2. Choose the SHA from the exact upstream release-please-action version you intend to keep using, and keep the version as a comment for readability.
    For example: uses: googleapis/release-please-action@0123456789abcdef0123456789abcdef01234567 # v5.x.y.

  3. Keep the existing with: settings unchanged after the pin.
    Pinning to a commit SHA prevents the action owner from silently moving v5 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:
target-branch: main

Expand Down
Loading