fix: remove pull request target from cla - BED-7555#197
Conversation
WalkthroughUpdated two GitHub workflow files: switched the CLA Assistant workflow trigger and condition from Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/cla.yml:
- Line 36: The current if condition that checks comment bodies allows matching
phrases from any issue comment; tighten it by requiring comment-based checks
only when the event is an issue_comment on a PR: modify the existing conditional
expression (the if statement comparing github.event.comment.body and
github.event_name) to include an additional guard: github.event_name ==
'issue_comment' && github.event.issue.pull_request so that comment-body checks
run only for PR comments, while preserving the existing pull_request branch and
the explicit recheck/signing string handling.
- Around line 5-6: The pull_request trigger causes repository secrets
(READ_MEMBERS_SCOPE, REPO_SCOPE) to be unavailable for forked PRs; update the
workflow to use pull_request_target and issue_comment instead of pull_request
and add a guard to skip CLA for forks: change the workflow triggers to include
pull_request_target (so base-repo runs have access to secrets) and issue_comment
(to allow rechecks), and add a job-level condition (e.g., in the CLA job) using
github.event.pull_request.head.repo.fork == false to bypass the CLA step for
forked PRs; ensure the CLA Assistant job references the same secrets
(READ_MEMBERS_SCOPE, REPO_SCOPE) and only runs when the PR is not from a fork so
secrets remain available.
| pull_request: | ||
| types: [opened,closed,synchronize] |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
GitHub Actions pull_request event fork repository secrets availability
💡 Result:
For workflows triggered by the pull_request event where the PR comes from a fork:
- Repository/Org/Environment secrets are not provided to the workflow run (to prevent exfiltration from untrusted code). The only exception is
GITHUB_TOKEN. [1] - The
GITHUB_TOKENis restricted (effectively read-only) for PRs from forks, even if you normally grant broader permissions. [2]
If you need secrets for PR-related automation, GitHub provides pull_request_target:
pull_request_targetruns in the context of the base (target) repository, using the workflow from the base branch, and it can access repository secrets (and typically has elevated token permissions). This is why it can be used for things like labeling/commenting on PRs. [3]- Security caveat: because it has access to secrets, you must not check out / build / execute untrusted PR code in a
pull_request_targetworkflow unless you’ve designed the workflow to prevent “pwn request” style attacks. [3]
Dependabot note: workflows triggered by Dependabot PRs are treated like fork PRs for these restrictions (read-only token, no secrets) when using events like pull_request. [2]
Sources: [1] GitHub Docs – Using secrets in GitHub Actions; [2] GitHub Changelog – Dependabot PR workflows run with read-only permissions / no secrets; [3] GitHub Well-Architected – Avoid pull_request_target (privileged, secrets available).
🏁 Script executed:
cat -n .github/workflows/cla.yml | head -50Repository: SpecterOps/SharpHound
Length of output: 2157
pull_request trigger breaks CLA checks for forked PRs—repository secrets unavailable.
Switching to pull_request means PRs from forks won't receive READ_MEMBERS_SCOPE (Line 19) or REPO_SCOPE (Line 40) repository secrets. GitHub Actions explicitly excludes non-GITHUB_TOKEN secrets from pull_request events originating from forks as a security measure. This causes the CLA Assistant step to fail silently.
To restore functionality while maintaining security:
Suggested fix
jobs:
CLAssistant:
+ if: github.event_name != 'pull_request' || github.event.pull_request.head.repo.fork == false
runs-on: ubuntu-latestThis skips the CLA check for fork PRs (preventing secret errors) while allowing recheck via issue_comment and running normally for base-repo PRs.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/cla.yml around lines 5 - 6, The pull_request trigger
causes repository secrets (READ_MEMBERS_SCOPE, REPO_SCOPE) to be unavailable for
forked PRs; update the workflow to use pull_request_target and issue_comment
instead of pull_request and add a guard to skip CLA for forks: change the
workflow triggers to include pull_request_target (so base-repo runs have access
to secrets) and issue_comment (to allow rechecks), and add a job-level condition
(e.g., in the CLA job) using github.event.pull_request.head.repo.fork == false
to bypass the CLA step for forked PRs; ensure the CLA Assistant job references
the same secrets (READ_MEMBERS_SCOPE, REPO_SCOPE) and only runs when the PR is
not from a fork so secrets remain available.
|
|
||
| - name: "CLA Assistant" | ||
| if: (github.event.comment.body == 'recheck' || github.event.comment.body == 'I have read the CLA Document and I hereby sign the CLA') || github.event_name == 'pull_request_target' | ||
| if: (github.event.comment.body == 'recheck' || github.event.comment.body == 'I have read the CLA Document and I hereby sign the CLA') || github.event_name == 'pull_request' |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/cla.ymlRepository: SpecterOps/SharpHound
Length of output: 2157
Scope issue_comment signing to PR comments only.
The condition at line 36 can execute on regular issue comments matching the phrase, not just PR comments. When the issue_comment event fires, the current condition checks github.event.comment.body without verifying that the comment is on a PR, allowing a matching phrase on any issue to trigger the CLA assistant step.
Add github.event_name == 'issue_comment' && github.event.issue.pull_request guards to restrict comment-based execution to PR comments:
Suggested condition hardening
- if: (github.event.comment.body == 'recheck' || github.event.comment.body == 'I have read the CLA Document and I hereby sign the CLA') || github.event_name == 'pull_request'
+ if: |
+ (
+ github.event_name == 'issue_comment' &&
+ github.event.issue.pull_request &&
+ (
+ github.event.comment.body == 'recheck' ||
+ github.event.comment.body == 'I have read the CLA Document and I hereby sign the CLA'
+ )
+ ) || github.event_name == 'pull_request'📝 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.
| if: (github.event.comment.body == 'recheck' || github.event.comment.body == 'I have read the CLA Document and I hereby sign the CLA') || github.event_name == 'pull_request' | |
| if: | | |
| ( | |
| github.event_name == 'issue_comment' && | |
| github.event.issue.pull_request && | |
| ( | |
| github.event.comment.body == 'recheck' || | |
| github.event.comment.body == 'I have read the CLA Document and I hereby sign the CLA' | |
| ) | |
| ) || github.event_name == 'pull_request' |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/cla.yml at line 36, The current if condition that checks
comment bodies allows matching phrases from any issue comment; tighten it by
requiring comment-based checks only when the event is an issue_comment on a PR:
modify the existing conditional expression (the if statement comparing
github.event.comment.body and github.event_name) to include an additional guard:
github.event_name == 'issue_comment' && github.event.issue.pull_request so that
comment-body checks run only for PR comments, while preserving the existing
pull_request branch and the explicit recheck/signing string handling.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/vuln-scan.yml:
- Line 20: Replace the mutable tag reference "aquasecurity/trivy-action@0.34.2"
with the corresponding full commit SHA for that tag: look up the
aquasecurity/trivy-action repository on GitHub, find the v0.34.2 tag and copy
the full commit SHA (or use the GitHub API), then update the workflow line to
use "aquasecurity/trivy-action@<full-commit-sha>" instead of the tag; after
updating, validate the workflow by running or linting the GitHub Actions
workflow to ensure the action resolves correctly.
|
|
||
| - name: Run vulnerability scanner | ||
| uses: aquasecurity/trivy-action@b6643a29fecd7f34b3597bc6acb0a98b03d33ff8 # 0.33.1 | ||
| uses: aquasecurity/trivy-action@0.34.2 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/vuln-scan.yml | head -30Repository: SpecterOps/SharpHound
Length of output: 1009
🌐 Web query:
GitHub Actions best practices pinning tag vs commit SHA security supply chain
💡 Result:
Pinning uses: in GitHub Actions: tag vs commit SHA (supply-chain security)
Recommendation (best practice)
- Pin third-party actions and reusable workflows to a full-length commit SHA (e.g.,
actions/checkout@692973e3d937...) to get an immutable reference and reduce the risk of a tag being moved to malicious code. GitHub explicitly calls this the most secure option and “currently the only way” to use an action as an immutable release. [1]
When (if ever) tags are acceptable
- Floating tags (e.g.,
@v1,@v4) are convenient but mutable (they can be moved/deleted if the action repo is compromised), so they’re higher supply-chain risk. If you use tags, GitHub recommends doing so only when you trust the creator (e.g., Marketplace “Verified creator” as a signal). [1] - Immutable releases/tags can change the equation: if an action publisher enables immutable releases, the release’s associated tag is locked and can’t be moved or deleted, and assets can’t be modified—improving supply-chain integrity. [2]
Practical workflow most teams use
- Pin to SHA, but track the human version in a comment, ideally choosing the SHA that corresponds to a release tag (helps reviewability and planned upgrades), e.g.
# v4.1.7. GitHub’s guidance aligns with this pattern. [3]
Org/enterprise enforcement
- GitHub added/enhanced policy controls so admins can enforce SHA pinning (workflows fail if an action isn’t pinned) and also block specific actions/versions via policy—useful for rapid response to a compromised dependency. [4]
Extra supply-chain hardening to pair with SHA pinning
- Verify the SHA is from the action’s official repository (not a fork) and audit the action (especially if it can access secrets). [1]
- Watch for actions that remain effectively mutable even when pinned (e.g., they pull unpinned code/images at runtime). [3]
Sources: GitHub security hardening guidance [1], GitHub immutable releases docs [2], GitHub Well-Architected Actions security recommendations [3], GitHub changelog on SHA pinning enforcement/blocking [4].
Pin the Trivy action to a commit SHA instead of a mutable tag.
Line 20 currently uses aquasecurity/trivy-action@0.34.2 (a tag reference). For security workflows, pin to a full-length commit SHA to ensure an immutable reference and prevent supply-chain drift. GitHub's security guidance explicitly recommends SHA pinning as the most secure approach for third-party actions, as tags can be moved or deleted if a repository is compromised.
Resolve the commit SHA for v0.34.2 and update the reference:
- uses: aquasecurity/trivy-action@0.34.2
+ uses: aquasecurity/trivy-action@<commit-sha>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/vuln-scan.yml at line 20, Replace the mutable tag
reference "aquasecurity/trivy-action@0.34.2" with the corresponding full commit
SHA for that tag: look up the aquasecurity/trivy-action repository on GitHub,
find the v0.34.2 tag and copy the full commit SHA (or use the GitHub API), then
update the workflow line to use "aquasecurity/trivy-action@<full-commit-sha>"
instead of the tag; after updating, validate the workflow by running or linting
the GitHub Actions workflow to ensure the action resolves correctly.
3 participants
Description
Removes pull_request_target from cla
Motivation and Context
BED-7555
How Has This Been Tested?
Screenshots (if appropriate):
Types of changes
Checklist:
Summary by CodeRabbit