copilot security review

[chmouel]

Security review of action.yml:

High risk

• Approval bypass via any labeler: lines 150–171 allow any labeled event with label ok-to-test to pass. It does not verify that the label was added by a maintainer/collaborator/admin. In pull_request_target, that’s the key control, so this is the main issue.
• No event hardening: it assumes safe use in pull_request_target, but doesn’t validate event type. Misuse in another trigger could change behavior unexpectedly.

Medium risk

• Over-broad token expectation: input says token may have repo + org:read scopes. That’s powerful; consumers may overgrant. Better to document minimum permissions more tightly.
• Silent fallback on membership errors: lines 91–122 treat API failures similarly to “not a member”. Safer than fail-open, but can hide auth/config problems.
• Unvalidated input enum: required-permission is documented as write or admin, but not enforced. Invalid values default into the write/admin branch.

Low risk

• Pinned action: good — actions/github-script is SHA-pinned.
• No shell injection surface: logic is JS, not shell.
• Logs disclose little: mostly usernames/team slugs; acceptable.

Recommended fixes

1. Verify label applier trust before approving:
   • check context.actor has write/admin/maintain on repo, or is org/team member.
2. Restrict event types explicitly:
   • fail unless event is pull_request_target on expected actions (opened, synchronize, reopened, labeled).
3. Validate required-permission:
   • fail if not one of allowed values.
4. Document minimum token permissions precisely:
   • pull-requests: read, issues: write for label removal, members: read if org/team checks are used.

Bottom line

• Not safe as-is for its stated purpose because the ok-to-test approval path appears bypassable unless the workflow separately restricts who can apply labels.

If you want, I can also give you a patched version of action.yml with the maintainer-labeler check added.

[zakisk]

Verify label applier trust before approving:
check context.actor has write/admin/maintain on repo, or is org/team member.

only users with permission write/triage can add the labels so I think no need to check user permission

[chmouel]

Verify label applier trust before approving:
check context.actor has write/admin/maintain on repo, or is org/team member.

can we double check? to make sure it is the case

[zakisk]

https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/managing-labels#applying-a-label

[chmouel]

how does the triage access get set?

[zakisk]

https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization#repository-roles-for-organizations

Repo owner gives that

[zakisk]

we can add a check if we only want user with permission write or higher

[zakisk]

feel free to review #3