Commit 7cd512b
authored
fix(ci): grant the secret-scanner reusable its required job permissions (#36)
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 dd9709a commit 7cd512b
1 file changed
Lines changed: 7 additions & 0 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
11 | 11 | | |
12 | 12 | | |
13 | 13 | | |
| 14 | + | |
| 15 | + | |
| 16 | + | |
| 17 | + | |
| 18 | + | |
| 19 | + | |
| 20 | + | |
14 | 21 | | |
15 | 22 | | |
16 | 23 | | |
| |||
0 commit comments