Skip to content

Conversation

@redsun82
Copy link
Contributor

The query was firing an alert only when both unsafe conditions were met:

  • a synchronize trigger
  • a mutable reference checkout

However, both these can cause problems alone. The query has thus been changed to detect either of the two, rather than both conditions at the same time.

Closes: #20706

@redsun82 redsun82 requested a review from a team as a code owner November 25, 2025 07:50
Copilot AI review requested due to automatic review settings November 25, 2025 07:50
@github-actions github-actions bot added documentation Actions Analysis of GitHub Actions labels Nov 25, 2025
Copilot finished reviewing on behalf of redsun82 November 25, 2025 07:52
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull request overview

This PR improves the actions/improper-access-control query to detect either unsafe condition independently (synchronize trigger OR mutable reference checkout) rather than requiring both conditions to be present simultaneously.

Key Changes:

  • Modified query logic to use broader PRHeadCheckoutStep type and add explicit check for mutable refs as a separate OR condition
  • Updated test files to demonstrate both scenarios: unsafe trigger with safe checkout (bad_triggers.yml) and safe trigger with unsafe checkout (bad_checkout.yml)
  • Added a safe test case (good.yml) demonstrating proper usage with both safe trigger and immutable reference

Reviewed changes

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

Show a summary per file
File Description
actions/ql/src/Security/CWE-285/ImproperAccessControl.ql Updated query to detect either unsafe triggers or mutable refs independently by changing checkout type to PRHeadCheckoutStep and adding mutable ref check as separate OR condition
actions/ql/test/query-tests/Security/CWE-285/ImproperAccessControl.expected Updated expected test results to include both new test cases (bad_checkout.yml and bad_triggers.yml)
actions/ql/test/query-tests/Security/CWE-285/.github/workflows/good.yml Added new test case demonstrating safe usage with labeled trigger and immutable SHA reference
actions/ql/test/query-tests/Security/CWE-285/.github/workflows/bad_triggers.yml Updated comment to clarify this tests the unsafe synchronize trigger scenario
actions/ql/test/query-tests/Security/CWE-285/.github/workflows/bad_checkout.yml Updated comment to clarify this tests the mutable reference scenario
actions/ql/src/change-notes/2025-11-25-improve-improper-access-control.md Added release notes documenting the query improvement

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

category: minorAnalysis
---
* The `actions/improper-access-control` query has been improved to correctly detect cases where either the check
triggers or the checkout reference are unsafe, rather than only when both applied as was done previously.
Copy link

Copilot AI Nov 25, 2025

Choose a reason for hiding this comment

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

Grammar issue: "when both applied" should be "when both apply" or "when both were applied".

Suggested change
triggers or the checkout reference are unsafe, rather than only when both applied as was done previously.
triggers or the checkout reference are unsafe, rather than only when both apply as was done previously.

Copilot uses AI. Check for mistakes.
if: contains(github.event.pull_request.labels.*.name, 'safe to test')
with:
ref: ${{ github.event.pull_request.head.ref }}
ref: ${{ github.event.pull_request.head.ref }} # BAD (mutable ref)
Copy link
Contributor

Choose a reason for hiding this comment

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

Technically head.ref without a repo name isn’t exploitable (as it will just check out the branch from the base repo a fail if not present).

Copy link
Contributor

Choose a reason for hiding this comment

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

I guess it still could be a privesc in very narrow scenarios where the repo enforces strict feature/main branch boundaries and a higher privilege group needs to approve the run (even though both have write access to the repo).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Actions Analysis of GitHub Actions documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Actions] CWE-285/ImproperAccessControl.ql Not Currently Working

3 participants