chore(deps): bump googleapis/release-please-action from 4 to 5 - #122
chore(deps): bump googleapis/release-please-action from 4 to 5#122dependabot[bot] wants to merge 1 commit into
Conversation
Bumps [googleapis/release-please-action](https://github.com/googleapis/release-please-action) from 4 to 5. - [Release notes](https://github.com/googleapis/release-please-action/releases) - [Changelog](https://github.com/googleapis/release-please-action/blob/main/CHANGELOG.md) - [Commits](googleapis/release-please-action@v4...v5) --- updated-dependencies: - dependency-name: googleapis/release-please-action dependency-version: '5' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
dependabot
Bot
added
dependencies
![semgrep-code-mongodb[bot]](https://avatars.githubusercontent.com/u/45120?s=60&v=4){kind=small}
| steps: | ||
| - id: release | ||
| uses: googleapis/release-please-action@v4 | ||
| uses: googleapis/release-please-action@v5 |
There was a problem hiding this comment.
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:
- An attacker compromises the
googleapis/release-please-actionproject or one of its maintainers and retagsv5to a malicious commit. - Your
releaseworkflow starts and thereleasestep pulls that new code because it usesgoogleapis/release-please-action@v5. - That step runs with
contents: writeandpull-requests: write, so the malicious action can use the job token to push code, alter tags, or open/update release PRs in this repository. - Because
release_pleasefeeds the rest of the release pipeline, the attacker can turn a normal release run into a repository takeover or ship a tampered release from yourmainbranch.
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
-
Replace the mutable action tag with a full 40-character commit SHA in the
usesline forgoogleapis/release-please-action.
Changeuses: googleapis/release-please-action@v5touses: googleapis/release-please-action@<40-character-commit-sha>. -
Choose the SHA from the exact upstream
release-please-actionversion 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. -
Keep the existing
with:settings unchanged after the pin.
Pinning to a commit SHA prevents the action owner from silently movingv5to 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.
Bumps googleapis/release-please-action from 4 to 5.
Release notes
Sourced from googleapis/release-please-action's releases.
... (truncated)
Changelog
Sourced from googleapis/release-please-action's changelog.
... (truncated)
Commits
45996edchore(main): release 5.0.0 (#1200)a8121b9chore: build dist (#1201)f533c26fix: bump release-please from 17.3.0 to 17.6.0 (#1199)46dfc01feat!: upgrade to node24 (#1188)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)