Skip to content

fix: remove pull request target from cla - BED-7555 #197

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
elikmiller merged 2 commits into from
Mar 2, 2026
Merged

fix: remove pull request target from cla - BED-7555 #197

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
669060b
fix: remove pull request target from cla
mykeelium Mar 2, 2026
c478901
fix: bump trivy action version
mykeelium Mar 2, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions .github/workflows/cla.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@ name: "CLA Assistant"
on:
issue_comment:
types: [created, edited]
pull_request_target:
pull_request:
types: [opened,closed,synchronize]
Comment on lines +5 to 6
Copy link

@coderabbitai coderabbitai bot Mar 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 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_TOKEN is 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_target runs 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_target workflow 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 -50

Repository: 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-latest

This 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.


jobs:
Expand Down Expand Up @@ -33,7 +33,7 @@ jobs:
echo "org_members=$ALL_MEMBERS" >> $GITHUB_OUTPUT

- 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'
Copy link

@coderabbitai coderabbitai bot Mar 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

cat -n .github/workflows/cla.yml

Repository: 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.

Suggested change
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.

uses: contributor-assistant/github-action@v2.2.1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Expand Down
4 changes: 2 additions & 2 deletions .github/workflows/vuln-scan.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@ jobs:
uses: actions/checkout@v4

- name: Run vulnerability scanner
uses: aquasecurity/trivy-action@b6643a29fecd7f34b3597bc6acb0a98b03d33ff8 # 0.33.1
uses: aquasecurity/trivy-action@0.34.2
Copy link

@coderabbitai coderabbitai bot Mar 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

cat -n .github/workflows/vuln-scan.yml | head -30

Repository: 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.

with:
scan-type: "repo"
scan-ref: "./"
Expand All @@ -26,4 +26,4 @@ jobs:
ignore-unfixed: true
env:
TRIVY_DB_REPOSITORY: ghcr.io/aquasecurity/trivy-db,public.ecr.aws/aquasecurity/trivy-db
TRIVY_JAVA_DB_REPOSITORY: ghcr.io/aquasecurity/trivy-java-db,public.ecr.aws/aquasecurity/trivy-java-db
TRIVY_JAVA_DB_REPOSITORY: ghcr.io/aquasecurity/trivy-java-db,public.ecr.aws/aquasecurity/trivy-java-db