feat: add CLA enforcement via contributor-assistant#10
Conversation
Activates Contributor License Agreement checking on all external PRs. Signatures stored in signatures/cla.json. CLA document hosted at meta-organvm/.github/CLA.md. Owner and bots allowlisted. Per SOP--open-source-licensing-and-ip.md Phase III mandate. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Reviewer's GuideAdds a GitHub Actions workflow to enforce a Contributor License Agreement (CLA) on external pull requests using contributor-assistant, including configuration for signatures storage, central CLA document, and an allowlist for trusted accounts and bots. Sequence diagram for CLA enforcement on external pull requestssequenceDiagram
actor Contributor
participant GitHub
participant CLA_Workflow
participant ContributorAssistant
participant Repo
participant SignaturesStore
participant CLADocumentRepo
Contributor->>GitHub: Open pull_request
GitHub->>CLA_Workflow: Trigger pull_request_target opened
CLA_Workflow->>ContributorAssistant: Run with cla.json and CLA.md config
ContributorAssistant->>Repo: Read signatures/cla.json
ContributorAssistant->>CLADocumentRepo: Read CLA.md
ContributorAssistant->>GitHub: Check actor against allowlist
alt Actor allowlisted
ContributorAssistant->>GitHub: Set CLA status success
else Actor not signed and not allowlisted
ContributorAssistant->>GitHub: Post custom notsigned comment
ContributorAssistant->>GitHub: Set CLA status pending
end
Note over Contributor,GitHub: Contributor decides to sign the CLA
Contributor->>GitHub: Comment I have read the CLA Document and I hereby sign the CLA
GitHub->>CLA_Workflow: Trigger issue_comment created
CLA_Workflow->>ContributorAssistant: Run with recheck condition
ContributorAssistant->>Repo: Update signatures/cla.json on main
ContributorAssistant->>GitHub: Set CLA status success
GitHub->>Contributor: Allow PR to be merged after other checks
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
📝 WalkthroughWalkthroughA GitHub Actions workflow for automated Contributor License Agreement (CLA) management is added, along with an empty signatures storage file. The workflow triggers on pull request and comment events to orchestrate CLA signing enforcement using the contributor-assistant action. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 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 |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| steps: | ||
| - 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' | ||
| uses: contributor-assistant/github-action@v2.6.1 |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request initializes the signatures/cla.json file with an empty array. However, the implementation is currently incomplete as it lacks the necessary GitHub Actions workflow to enforce the CLA process. Furthermore, the changes do not comply with the repository style guide, which requires that significant governance updates be documented within the docs/logos/ directory.
| @@ -0,0 +1 @@ | |||
| [] | |||
There was a problem hiding this comment.
The pull request is incomplete as it lacks the GitHub Actions workflow file (e.g., .github/workflows/cla.yml) required to actually perform the CLA enforcement. While the storage file signatures/cla.json is present, the logic to trigger the check, verify signatures, and apply the allowlist mentioned in the description is missing.
| @@ -0,0 +1 @@ | |||
| [] | |||
There was a problem hiding this comment.
This change introduces a new governance protocol but does not include the required documentation updates. According to the repository style guide (Logos Documentation Layer, lines 181-194), significant changes to the project's state or community standards should be recorded in the docs/logos/ directory. Please update docs/logos/pragma.md and docs/logos/receptio.md to reflect the implementation of CLA enforcement.
References
- The Logos Documentation Layer requires a narrative record of the system's state and polis in docs/logos/. (link)
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 1 issue, and left some high level feedback:
- The workflow permissions (
actions,contents,pull-requests,statusesall set towrite) are quite broad for a CLA check; consider scoping them down to only what the contributor-assistant action actually requires (e.g.,contents: writeandpull-requests: writeif that’s sufficient). - The
allowlist: 'bot*,dependabot[bot],github-actions[bot],4444J99'pattern may unintentionally allow any user or app matchingbot*; consider tightening this to explicit bot accounts you control to avoid bypassing CLA checks for unknown actors. - The
custom-notsigned-prcommentmessage hardcodes the repository namerecursive-engine--generative-entity; consider usinggithub.repositoryor a more generic reference so the workflow stays correct if the repo is renamed or reused.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The workflow permissions (`actions`, `contents`, `pull-requests`, `statuses` all set to `write`) are quite broad for a CLA check; consider scoping them down to only what the contributor-assistant action actually requires (e.g., `contents: write` and `pull-requests: write` if that’s sufficient).
- The `allowlist: 'bot*,dependabot[bot],github-actions[bot],4444J99'` pattern may unintentionally allow any user or app matching `bot*`; consider tightening this to explicit bot accounts you control to avoid bypassing CLA checks for unknown actors.
- The `custom-notsigned-prcomment` message hardcodes the repository name `recursive-engine--generative-entity`; consider using `github.repository` or a more generic reference so the workflow stays correct if the repo is renamed or reused.
## Individual Comments
### Comment 1
<location path=".github/workflows/cla.yml" line_range="8-12" />
<code_context>
+ pull_request_target:
+ types: [opened, closed, synchronize]
+
+permissions:
+ actions: write
+ contents: write
+ pull-requests: write
+ statuses: write
+
+jobs:
</code_context>
<issue_to_address>
**🚨 suggestion (security):** Consider tightening the permissions block to the minimal scopes required for the CLA action.
This workflow grants `actions: write`, `contents: write`, `pull-requests: write`, and `statuses: write`. For a CLA assistant that mainly updates a signatures file and comments on PRs, some of these likely don’t need `write` access (particularly `actions` and `statuses`). Since this runs on `pull_request_target` with repo secrets, trimming permissions to only what’s strictly required would meaningfully reduce risk if the workflow or a dependency is compromised.
```suggestion
permissions:
contents: write
pull-requests: write
```
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| permissions: | ||
| actions: write | ||
| contents: write | ||
| pull-requests: write | ||
| statuses: write |
There was a problem hiding this comment.
🚨 suggestion (security): Consider tightening the permissions block to the minimal scopes required for the CLA action.
This workflow grants actions: write, contents: write, pull-requests: write, and statuses: write. For a CLA assistant that mainly updates a signatures file and comments on PRs, some of these likely don’t need write access (particularly actions and statuses). Since this runs on pull_request_target with repo secrets, trimming permissions to only what’s strictly required would meaningfully reduce risk if the workflow or a dependency is compromised.
| permissions: | |
| actions: write | |
| contents: write | |
| pull-requests: write | |
| statuses: write | |
| permissions: | |
| contents: write | |
| pull-requests: write |
![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
🧹 Nitpick comments (2)
.github/workflows/cla.yml (2)
20-20: Consider pinning the action to a full commit SHA.
pull_request_targetruns with write tokens against the base repository, so a compromised tag on a third-party action could exfiltrate secrets or push tomain. GitHub's hardening guide recommends pinning third‑party actions to an immutable commit SHA rather than a mutable tag likev2.6.1, with the version kept in a trailing comment.- uses: contributor-assistant/github-action@v2.6.1 + uses: contributor-assistant/github-action@<full-40-char-sha> # v2.6.1🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/cla.yml at line 20, Replace the mutable tag reference "contributor-assistant/github-action@v2.6.1" with an immutable commit SHA for that action (e.g., "contributor-assistant/github-action@<full-commit-sha>") and keep the original tag as a trailing comment for readability (e.g., "# v2.6.1"); update the workflow step that uses the contributor-assistant/github-action to use the full commit SHA to ensure immutability and security.
19-19: Guardissue_commentto PR comments only.This job currently fires on every created issue comment repo‑wide that matches
recheckor the sign‑off phrase (including comments on plain issues). The action itself will no‑op, but you're burning a runner and exposing apull_request_target-permissioned step to unrelated events. Gate ongithub.event.issue.pull_requestto limit to PR comments.♻️ Proposed tightening
- 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_name == 'pull_request_target' || + (github.event_name == 'issue_comment' && + github.event.issue.pull_request != null && + (github.event.comment.body == 'recheck' || + github.event.comment.body == 'I have read the CLA Document and I hereby sign the CLA'))🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/cla.yml at line 19, The current if condition checks github.event.comment.body and github.event_name but does not ensure the comment is on a pull request; update the conditional in the workflow (the if expression shown) to also require github.event.issue.pull_request (i.e., only proceed when github.event.issue.pull_request is truthy) so that the job runs only for PR comments and not for issue comments, preserving existing checks for the 'recheck' or CLA sign-off phrases and the pull_request_target event.
🤖 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 27: The allowlist uses a risky wildcard "bot*" that redundantly matches
specific entries and could exempt attacker-controlled usernames; update the
allowlist value in the CLA workflow by removing the "bot*" glob and keeping only
the explicit safe entries (e.g., replace
"bot*,dependabot[bot],github-actions[bot],4444J99" with
"dependabot[bot],github-actions[bot],4444J99") so only known bot accounts and
the intended ID remain exempt; edit the allowlist key in the workflow file
accordingly.
- Line 25: Update the path-to-document value in the CLA workflow to use the raw
GitHub content URL instead of the web/blob URL; replace
'https://github.com/meta-organvm/.github/blob/main/CLA.md' with
'https://raw.githubusercontent.com/meta-organvm/.github/main/CLA.md' in the
path-to-document field and confirm the meta-organvm/.github repository exists
and is public so the raw URL is reachable by contributor-assistant.
---
Nitpick comments:
In @.github/workflows/cla.yml:
- Line 20: Replace the mutable tag reference
"contributor-assistant/github-action@v2.6.1" with an immutable commit SHA for
that action (e.g., "contributor-assistant/github-action@<full-commit-sha>") and
keep the original tag as a trailing comment for readability (e.g., "# v2.6.1");
update the workflow step that uses the contributor-assistant/github-action to
use the full commit SHA to ensure immutability and security.
- Line 19: The current if condition checks github.event.comment.body and
github.event_name but does not ensure the comment is on a pull request; update
the conditional in the workflow (the if expression shown) to also require
github.event.issue.pull_request (i.e., only proceed when
github.event.issue.pull_request is truthy) so that the job runs only for PR
comments and not for issue comments, preserving existing checks for the
'recheck' or CLA sign-off phrases and the pull_request_target event.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: e73e0b12-7893-4ce3-a6ac-aa1caf8171bc
📒 Files selected for processing (2)
.github/workflows/cla.ymlsignatures/cla.json
| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} | ||
| with: | ||
| path-to-signatures: 'signatures/cla.json' | ||
| path-to-document: 'https://github.com/meta-organvm/.github/blob/main/CLA.md' |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
curl -sI -o /dev/null -w "%{http_code}\n" https://github.com/meta-organvm/.github/blob/main/CLA.mdRepository: organvm-i-theoria/recursive-engine--generative-entity
Length of output: 100
Fix the CLA URL — it returns 404 and uses an incorrect format.
The URL https://github.com/meta-organvm/.github/blob/main/CLA.md returns HTTP 404, preventing contributors from accessing the CLA. Additionally, the /blob/ format is the GitHub web interface and is not suitable for automated tools like contributor-assistant. Use the raw content URL instead:
https://raw.githubusercontent.com/meta-organvm/.github/main/CLA.md
Verify that the meta-organvm/.github repository exists and is public before updating.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/cla.yml at line 25, Update the path-to-document value in
the CLA workflow to use the raw GitHub content URL instead of the web/blob URL;
replace 'https://github.com/meta-organvm/.github/blob/main/CLA.md' with
'https://raw.githubusercontent.com/meta-organvm/.github/main/CLA.md' in the
path-to-document field and confirm the meta-organvm/.github repository exists
and is public so the raw URL is reachable by contributor-assistant.
| path-to-signatures: 'signatures/cla.json' | ||
| path-to-document: 'https://github.com/meta-organvm/.github/blob/main/CLA.md' | ||
| branch: 'main' | ||
| allowlist: 'bot*,dependabot[bot],github-actions[bot],4444J99' |
There was a problem hiding this comment.
Allowlist has redundant entries and a risky wildcard.
bot* is a prefix glob that already matches dependabot[bot] / github-actions[bot], so both specific entries are redundant. More importantly, bot* will also match any future/attacker-controlled username starting with bot (e.g., bot-attacker), letting them bypass the CLA. Recommend dropping the wildcard and listing only the bots you actually want to exempt.
🔒 Proposed fix
- allowlist: 'bot*,dependabot[bot],github-actions[bot],4444J99'
+ allowlist: 'dependabot[bot],github-actions[bot],4444J99'📝 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.
| allowlist: 'bot*,dependabot[bot],github-actions[bot],4444J99' | |
| allowlist: 'dependabot[bot],github-actions[bot],4444J99' |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/cla.yml at line 27, The allowlist uses a risky wildcard
"bot*" that redundantly matches specific entries and could exempt
attacker-controlled usernames; update the allowlist value in the CLA workflow by
removing the "bot*" glob and keeping only the explicit safe entries (e.g.,
replace "bot*,dependabot[bot],github-actions[bot],4444J99" with
"dependabot[bot],github-actions[bot],4444J99") so only known bot accounts and
the intended ID remain exempt; edit the allowlist key in the workflow file
accordingly.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c908672d09
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| path-to-signatures: 'signatures/cla.json' | ||
| path-to-document: 'https://github.com/meta-organvm/.github/blob/main/CLA.md' | ||
| branch: 'main' | ||
| allowlist: 'bot*,dependabot[bot],github-actions[bot],4444J99' |
There was a problem hiding this comment.
The allowlist includes bot*, and this action treats allowlist entries as wildcard patterns, so any normal GitHub user whose login starts with bot can bypass CLA signing. That breaks the intended “all external PRs must sign” enforcement and creates a compliance gap; limit this to explicit bot accounts (for example dependabot[bot], github-actions[bot]) instead of a broad prefix wildcard.
Useful? React with 👍 / 👎.
| @@ -0,0 +1 @@ | |||
| [] | |||
There was a problem hiding this comment.
The workflow is wired to contributor-assistant/github-action@v2.6.1, whose setup expects to create the signatures file itself; pre-creating signatures/cla.json can make CLA processing fail when contributors sign. If this file is seeded manually, the CLA check can fail for valid contributors and block merges until the file is removed.
Useful? React with 👍 / 👎.
![llamapreview[bot]](https://avatars.githubusercontent.com/in/1023541?s=60&v=4){kind=small}
There was a problem hiding this comment.
AI Code Review by LlamaPReview
🎯 TL;DR & Recommendation
Recommendation: Request Changes
This PR introduces a critical security vulnerability by missing guardrails on the pull_request_target event, alongside logical flaws in conditionals and an external dependency that could block contributions.
📝 Findings Summary
📄 Documentation Diagram
This diagram documents the new CLA enforcement workflow triggered by pull requests and issue comments.
sequenceDiagram
participant User as Contributor
participant GitHub as GitHub
participant Action as CLA Assistant
participant File as Signatures File
User ->> GitHub: Opens Pull Request
GitHub ->> Action: Triggers pull_request_target event
Action ->> Action: Check if user is allowlisted
alt User is allowlisted
Action ->> GitHub: Skip CLA check
else User not allowlisted
Action ->> GitHub: Post comment requesting CLA signature
User ->> GitHub: Comments "I have read the CLA Document..."
GitHub ->> Action: Triggers issue_comment event
Action ->> Action: Validate comment
Action ->> File: Write signature to cla.json
Action ->> GitHub: Update PR status to signed
end
note over Action: PR #35;10 added CLA enforcement logic
| Priority | File | Category | Impact Summary (≤12 words) | Anchors |
|---|---|---|---|---|
| P0 | .github/workflows/cla.yml | Security | Missing guardrails on pull_request_target allows workflow injection. | |
| P1 | .github/workflows/cla.yml | Correctness and Business Logic | Flawed if condition may incorrectly trigger on issue comments. | |
| P1 | .github/workflows/cla.yml | Architecture | External CLA document dependency creates single point of failure. | path:meta-organvm/.github/CLA.md |
| P2 | .github/workflows/cla.yml | Correctness and Business Logic | Broad bot allowlist pattern could allow unintended users. | `path:README.md |
| P2 | signatures/cla.json | Testing | No automated test for signature file validation, risking silent failures. |
🔍 Notable Themes
- Security Configuration: Multiple findings highlight risks in workflow security settings and access controls, particularly with privileged events.
- Conditional Logic: Issues with if conditions could lead to incorrect behavior in event handling, potentially causing false positives or misses.
- External Dependencies and Testing: Reliance on external resources and lack of automated tests increase operational risk and maintenance burden.
📈 Risk Diagram
This diagram illustrates the security risk from missing guardrails on the pull_request_target event.
sequenceDiagram
participant PR as Untrusted PR
participant Workflow as CLA Workflow
participant BaseRepo as Base Repository
PR ->> Workflow: Submits PR with modified .github/workflows/
Workflow ->> BaseRepo: Runs with write permissions due to pull_request_target
note over Workflow: R1(P0): Missing guardrail allows arbitrary code execution
Workflow ->> BaseRepo: Potentially executes malicious code
💡 Have feedback? We'd love to hear it in our GitHub Discussions.
✨ This review was generated by LlamaPReview Advanced, which is free for all open-source projects. Learn more.
| on: | ||
| issue_comment: | ||
| types: [created] | ||
| pull_request_target: | ||
| types: [opened, closed, synchronize] |
There was a problem hiding this comment.
P0 | Confidence: High
The workflow is triggered by the privileged pull_request_target event. This event runs in the context of the base repository (target branch) with write permissions, not the untrusted PR source. While necessary for the contributor-assistant action to write statuses and signature files, this PR does NOT implement the required security guardrails. Malicious external contributors could submit a PR with a modified .github/workflows/ directory that runs arbitrary, privileged code in the base repository context during the pull_request_target event, potentially leading to repository compromise or secret exfiltration. The standard mitigation is to ensure the workflow if condition excludes changes to workflows, but no such condition is present.
Code Suggestion:
on:
issue_comment:
types: [created]
pull_request_target:
types: [opened, closed, synchronize]
jobs:
CLAssistant:
# CRITICAL: Prevent workflow injection from untrusted PRs
if: github.event_name == 'issue_comment' || (github.event_name == 'pull_request_target' && !contains(github.event.pull_request.head.ref, '.github/workflows/'))
runs-on: ubuntu-latest
steps:
- name: CLA Assistant
...| - 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' |
There was a problem hiding this comment.
P1 | Confidence: High
The if condition for the issue_comment trigger is flawed. The event payload for issue_comment on a Pull Request includes the comment body under github.event.comment.body. However, the condition uses a logical OR (||) with the pull_request_target event check, making the entire condition true for ANY pull_request_target event, which is correct. The flaw is that for an issue_comment event, the condition also becomes true if it's a pull_request_target event, which is impossible. While this doesn't cause a failure, it's logically incorrect and confusing. More importantly, the condition does not scope the issue_comment trigger to only comments on Pull Requests (as opposed to regular Issues), which could cause the CLA action to run incorrectly on Issue comments.
Code Suggestion:
- name: CLA Assistant
# For issue_comment events, only run on PR comments with the specific signature phrase or 'recheck'.
# For pull_request_target events, always run.
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_target'| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} | ||
| with: | ||
| path-to-signatures: 'signatures/cla.json' | ||
| path-to-document: 'https://github.com/meta-organvm/.github/blob/main/CLA.md' |
There was a problem hiding this comment.
P1 | Confidence: High
The workflow configures the CLA assistant to read the CLA document from an external repository (meta-organvm/.github). This creates a hard, cross-repository dependency. If the CLA.md file in the external repo is moved, renamed, deleted, or has its permissions changed, the CLA check in this repository will fail for all new contributors, blocking contributions. The related_context shows this repository is part of the "organvm ecosystem", suggesting a centralized policy is intended. However, this introduces a single point of failure and operational risk. The repository's own CONTRIBUTING.md (implied by standard open-source practice, though not in provided context) would not reflect this external dependency.
Code Suggestion:
# Option 1: Host a copy locally for resilience (recommended for critical legal docs)
path-to-document: 'https://github.com/organvm-i-theoria/recursive-engine--generative-entity/blob/main/CLA.md'
# Option 2: Keep external reference but add a verification step or fallback in the workflow.Evidence: path:meta-organvm/.github/CLA.md
| @@ -0,0 +1 @@ | |||
| [] | |||
There was a problem hiding this comment.
P2 | Confidence: High
The initial signatures/cla.json is an empty array. While correct for bootstrapping, the PR's test plan is manual. There is no automated test to verify the workflow's core function: writing a valid signature to this file. A regression in the CLA assistant action or a permissions issue could cause the file to remain empty or be written in an invalid format, breaking the enforcement system silently. The repository has existing Python tests (test (3.11) passes per CI). A simple integration test should be added to verify the signature file structure after a mock signing event, perhaps in a separate workflow that runs on push to main.
| path-to-signatures: 'signatures/cla.json' | ||
| path-to-document: 'https://github.com/meta-organvm/.github/blob/main/CLA.md' | ||
| branch: 'main' | ||
| allowlist: 'bot*,dependabot[bot],github-actions[bot],4444J99' |
There was a problem hiding this comment.
P2 | Confidence: Medium
The user 4444J99 is allowlisted. The related_context from README.md confirms this is the project author. However, the allowlist uses a glob pattern (bot*) for bots but lists specific names for dependabot[bot] and github-actions[bot]. The pattern bot* is broad and could accidentally allowlist any GitHub user whose login begins with "bot", which is a potential (though low-risk) security oversight. It is more precise and secure to list the specific bot logins.
Code Suggestion:
allowlist: 'dependabot[bot],github-actions[bot],4444J99'
# If other generic bots are needed, add them explicitly, e.g., 'renovate[bot]'Evidence: path:README.md|search:4444J99
2 participants
Summary
signatures/cla.jsonmeta-organvm/.github/CLA.mdGovernance Reference
Per
SOP--open-source-licensing-and-ip.mdPhase III: "Ensure all public repositories have a Contributor License Agreement (CLA) bot active."Test plan
signatures/cla.json🤖 Generated with Claude Code
Summary by Sourcery
Add a GitHub Actions workflow to enforce Contributor License Agreement (CLA) checks on external pull requests using contributor-assistant, recording signatures in the repository.
New Features:
Build:
Chores:
Summary by CodeRabbit