chore(deps): bump actions/checkout from 6 to 7#1238
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
the
github_actions
dependabot
Bot
requested review from
sc-david-voisin
and removed request for
a team
![semgrep-code-scalingo[bot]](https://avatars.githubusercontent.com/u/4868969?s=60&v=4){kind=small}
| runs-on: windows-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 action could run attacker code in these release jobs and tamper with published artifacts.
More details about this
actions/checkout@v7 is a movable reference in this release workflow, so the code that runs in the releases and releases-windows jobs can change without any diff in this repository. If the owner of actions/checkout — or anyone who gains control of that action's publishing — repoints v7 to a malicious commit, that new code would run before goreleaser/goreleaser-action@v7 and before the jobs use ${{ secrets.GITHUB_TOKEN }}.
A plausible attack looks like this:
- An attacker compromises the action supply chain and moves the
v7tag foractions/checkoutto attacker-controlled code. - You push a new Git tag, so the
releasesandreleases-windowsjobs start because ofif: ${{ github.ref_type == 'tag' }}. - The step
- uses: actions/checkout@v7downloads and executes the attacker's updated action code on both runners. - That malicious code can read the checked-out repository, inspect the workspace, and use the job's network access to exfiltrate data.
- In the same job, the attacker can target
${{ secrets.GITHUB_TOKEN }}from theRun GoReleaserstep or tamper with files that GoReleaser will package, turning your release process into a backdoor distribution channel.
Because this workflow builds tagged releases, a silently repointed actions/checkout@v7 could let an attacker alter the exact code and artifacts you publish.
To resolve this comment:
✨ Commit fix suggestion
| - uses: actions/checkout@v7 | |
| - uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608 |
View step-by-step instructions
-
Replace the mutable action reference
actions/checkout@v7with a full 40-character commit SHA for the exactactions/checkoutrelease you want to trust.
For example, change it touses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608only if that SHA matches the release you intend to use. -
Get the correct SHA from the
actions/checkoutGitHub releases or tags page, then copy the commit ID that thev7tag points to.
Pinning to a commit SHA prevents the action owner from silently moving the tag later. -
Apply the same replacement to each
actions/checkout@v7step shown in this workflow so both jobs use the pinned commit:
- uses: actions/checkout@<40-character-commit-sha> -
Keep the existing
with:block unchanged, includingfetch-depth: 0, because only theuses:reference needs to be pinned.
💬 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.
You can view more details about this finding in the Semgrep AppSec Platform.
| runs-on: ubuntu-24.04 | ||
| 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 tag could run attacker-controlled code in your release jobs with repository write access.
More details about this
actions/checkout@v7 pulls whatever code the v7 tag points to at runtime instead of a specific commit. In this releases job, that action runs before GoReleaser and has access to the checked-out repository plus the job’s contents: write permission, so if the v7 tag were ever repointed to attacker-controlled code, that code would execute during your release pipeline.
A plausible attack looks like this:
- An attacker compromises the
actions/checkoutaction or gains the ability to move itsv7tag to a different commit. - Your workflow starts on a tag push (
if: ${{ github.ref_type == 'tag' }}) and runs- uses: actions/checkout@v7in thereleasesjob. - GitHub resolves
@v7to the attacker’s commit, and the malicious action code runs onubuntu-24.04inside your release job. - That code can read the repository contents fetched by
actions/checkout, use the job’scontents: writepermission to alter release artifacts or create/update a GitHub release, and accessGITHUB_TOKENlater exposed to the GoReleaser step. - The result is a supply-chain compromise where users download a release produced or modified by attacker-controlled code, even though your workflow file still says
actions/checkout@v7.
The same risk also appears in the releases-windows job, which uses the same mutable actions/checkout@v7 reference before building Windows releases.
To resolve this comment:
✨ Commit fix suggestion
| - uses: actions/checkout@v7 | |
| - uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608 | |
| with: | |
| fetch-depth: 0 # required by GoReleaser (https://goreleaser.com/ci/actions/#fetch-all-history) |
View step-by-step instructions
- Replace the mutable action reference
actions/checkout@v7with a full 40-character commit SHA for the exact release you want to trust, for exampleactions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608. - Apply the same change to the other
actions/checkout@v7step shown in this workflow so both checkout steps use the same pinned commit. - Keep the existing
with:block unchanged, so the step still usesfetch-depth: 0after pinning. Pinning to a commit SHA prevents the action owner from silently changing what code runs under the same tag name. - Alternatively, if you need a newer
actions/checkoutrelease than the example SHA, look up the commit behind that release on the action's GitHub releases page and pinuses:to that 40-character SHA instead of the version tag.
💬 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.
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)