Add role validation for workflow_run triggers to prevent privilege escalation

[Copilot]

Plan: Add Role Validation for workflow_run Triggers ✅

Based on the issue and @pelikhan's comment to "update compiler to emit a role validation check on workflow run, just like for the command event."

• Understand current code structure
• Remove workflow_run from SafeWorkflowEvents list (make it require role validation)
• Update hasSafeEventsOnly function logic to treat workflow_run as unsafe
• Update test expectations in constants_test.go
• Update test expectations in permission_restriction_test.go
• Add new test case for workflow_run requiring role validation
• Run tests to verify changes work correctly
• Compile ci-doctor.md to verify it now includes role validation
• Remove workflow_run from JavaScript safeEvents arrays
• Fix JavaScript test failures
• Review and verify the changes
• Final verification of all workflows

Implementation Complete ✅

Successfully implemented role validation for workflow_run triggers by removing it from the SafeWorkflowEvents list and updating all related code.

Changes Made

1. Go Code Updates

   • pkg/constants/constants.go: Removed workflow_run from SafeWorkflowEvents
   • pkg/constants/constants_test.go: Updated test expectations
   • pkg/workflow/permission_restriction_test.go: Updated to expect role checks

2. JavaScript Code Updates

   • pkg/workflow/js/check_membership.cjs: Removed workflow_run from safeEvents
   • pkg/workflow/js/check_permissions.cjs: Removed workflow_run from safeEvents
   • pkg/workflow/js_comments_test.go: Updated test data

3. JavaScript Test Updates

   • pkg/workflow/js/check_membership.test.cjs: Removed workflow_run safe event test
   • pkg/workflow/js/check_permissions.test.cjs: Removed workflow_run safe event test

4. Workflow Compilations

   • All workflows with workflow_run triggers now compile with role validation
   • Example: ci-doctor.md now includes check_membership step in pre_activation job

Security Benefits

This change addresses HIGH severity security vulnerabilities:

✅ Privilege Escalation: workflow_run triggers now require role validation before execution
✅ Branch Protection Bypass: Cannot execute on protected branches without authorization
✅ Secret Exposure: Secrets not available to unauthorized users
✅ Code Review Gate: Requires admin/maintainer/write role for execution

Verification

• ✅ All unit tests pass (Go: 100%, JavaScript: 978 tests)
• ✅ ci-doctor.md compiles with role validation enabled
• ✅ needsPermissionCheck=true for workflow_run triggers
• ✅ Consistent behavior between Go and JavaScript code
• ✅ Multiple workflows verified (archie, brave, changeset, ci-doctor)

This implementation fully addresses the security issue reported in #3945 and implements @pelikhan's requested feature.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[task] Fix dangerous workflow_run trigger in ci-doctor.md (HIGH severity)</issue_title>
<issue_description>## Objective
Replace the insecure workflow_run trigger in ci-doctor.md with a secure scheduled trigger that uses the GitHub API to check for failed workflow runs.

Context

The CI Doctor workflow currently uses the workflow_run trigger, which poses HIGH security risks:

• Privilege Escalation Risk: Triggered workflows inherit permissions/secrets from the triggering workflow
• Branch Protection Bypass: Can execute on protected branches via unprotected branches
• Secret Exposure: Secrets available even when triggered by untrusted code
• No Review Gate: Executes automatically without code review

This is finding #1 from discussion #3945 (Static Analysis Report - November 14, 2025).

Approach

1. Replace workflow_run trigger with scheduled trigger (cron: '*/30 * * * *')
2. Add workflow_dispatch for manual triggers
3. Use actions/github-script@v7 to query GitHub API for workflow runs
4. Filter for failures in the last 30 minutes to avoid duplicate processing
5. Preserve all existing CI Doctor analysis logic

Files to Modify

• .github/workflows/ci-doctor.md (line 47 - trigger section)
• Test the compiled .github/workflows/ci-doctor.lock.yml after changes

Acceptance Criteria

