build(deps): bump actions/checkout from 6 to 7#1288
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>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: dependabot[bot] The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
WalkthroughSix Changesactions/checkout v6 → v7 bump
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Suggested labels
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/publish-components-for-e2e-tests.yml (1)
27-33:⚠️ Potential issue | 🔴 Critical
checkout@v7will break fork-based PR e2e testing.This workflow uses
actions/checkout@v7on bothpull_request_target(lines 27-33) and checks out fork repositories viaissue_comment(lines 47-53). As of June 2026, v7 blocks fork checkouts on these events by default to prevent "pwn request" vulnerabilities. External contributor e2e runs will fail unless you either revert to v6, or explicitly addallow-unsafe-pr-checkout: trueto both checkout steps with documented justification.Suggested change
- uses: actions/checkout@v7 + uses: actions/checkout@v6Apply to lines 27 and 48.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/publish-components-for-e2e-tests.yml around lines 27 - 33, The actions/checkout@v7 action blocks fork checkouts on pull_request_target and issue_comment events by default as a security measure, which will cause external contributor e2e runs to fail. Fix this by either downgrading both checkout actions from v7 to v6, or by explicitly adding the allow-unsafe-pr-checkout: true parameter to both the checkout step at lines 27-33 (for pull_request_target) and the checkout step at lines 47-53 (for issue_comment). Choose whichever approach aligns with your security posture and document the justification if using the unsafe flag.Source: Linked repositories
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/ci-build.yml:
- Around line 17-18: The actions/checkout step at the specified location uses a
mutable tag reference (v7) which creates a supply chain attack vector, and the
default behavior allows GITHUB_TOKEN credentials to persist across all
subsequent steps unnecessarily. Replace the mutable tag reference with a pinned
commit SHA for actions/checkout and add the persist-credentials parameter set to
false to the uses statement to disable credential persistence for this workflow
that only requires code checkout for linting and testing.
In @.github/workflows/ci-check-gomod.yml:
- Around line 14-15: The checkout action in the "Checkout code" step uses a
mutable version tag (v7) instead of a pinned SHA, and it's persisting git
credentials when they're not needed. Replace the `actions/checkout@v7` reference
with a pinned SHA commit hash and add `persist-credentials: false` as a
parameter to the checkout step to disable credential persistence and reduce the
attack surface.
In @.github/workflows/govulncheck.yml:
- Around line 13-14: The `actions/checkout` action is using a mutable tag (v7)
which presents a supply chain security risk. Pin the action to a specific commit
SHA instead of the v7 tag, and add the parameter `persist-credentials: false` to
the checkout action configuration since this job only requires read-only access
to the repository and does not need Git credentials to be persisted between
runs.
In @.github/workflows/publish-components-for-e2e-tests.yml:
- Line 28: Both checkout steps (actions/checkout@v7) in this workflow need to be
updated to handle fork pull request checkouts safely. Add
`allow-unsafe-pr-checkout: true` to both checkout steps to opt into the v7
breaking security change that requires explicit approval for checking out fork
PRs with pull_request_target events. Additionally, add `persist-credentials:
false` to both checkout steps as a best practice since the workflow only
performs read operations, and optionally pin to specific commit SHAs instead of
v7 for improved supply chain security.
---
Outside diff comments:
In @.github/workflows/publish-components-for-e2e-tests.yml:
- Around line 27-33: The actions/checkout@v7 action blocks fork checkouts on
pull_request_target and issue_comment events by default as a security measure,
which will cause external contributor e2e runs to fail. Fix this by either
downgrading both checkout actions from v7 to v6, or by explicitly adding the
allow-unsafe-pr-checkout: true parameter to both the checkout step at lines
27-33 (for pull_request_target) and the checkout step at lines 47-53 (for
issue_comment). Choose whichever approach aligns with your security posture and
document the justification if using the unsafe flag.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Enterprise
Run ID: 09769a18-de1c-465d-a046-6652884ed3b5
📒 Files selected for processing (4)
.github/workflows/ci-build.yml.github/workflows/ci-check-gomod.yml.github/workflows/govulncheck.yml.github/workflows/publish-components-for-e2e-tests.yml
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
codeready-toolchain/api(manual)codeready-toolchain/toolchain-common(manual)codeready-toolchain/host-operator(manual)codeready-toolchain/toolchain-e2e(manual)
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Build & push operator bundles & dashboard image for e2e tests
🧰 Additional context used
🪛 zizmor (1.25.2)
.github/workflows/ci-check-gomod.yml
[warning] 14-15: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 15-15: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
.github/workflows/ci-build.yml
[warning] 17-18: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 18-18: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[warning] 37-38: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 38-38: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
.github/workflows/publish-components-for-e2e-tests.yml
[error] 28-28: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[error] 48-48: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
.github/workflows/govulncheck.yml
[warning] 13-14: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 14-14: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🔀 Multi-repo context codeready-toolchain/host-operator, codeready-toolchain/toolchain-common
Linked repositories findings
Critical Security Impact on Fork PR Testing
codeready-toolchain/host-operator [::codeready-toolchain/host-operator::]
Workflow affected by actions/checkout v7 fork protection:
The .github/workflows/publish-components-for-e2e-tests.yml workflow is explicitly designed to checkout code from fork repositories and will be blocked by the new fork protection in v7:
- Lines 5-6: Uses
pull_request_targetevent (one of the events with new fork blocking in v7) - Lines 24-29: First checkout step explicitly pulls from the fork:
with: ref: ${{github.event.pull_request.head.ref}} repository: ${{github.event.pull_request.head.repo.full_name}}
- Lines 45-51: Second checkout also retrieves fork repo details dynamically
- Lines 25, 46: Uses
actions/checkout@v6(not yet updated to v7)
Impact: When upgraded to v7, the actions/checkout action will reject checkout operations for fork pull requests on pull_request_target events. This will break the e2e testing pipeline for external contributors, preventing the workflow from checking out their code.
codeready-toolchain/toolchain-common and codeready-toolchain/host-operator [::codeready-toolchain/toolchain-common::] [::codeready-toolchain/host-operator::]
Workflows using workflow_run event (also affected by v7 fork protection):
Both repos have .github/workflows/upload-coverage.yml files that use the workflow_run event (lines 3-5 in both). These workflows do NOT perform explicit fork checkouts—they download artifacts from a completed workflow run. These are lower risk but should be monitored to ensure artifact downloads from forked workflow runs continue to work as expected.
Summary for Reviewers
The upgrade to actions/checkout v7 introduces a breaking security restriction that blocks checkout of fork repositories for pull_request_target and workflow_run events.
Two repositories are directly affected:
- host-operator: The
publish-components-for-e2e-tests.ymlworkflow will fail for all fork-based PRs because it explicitly checks out code from fork repositories duringpull_request_targetevents. This needs to be updated to use an alternative approach (e.g.,pull_requestevent + token handling or modified workflow logic). - toolchain-common and host-operator: The
upload-coverage.ymlworkflows should be tested to ensureworkflow_runevent artifact downloads still function correctly with v7.
Recommendation: Before merging this PR, ensure that the host-operator and toolchain-common repositories are updated to handle this breaking change, or revert to v6 if fork PR testing is essential to your CI/CD strategy.
| - name: Checkout code | ||
| uses: actions/checkout@v6 | ||
| uses: actions/checkout@v7 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# First, let's see the structure and find the workflow file
find .github/workflows -name "ci-build.yml" -type fRepository: codeready-toolchain/toolchain-e2e
Length of output: 108
🏁 Script executed:
#!/bin/bash
# Read the ci-build.yml file to see the checkout usage
cat -n .github/workflows/ci-build.yml | head -60Repository: codeready-toolchain/toolchain-e2e
Length of output: 1273
🏁 Script executed:
#!/bin/bash
# Check if there are additional checkout uses beyond line 38
cat -n .github/workflows/ci-build.ymlRepository: codeready-toolchain/toolchain-e2e
Length of output: 1273
🌐 Web query:
GitHub Actions checkout mutable tags security risk @v7 pinning to SHA
💡 Result:
Pinning GitHub Actions to a full-length commit SHA is a critical security best practice to mitigate supply chain attacks [1][2][3]. Referencing actions by mutable tags (e.g., @v7) or branches allows the underlying code to be silently updated by repository maintainers or attackers who gain unauthorized access [1][4][3]. By using a full 40-character commit SHA, you ensure the workflow executes a specific, immutable version of the code, preventing "tag-mutation" attacks where malicious code is injected into an existing version tag [2][5][6]. Security Recommendations and Best Practices: 1. Pin to Full SHA: Always use the full 40-character commit SHA for all third-party actions [4][7][3]. 2. Maintain Human-Readability: To retain context, use a trailing comment to indicate the original version tag (e.g., - uses: actions/checkout@de0fac2 # v6.0.2) [2][4][3]. 3. Enforce via Policy: If you manage an organization, use GitHub's organization-level policy to enforce SHA pinning, which causes workflows using non-pinned actions to fail automatically [6][8]. 4. Automate Updates: Manually maintaining SHAs is error-prone. Use tools like Renovate (with the helpers:pinGitHubActionDigests preset) or Dependabot to automatically track and propose updates to pinned SHAs, keeping your actions secure and current without manual overhead [4][5][6]. 5. Defense-in-Depth: SHA pinning is necessary but not always sufficient [1][9]. Ensure your security posture includes least-privilege permissions, OIDC-based authentication, and monitoring, as SHA pinning does not protect against vulnerabilities inherent in the action code itself or actions that dynamically fetch other unpinned dependencies at runtime [1][9][3]. GitHub maintains documentation on these security practices, emphasizing that pinning to a full-length commit SHA is currently the only way to treat an action reference as an immutable asset [10]. While GitHub has introduced an immutable release feature for tags, the industry standard for maximum security remains explicit SHA pinning [11][10].
Citations:
- 1: https://mikael.barbero.tech/blog/post/2026-03-24-stop-trusting-mutable-references/
- 2: https://actsense.dev/vulnerabilities/no_hash_pinning/
- 3: https://www.decryptiondigest.com/blog/github-actions-security-hardening
- 4: https://architecture.lullabot.com/adr/20260505-pin-github-actions-to-hash/
- 5: https://emmer.dev/blog/pin-your-github-actions-to-protect-against-mutability/
- 6: https://www.romainlespinasse.dev/posts/github-actions-commit-sha-pinning/
- 7: https://docs.ozarksecuritylabs.com/supply-chain/tier-1-baseline/sha-pin-actions/
- 8: https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/
- 9: https://rosesecurity.dev/2026/03/24/sha-pinning-is-not-enough.html
- 10: https://github.com/github/docs/blob/962a1c8dccb8c0f66548b324e5b921b5e4fbc3d6/content/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions.md
- 11: Use immutable GitHub release feature actions/checkout#2316
🌐 Web query:
GitHub Actions persist-credentials false best practice when necessary
💡 Result:
Setting persist-credentials: false in the actions/checkout GitHub Action is considered a security best practice for most workflows [1][2][3]. The persist-credentials input defaults to true, which configures the local Git environment with a GITHUB_TOKEN (or a provided PAT) to enable authenticated Git operations [4][2]. When left at its default, this token remains available to all subsequent steps in the job [5][6]. If a workflow is compromised or utilizes insecure third-party actions, those actions could potentially access or misuse the persisted credentials [2][5]. Best Practice Guidance: 1. Default to false: For the majority of workflows that only checkout code and do not perform subsequent Git operations (e.g., git push, git commit), you should explicitly set persist-credentials: false [1][2]. 2. When to use true: Only set persist-credentials: true when your workflow genuinely requires authenticated Git commands to run in later steps [2]. 3. Defense in depth: Even if you must persist credentials, follow the principle of least privilege by using scoped permissions for your GITHUB_TOKEN or restricted service accounts [6][7]. Example of the recommended configuration: - name: Code checkout uses: actions/checkout@v6 with: persist-credentials: false While the official actions/checkout has improved security by storing credentials in a separate file under $RUNNER_TEMP rather than directly in.git/config, explicitly disabling persistence remains the recommended approach to minimize the attack surface of your workflow jobs [4][8].
Citations:
- 1: https://cheatsheetseries.owasp.org/cheatsheets/GitHub_Actions_Security_Cheat_Sheet.html
- 2: https://masteringlaravel.io/daily/2026-06-18-the-security-default-we-change-in-githubs-checkout-action
- 3: https://github.com/suzuki-shunsuke/ghalint/blob/main/docs/policies/013.md
- 4: https://github.com/actions/checkout
- 5: Remove
persist-credentialsor change the default tofalseactions/checkout#485 - 6: Remove
persist-credentialsor change the default tofalseactions/checkout#485 - 7: https://github.com/marketplace/actions/checkout
- 8: https://github.com/actions/checkout/?tab=readme-ov-file
Pin checkout to commit SHA and disable credential persistence.
actions/checkout@v7 uses a mutable tag, which allows supply chain attack vectors through tag mutation. Additionally, the default persist-credentials: true leaves the GITHUB_TOKEN available to all subsequent steps unnecessarily. This workflow only checks out code for linting and testing, so both credentials and mutable tags should be eliminated.
Suggested changes
- uses: actions/checkout@v7
+ uses: actions/checkout@<sha>
+ with:
+ persist-credentials: falseAlso applies to: 37-38
🧰 Tools
🪛 zizmor (1.25.2)
[warning] 17-18: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 18-18: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/ci-build.yml around lines 17 - 18, The actions/checkout
step at the specified location uses a mutable tag reference (v7) which creates a
supply chain attack vector, and the default behavior allows GITHUB_TOKEN
credentials to persist across all subsequent steps unnecessarily. Replace the
mutable tag reference with a pinned commit SHA for actions/checkout and add the
persist-credentials parameter set to false to the uses statement to disable
credential persistence for this workflow that only requires code checkout for
linting and testing.
Source: Linters/SAST tools
| - name: Checkout code | ||
| uses: actions/checkout@v6 | ||
| uses: actions/checkout@v7 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/ci-check-gomod.yml | head -50Repository: codeready-toolchain/toolchain-e2e
Length of output: 531
Pin checkout to a SHA and disable credential persistence.
actions/checkout@v7 uses a mutable tag, and this job doesn't require persisted git credentials since it only checks go.mod replacements. Pin it to a specific SHA and set persist-credentials: false to reduce the attack surface.
Suggested change
- uses: actions/checkout@v7
+ uses: actions/checkout@<sha>
+ with:
+ persist-credentials: false🧰 Tools
🪛 zizmor (1.25.2)
[warning] 14-15: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 15-15: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/ci-check-gomod.yml around lines 14 - 15, The checkout
action in the "Checkout code" step uses a mutable version tag (v7) instead of a
pinned SHA, and it's persisting git credentials when they're not needed. Replace
the `actions/checkout@v7` reference with a pinned SHA commit hash and add
`persist-credentials: false` as a parameter to the checkout step to disable
credential persistence and reduce the attack surface.
Source: Linters/SAST tools
| - name: Checkout code | ||
| uses: actions/checkout@v6 | ||
| uses: actions/checkout@v7 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if the file exists and examine its content
if [ -f ".github/workflows/govulncheck.yml" ]; then
echo "=== File exists ==="
cat -n ".github/workflows/govulncheck.yml"
else
echo "File not found"
find . -name "govulncheck.yml" -o -name "*govuln*"
fiRepository: codeready-toolchain/toolchain-e2e
Length of output: 651
🏁 Script executed:
#!/bin/bash
# Check for other checkout actions in the repo to see the pattern
echo "=== All checkout actions in this repo ==="
rg "actions/checkout@" .github/workflows/ -A 2 -B 1Repository: codeready-toolchain/toolchain-e2e
Length of output: 1775
🏁 Script executed:
#!/bin/bash
# Check if this workflow uses any authenticated operations
echo "=== Checking workflow context and job definition ==="
rg "persist-credentials" .github/workflows/ || echo "No persist-credentials found"Repository: codeready-toolchain/toolchain-e2e
Length of output: 159
🌐 Web query:
actions/checkout v7 best practices security mutable tags persist-credentials
💡 Result:
The actions/checkout v7 release, launched on June 18, 2026, introduces significant security enhancements to default behaviors, particularly regarding pull request handling [1][2]. Below are the key best practices and security considerations: ### 1. Security Enhancements in v7 actions/checkout v7 now blocks checking out fork pull request code by default in pull_request_target and workflow_run events to mitigate common pwn-request vulnerabilities [1][2]. - If your workflow legitimately requires checking out fork pull request code in these contexts, you can opt out of this protection by setting the allow-unsafe-pr-checkout input to true [1][3]. - This option is intentionally named to be easy to identify during code reviews and security audits [1][3]. ### 2. Best Practice: persist-credentials By default, actions/checkout persists Git credentials (specifically the GITHUB_TOKEN or other configured tokens) into the runner’s Git configuration to allow subsequent Git operations [4][5]. - Recommendation: Unless your workflow explicitly requires executing authenticated Git commands (like pushing commits back to the repository), you should always set persist-credentials: false [6][7][8]. - Risk: Leaving this enabled (the default) exposes the credentials to any subsequent step or third-party action within the same job [8][9]. This has historically led to vulnerabilities like "ArtiPACKED," where leaked tokens are inadvertently included in uploaded artifacts [10]. ### 3. Best Practice: Use Immutable Tags To ensure supply chain security, avoid using mutable tags (e.g., actions/checkout@v7) that can be updated by the action owner to point to malicious code [7]. - Recommendation: Pin your actions to a specific, immutable commit SHA [7]. - Example: - uses: actions/checkout@11bd719 ### 4. General Workflow Security - Least Privilege: Ensure your GITHUB_TOKEN has the minimum required permissions using the permissions: key at the job or workflow level [7][11][9]. - Avoid Untrusted Code: Never check out and execute code from untrusted sources (e.g., external forks) in privileged contexts like pull_request_target [6][3][11]. When necessary, always use immutable references (commit SHAs) to point to the exact, audited state of the code [6][11].
Citations:
- 1: https://github.blog/changelog/2026-06-18-safer-pull_request_target-defaults-for-github-actions-checkout/
- 2: https://github.com/actions/checkout/releases/tag/v7.0.0
- 3: https://docs.github.com/en/actions/reference/security/securely-using-pull_request_target
- 4: https://github.com/actions/checkout/?tab=readme-ov-file
- 5: https://github.com/actions/checkout
- 6: https://cheatsheetseries.owasp.org/cheatsheets/GitHub_Actions_Security_Cheat_Sheet.html
- 7: https://getplumber.io/blog/harden-github-supply-chain
- 8: https://actsense.dev/vulnerabilities/unsafe_checkout/
- 9: Remove
persist-credentialsor change the default tofalseactions/checkout#485 - 10: GHSA-3959-6v5q-45q2
- 11: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/GitHub_Actions_Security_Cheat_Sheet.md
Pin checkout to a commit SHA and disable credential persistence.
The actions/checkout@v7 action uses a mutable tag, creating a supply chain security risk. Additionally, this job only reads the repository and doesn't require persisted Git credentials. Pin to a specific commit SHA and set persist-credentials: false.
Suggested change
- name: Checkout code
uses: actions/checkout@v7
+ with:
+ persist-credentials: falseNote: Replace v7 with a pinned commit SHA (e.g., 11bd71901bbe5b1630ceea73d27597364c9af683) to fully secure the action reference.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - name: Checkout code | |
| uses: actions/checkout@v6 | |
| uses: actions/checkout@v7 | |
| - name: Checkout code | |
| uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 | |
| with: | |
| persist-credentials: false |
🧰 Tools
🪛 zizmor (1.25.2)
[warning] 13-14: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 14-14: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/govulncheck.yml around lines 13 - 14, The
`actions/checkout` action is using a mutable tag (v7) which presents a supply
chain security risk. Pin the action to a specific commit SHA instead of the v7
tag, and add the parameter `persist-credentials: false` to the checkout action
configuration since this job only requires read-only access to the repository
and does not need Git credentials to be persisted between runs.
Source: Linters/SAST tools
| # Checkout from PR event | ||
| - name: Checkout code from PR event | ||
| uses: actions/checkout@v6 | ||
| uses: actions/checkout@v7 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if the workflow file exists and examine the checkout steps
if [ -f ".github/workflows/publish-components-for-e2e-tests.yml" ]; then
echo "=== File contents ==="
cat -n .github/workflows/publish-components-for-e2e-tests.yml | head -60
else
echo "File not found in toolchain-e2e"
# Check host-operator as the linked findings suggest it might be there
fiRepository: codeready-toolchain/toolchain-e2e
Length of output: 2454
🏁 Script executed:
#!/bin/bash
# Check the host-operator repo which was mentioned in linked findings
if [ -f ".github/workflows/publish-components-for-e2e-tests.yml" ]; then
echo "=== File from host-operator ==="
cat -n .github/workflows/publish-components-for-e2e-tests.yml | head -60
else
echo "File not found"
fiRepository: codeready-toolchain/host-operator
Length of output: 2656
🌐 Web query:
actions/checkout v7 fork security persist-credentials best practices
💡 Result:
As of June 2026, actions/checkout v7 is the latest major version [1][2]. It introduces significant security improvements regarding how fork pull requests are handled, while maintainining existing best practices for credential persistence [3][4]. Persist-Credentials Best Practices The persist-credentials input defaults to true in all versions, including v7 [5][6]. When true, the GITHUB_TOKEN (or provided SSH key) is configured in the local Git repository's configuration for the duration of the job [5]. While this is convenient for authenticated Git operations (like pushing commits), it poses security risks because subsequent steps or third-party actions in the same job can read these credentials [7][6]. Best practices for persist-credentials: - Explicitly set persist-credentials: false in all workflows unless your job specifically requires authenticated Git write access (e.g., pushing tags or commits back to the repo) [6]. - If you require authenticated Git access, ensure the GITHUB_TOKEN has the minimum necessary permissions [6]. - Rely on the default only when absolutely necessary and limit the scope of subsequent steps to minimize exposure [6]. Fork Security in v7 A major feature of actions/checkout v7 is its improved protection against "pwn request" vulnerabilities in privileged contexts [3][8]. - By default, v7 now refuses to check out fork pull request code when triggered by pull_request_target or certain workflow_run events [3][4]. This prevents malicious fork code from running in the context of the base repository's secrets and permissions [3][4]. - If a workflow genuinely requires this behavior and has been audited for safety, you must explicitly opt-in by setting allow-unsafe-pr-checkout: true [3][4][8]. This input is intentionally named to be prominent during code reviews and security audits [3][4]. For workflows using pull_request_target, GitHub recommends thoroughly reviewing the security implications before enabling allow-unsafe-pr-checkout [3][4]. You should also ensure that your GITHUB_TOKEN permissions are restricted to the minimum level required [4][9].
Citations:
- 1: https://github.com/actions/checkout/releases/tag/v7.0.0
- 2: https://github.com/actions/checkout/releases
- 3: https://github.blog/changelog/2026-06-18-safer-pull_request_target-defaults-for-github-actions-checkout/
- 4: https://docs.github.com/en/actions/reference/security/securely-using-pull_request_target
- 5: https://github.com/actions/checkout/
- 6: https://actsense.dev/vulnerabilities/unsafe_checkout/
- 7: Remove
persist-credentialsor change the default tofalseactions/checkout#485 - 8: block checking out fork pr for pull_request_target and workflow_run actions/checkout#2454
- 9: https://blog.gitguardian.com/github-actions-security-cheat-sheet/
Add allow-unsafe-pr-checkout: true to both checkout steps for v7 compatibility with fork repositories.
actions/checkout v7 introduces a breaking security change: it now refuses to check out fork pull request code when triggered by pull_request_target events unless explicitly opt-in via allow-unsafe-pr-checkout: true. This workflow explicitly checks out fork repositories (lines 31–32 and 51–52), so both checkout steps will fail without this flag.
Additionally, add persist-credentials: false to both steps as a best practice for read-only operations, and optionally pin to commit SHAs for supply chain security.
Suggested change (line 28)
uses: actions/checkout@v7
+ with:
+ ref: ${{github.event.pull_request.head.ref}}
+ repository: ${{github.event.pull_request.head.repo.full_name}}
+ fetch-depth: 0
+ allow-unsafe-pr-checkout: true
+ persist-credentials: falseSuggested change (line 48)
uses: actions/checkout@v7
+ with:
+ repository: ${{ fromJson(steps.request.outputs.data).head.repo.full_name }}
+ ref: ${{ fromJson(steps.request.outputs.data).head.ref }}
+ fetch-depth: 0
+ allow-unsafe-pr-checkout: true
+ persist-credentials: false📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| uses: actions/checkout@v7 | |
| uses: actions/checkout@v7 | |
| with: | |
| ref: ${{github.event.pull_request.head.ref}} | |
| repository: ${{github.event.pull_request.head.repo.full_name}} | |
| fetch-depth: 0 | |
| allow-unsafe-pr-checkout: true | |
| persist-credentials: false |
🧰 Tools
🪛 zizmor (1.25.2)
[error] 28-28: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/publish-components-for-e2e-tests.yml at line 28, Both
checkout steps (actions/checkout@v7) in this workflow need to be updated to
handle fork pull request checkouts safely. Add `allow-unsafe-pr-checkout: true`
to both checkout steps to opt into the v7 breaking security change that requires
explicit approval for checking out fork PRs with pull_request_target events.
Additionally, add `persist-credentials: false` to both checkout steps as a best
practice since the workflow only performs read operations, and optionally pin to
specific commit SHAs instead of v7 for improved supply chain security.
Source: Linters/SAST tools
|
@dependabot[bot]: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |



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)Summary by CodeRabbit