Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 12 additions & 13 deletions .github/workflows/test.yaml
Original file line number Diff line number Diff line change
@@ -1,20 +1,19 @@
---
name: test
on:
pull_request:
types: [closed]
pull_request_review:
types: [submitted]
on: pull_request
jobs:
test:
if: |
endsWith(github.event.pull_request.user.login, '[bot]') &&
((github.event_name == 'pull_request_review' && github.event.review.state == 'approved') ||
github.event_name == 'pull_request')
runs-on: ubuntu-24.04
timeout-minutes: 15
permissions:
pull-requests: write
contents: read
permissions: {}
steps:
- uses: suzuki-shunsuke/notify-bot-pr-event-action@pr/1
- id: create_token
uses: suzuki-shunsuke/tibdex-github-app-token@55429bbc082600559820fc71ef237b3f0e2a50a1 # v3.0.0
with:
app_id: ${{ vars.APP_ID }}
private_key: ${{ secrets.APP_PRIVATE_KEY }}
Comment on lines +3 to +14
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🌐 Web query:

For GitHub Actions, are repository secrets available to workflows triggered by pull_requestfrom forks, and when ispull_request_target the correct alternative?

💡 Result:

Yes—when a workflow is triggered by pull_request from a fork, GitHub does not pass repository secrets to the runner (with the exception of GITHUB_TOKEN). [1][2] When to use pull_request_target: use it when you need access to the base repository’s secrets (or otherwise need the privileged context of the target repository) while responding to a pull request. GitHub introduced pull_request_target specifically to give the workflow access to secrets/read-write GITHUB_TOKEN so maintainers can safely perform tasks like commenting/labeling on PRs. [3] However, pull_request_target is dangerous if your workflow checks out and runs untrusted code from the pull request; GitHub’s Security Lab warns that combining it with an explicit checkout/build/run of untrusted PR code can lead to repository compromise, because the workflow runs in the context of the base repo with secrets available. [4] Rule of thumb: - If you only need to test untrusted code: prefer pull_request (secrets withheld by design). [4][2] - If you truly need base repo secrets: use pull_request_target, but do not blindly execute the PR’s code—only use it for trusted tasks, and/or gate execution carefully (e.g., separate trusted workflow steps, approvals, and strict handling of what is checked out/executed). [4] Related note: for fork PRs using pull_request_target, GitHub documents that GITHUB_TOKEN is granted read/write repository permission even when triggered from a public fork. [5]

Citations:


🏁 Script executed:

cat -n .github/workflows/test.yaml

Repository: szksh-lab-2/test-github-action

Length of output: 797


pull_request prevents app-secret usage on fork PRs.

Line 3 + Line 14 are incompatible for forked PR validation: secrets.APP_PRIVATE_KEY is not available on fork-triggered pull_request runs, so token creation fails and the gh pr comment step cannot execute.

Suggested fix
-on: pull_request
+on:
+  pull_request_target:
+    types: [opened, reopened, synchronize]
📝 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.

Suggested change
on: pull_request
jobs:
test:
if: |
endsWith(github.event.pull_request.user.login, '[bot]') &&
((github.event_name == 'pull_request_review' && github.event.review.state == 'approved') ||
github.event_name == 'pull_request')
runs-on: ubuntu-24.04
timeout-minutes: 15
permissions:
pull-requests: write
contents: read
permissions: {}
steps:
- uses: suzuki-shunsuke/notify-bot-pr-event-action@pr/1
- id: create_token
uses: suzuki-shunsuke/tibdex-github-app-token@55429bbc082600559820fc71ef237b3f0e2a50a1 # v3.0.0
with:
app_id: ${{ vars.APP_ID }}
private_key: ${{ secrets.APP_PRIVATE_KEY }}
on:
pull_request_target:
types: [opened, reopened, synchronize]
jobs:
test:
runs-on: ubuntu-24.04
timeout-minutes: 15
permissions: {}
steps:
- id: create_token
uses: suzuki-shunsuke/tibdex-github-app-token@55429bbc082600559820fc71ef237b3f0e2a50a1 # v3.0.0
with:
app_id: ${{ vars.APP_ID }}
private_key: ${{ secrets.APP_PRIVATE_KEY }}
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/test.yaml around lines 3 - 14, The workflow currently
triggers on pull_request which disallows access to secrets for forked PRs;
change the trigger to pull_request_target (or split the token-creation into a
separate job triggered by pull_request_target) so the create_token step (uses:
suzuki-shunsuke/tibdex-github-app-token) can access secrets.APP_PRIVATE_KEY; if
you use pull_request_target ensure you still checkout the PR head (use the
appropriate checkout ref for github.event.pull_request.head.sha) before running
actions that use repository code so the rest of the job (including the
subsequent gh pr comment step) operates against the PR changes.

- run: gh pr comment -R "$GITHUB_REPOSITORY" "$NUMBER" --body "$BODY"
env:
GH_TOKEN: ${{ steps.create_token.outputs.token }}
NUMBER: ${{ github.event.pull_request.number }}
BODY: hello