• workflow_run trigger removed from ci-doctor.md
• Scheduled trigger (every 30 minutes) added
• workflow_dispatch trigger added for manual execution
• GitHub API call implemented to query workflow runs
• Filtering logic for recent failures (last 30 minutes) implemented
• All existing CI Doctor functionality preserved
• Workflow compiles successfully with gh aw compile ci-doctor
• Manual test confirms workflow detects failures correctly
• Permissions updated to minimum required: actions: read, contents: read, issues: write

Security Impact

Fixes HIGH severity security vulnerability that could allow:

• Arbitrary code execution with elevated permissions
• Access to repository secrets
• Modification of protected branches
• Bypass of security controls

Estimated Effort

2-4 hours

AI generated by Plan Command for discussion #3945</issue_description>

Comments on the Issue (you are @copilot in this section)

@pelikhan @copilot update compiler to emit a role validation check on workflow run, just like for the command event.

• Fixes [task] Fix dangerous workflow_run trigger in ci-doctor.md (HIGH severity) #3982

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[pelikhan]

@copilot Fix tests

[Copilot]

Pull Request Overview

This PR addresses a HIGH severity security vulnerability by removing workflow_run from the list of safe workflow events that bypass authorization checks. The workflow_run trigger poses significant security risks including privilege escalation, branch protection bypass, and secret exposure when triggered by untrusted code.

Key Changes:

• Removed workflow_run from SafeWorkflowEvents constant, requiring admin/maintainer/write role validation
• Updated JavaScript validation scripts (check_membership.cjs and check_permissions.cjs) to exclude workflow_run from safe events
• Updated test expectations to reflect that workflow_run now requires permission checks
• Regenerated all lock files to include pre_activation job with role validation for workflows using workflow_run triggers

Reviewed Changes

Copilot reviewed 31 out of 31 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
pkg/constants/constants.go	Removed workflow_run from SafeWorkflowEvents array with security rationale comments
pkg/constants/constants_test.go	Updated test to expect 2 safe events instead of 3, added security comment
pkg/workflow/js/check_membership.cjs	Removed workflow_run from safe events list with detailed security comments
pkg/workflow/js/check_permissions.cjs	Added security comments explaining workflow_run exclusion, but kept workflow_dispatch in safe events
pkg/workflow/permission_restriction_test.go	Updated test expectations: workflow_run now requires permission checks
pkg/workflow/js_comments_test.go	Updated benchmark test data to reflect new safe events list
.github/workflows/*.lock.yml (multiple files)	Updated generated workflows to use new safe events list in embedded JavaScript
.github/workflows/dev-hawk.lock.yml	Added new pre_activation job with role validation for workflow_run trigger
.github/workflows/ci-doctor.lock.yml	Added role validation step to existing activation job for workflow_run trigger

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Inconsistency detected: check_permissions.cjs still includes workflow_dispatch in the safeEvents array (line 12), but this is inconsistent with how check_membership.cjs handles workflow_dispatch.

In check_membership.cjs, workflow_dispatch is given special conditional treatment - it's only considered safe if the "write" role is allowed (lines 11-23 in check_membership.cjs). However, check_permissions.cjs unconditionally treats workflow_dispatch as safe.

For consistency, check_permissions.cjs should either:

1. Apply the same conditional logic as check_membership.cjs (skip validation only when write role is allowed), OR
2. Have clear documentation explaining why the difference in treatment is intentional

The current implementation could lead to unexpected behavior where permissions are checked differently depending on which script is used.

Suggested change

	const safeEvents = ["workflow_dispatch", "schedule"];
	if (safeEvents.includes(eventName)) {
	const safeEvents = ["schedule"];
	// Special case: workflow_dispatch is only safe if "write" is in requiredPermissions (see check_membership.cjs)
	if (
	safeEvents.includes(eventName) ||
	(eventName === "workflow_dispatch" && requiredPermissionsEnv && requiredPermissionsEnv.split(",").map(p => p.trim()).includes("write"))
	) {

[github-actions]

Agentic Changeset Generator triggered by this pull request.

[Copilot]

@copilot Fix tests

Fixed in commit 1bc2333. Removed test cases that expected workflow_run to be treated as a safe event. All tests now pass (978 JavaScript tests, all Go unit tests).