ci: Add weekly flaky test detector workflow#6484
2 issues
find-bugs: Found 2 issues (1 high, 1 low)
High
GITHUB_TOKEN with `issues: write` is passed to the LLM-controlled Claude step, contradicting the stated security model - `.github/workflows/flaky-test-detector.yml:112`
The security comment explicitly states the Claude step gets "NO write token", but github_token: ${{ github.token }} is passed at line 112. The workflow-level permission grants issues: write to that token, so a successful prompt injection that finds or reuses the token (e.g. through the action's own GitHub API plumbing) could create or manipulate issues — the exact capability the trust-boundary design aims to prevent.
Also found at:
.github/workflows/flaky-test-detector.yml:186-188.github/workflows/flaky-test-detector.yml:114
Low
Duplicate issue created when `gh issue create` succeeds server-side but times out client-side - `.github/workflows/flaky-test-detector.yml:207-215`
The || gh issue create fallback (intended to retry without the missing flaky-test label) fires on any non-zero exit from the first call, including a network timeout that occurs after GitHub already persisted the issue, resulting in two identical issues being opened.
⏱ 3m 43s · 75.7k in / 10.1k out · $0.62
Annotations
Check failure on line 112 in .github/workflows/flaky-test-detector.yml
sentry-warden / warden: find-bugs
GITHUB_TOKEN with `issues: write` is passed to the LLM-controlled Claude step, contradicting the stated security model
The security comment explicitly states the Claude step gets "NO write token", but `github_token: ${{ github.token }}` is passed at line 112. The workflow-level permission grants `issues: write` to that token, so a successful prompt injection that finds or reuses the token (e.g. through the action's own GitHub API plumbing) could create or manipulate issues — the exact capability the trust-boundary design aims to prevent.
Check failure on line 188 in .github/workflows/flaky-test-detector.yml
sentry-warden / warden: find-bugs
[APP-XYJ] GITHUB_TOKEN with `issues: write` is passed to the LLM-controlled Claude step, contradicting the stated security model (additional location)
The security comment explicitly states the Claude step gets "NO write token", but `github_token: ${{ github.token }}` is passed at line 112. The workflow-level permission grants `issues: write` to that token, so a successful prompt injection that finds or reuses the token (e.g. through the action's own GitHub API plumbing) could create or manipulate issues — the exact capability the trust-boundary design aims to prevent.
Check failure on line 114 in .github/workflows/flaky-test-detector.yml
sentry-warden / warden: find-bugs
[APP-XYJ] GITHUB_TOKEN with `issues: write` is passed to the LLM-controlled Claude step, contradicting the stated security model (additional location)
The security comment explicitly states the Claude step gets "NO write token", but `github_token: ${{ github.token }}` is passed at line 112. The workflow-level permission grants `issues: write` to that token, so a successful prompt injection that finds or reuses the token (e.g. through the action's own GitHub API plumbing) could create or manipulate issues — the exact capability the trust-boundary design aims to prevent.