Commit b3cfbaa
authored
fix(ci): grant the secret-scanner reusable its required job permissions (#214)
Every `Secret Scanner` run in this repo has been ending in
**`startup_failure`** — meaning **secret scanning has never actually
executed** here.
### Root cause
A called reusable workflow may only request permissions **equal to or
more restrictive than its caller**. This is enforced when the workflow
file is *parsed*, before a runner is allocated — which is why it
surfaces as `startup_failure` with no logs and no annotations.
`secret-scanner-reusable.yml` declares this on its `gitleaks` job:
```yaml
permissions:
contents: read
pull-requests: write # gitleaks-action posts the PR summary comment
actions: read # workflow-run metadata / PR-files endpoint
```
This caller granted only the file-level `permissions: contents: read`,
so the reusable was asking for more than the caller had. GitHub refused
the run outright.
### Evidence
Two repos pinning the **identical** reusable SHA behave differently
based only on this block: `modshells` (grants the superset) runs fine;
`verisimdb` (does not) `startup_failure`s. Estate-wide, 176 callers
grant it and run; 26 do not and are all dead.
### Fix
Grant the superset at job level — byte-identical to the canonical
template. **No SHA pin is changed**, so the scanned content and
supply-chain posture are unaffected; this only lets the existing pinned
scanner start.
### Verification
After merge, `Secret Scanner` should move from `startup_failure` to an
actual run with `gitleaks` / `rust-secrets` / `shell-secrets` jobs.
🤖 Generated with [Claude Code](https://claude.com/claude-code)1 parent 323d4fb commit b3cfbaa
1 file changed
Lines changed: 7 additions & 0 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
15 | 15 | | |
16 | 16 | | |
17 | 17 | | |
| 18 | + | |
| 19 | + | |
| 20 | + | |
| 21 | + | |
| 22 | + | |
| 23 | + | |
| 24 | + | |
18 | 25 | | |
19 | 26 | | |
0 commit comments