🚨 Runner-Guard Security Finding
Rule: RGS-004 — Comment-Triggered Workflow Without Author Authorization Check
Severity: High
Files: pr-nitpick-reviewer.lock.yml, dev-hawk.lock.yml
Total Findings: 1590 (highly repetitive across all steps in these 2 workflows)
Description
A workflow is triggered by issue_comment, pull_request_review_comment, or workflow_run events and accesses secrets or has write permissions, but does not verify the comment author's authorization level before executing privileged operations.
The issue_comment event fires for comments from ANY GitHub user, including those with no affiliation to the repository. Without an explicit check on github.event.comment.author_association (e.g., requiring OWNER, MEMBER, or COLLABORATOR), any external user can trigger the workflow by posting a comment on any open issue or pull request.
Impact
If the workflow accesses secrets, performs deployments, or has write permissions, any external GitHub user who can post a comment can:
- Trigger privileged CI operations
- Potentially exfiltrate secrets through workflow outputs
- Bypass intended access controls
- Exhaust CI resources through repeated comment triggers
This effectively grants those privileges to arbitrary external users, which is a critical authorization boundary violation.
Remediation
Add an authorization check at the beginning of the workflow's agent job to verify the commenter's association:
- name: Check author authorization
if: github.event_name == 'issue_comment' || github.event_name == 'pull_request_review_comment'
run: |
AUTHOR_ASSOC="${{ github.event.comment.author_association }}"
if [[ "$AUTHOR_ASSOC" != "OWNER" && "$AUTHOR_ASSOC" != "MEMBER" && "$AUTHOR_ASSOC" != "COLLABORATOR" ]]; then
echo "Unauthorized: comment author association '$AUTHOR_ASSOC' is not permitted"
exit 1
fiOr use the existing gh-aw activation/guard mechanism to restrict workflow execution to authorized users before any privileged steps run.
Note: The extremely high count (1590 findings) is because runner-guard flags every individual step in the affected jobs, not just the triggering condition — both pr-nitpick-reviewer.lock.yml and dev-hawk.lock.yml have many steps that each receive their own finding.
Affected Workflows
.github/workflows/pr-nitpick-reviewer.lock.yml (~1000+ findings).github/workflows/dev-hawk.lock.yml (~500+ findings)
Detected by runner-guard v2.6.0 — CI/CD source-to-sink vulnerability scanner
Workflow run: https://github.com/github/gh-aw/actions/runs/25478184229
Generated by Static Analysis Report · ● 455.3K · ◷
🚨 Runner-Guard Security Finding
Rule: RGS-004 — Comment-Triggered Workflow Without Author Authorization Check
Severity: High
Files:
pr-nitpick-reviewer.lock.yml,dev-hawk.lock.ymlTotal Findings: 1590 (highly repetitive across all steps in these 2 workflows)
Description
A workflow is triggered by
issue_comment,pull_request_review_comment, orworkflow_runevents and accesses secrets or has write permissions, but does not verify the comment author's authorization level before executing privileged operations.The
issue_commentevent fires for comments from ANY GitHub user, including those with no affiliation to the repository. Without an explicit check ongithub.event.comment.author_association(e.g., requiringOWNER,MEMBER, orCOLLABORATOR), any external user can trigger the workflow by posting a comment on any open issue or pull request.Impact
If the workflow accesses secrets, performs deployments, or has write permissions, any external GitHub user who can post a comment can:
This effectively grants those privileges to arbitrary external users, which is a critical authorization boundary violation.
Remediation
Add an authorization check at the beginning of the workflow's agent job to verify the commenter's association:
Or use the existing gh-aw activation/guard mechanism to restrict workflow execution to authorized users before any privileged steps run.
Note: The extremely high count (1590 findings) is because runner-guard flags every individual step in the affected jobs, not just the triggering condition — both
pr-nitpick-reviewer.lock.ymlanddev-hawk.lock.ymlhave many steps that each receive their own finding.Affected Workflows
.github/workflows/pr-nitpick-reviewer.lock.yml(~1000+ findings).github/workflows/dev-hawk.lock.yml(~500+ findings)Detected by runner-guard v2.6.0 — CI/CD source-to-sink vulnerability scanner
Workflow run: https://github.com/github/gh-aw/actions/runs/25478184229