repo-standard.yml @ #54 fails caller startup: scorecard/sbom actions not in the org Actions allowlist

[bdelanghe]

repo-standard.yml at 60745f9bf5160811fdc3529d211ae8cffd6619ca (the #54 spell-gate/scorecard/sbom revision) causes a startup_failure — zero jobs, run never created — for any repo that calls it, regardless of inputs.

Evidence (from bounded-systems/conformance)

• A caller pinned to the previous revision d43c3280588ef05f4ead43426db1091d4cb8f520 runs fine with any inputs (this is what guest-room / verbspec / claude-box use today).
• A caller pinned to 60745f9b gets startup_failure on every variant tried: security-only (nothing else), with/without spell: true, with/without scorecard: false, with/without actions: read at the caller's top level, on a fresh push and on a manual re-run (so not propagation lag).
• The reusable workflow's YAML at 60745f9b parses cleanly; all inputs (security/scorecard/sbom/spell/test/descriptor/…) are present.

Likely cause

The only delta between the two pins is that 60745f9b adds two new third-party actions the old revision didn't reference:

• ossf/scorecard-action@4eaacf0543bb3f2c246792bd56e8cdeffafb205a (the scorecard job)
• anchore/sbom-action@e22c389904149dbc22b58101806040fa8d37a610 (the sbom job)

GitHub Actions statically validates every uses: across all jobs of a called reusable workflow at run-creation time — before evaluating any job's if: condition. So if the org Actions policy is "Allow select actions" and those two aren't on the allowlist, the entire run fails to start even when scorecard/sbom are false and their jobs would never run.

(I could not read the org/repo Actions-permissions API directly to 100%-confirm the allowlist contents — it's blocked in my environment — so this is an inference from the evidence above. But nothing else fits: valid YAML, works on the old pin, fails on the new pin with identical inputs, only-delta is two new actions.)

Why it wasn't caught in #54

.github has no workflow that calls repo-standard.yml as a self-test, so #54's own CI (org-defaults, required-baseline, …) went green without ever exercising the new revision through a real caller. The first real invocation (a conformance PR) is what surfaced it.

Suggested fixes (any one)

1. Allowlist ossf/scorecard-action and anchore/sbom-action in the org Actions policy (Settings → Actions → General → Allow select actions). This is probably the intended state anyway, since feat(repo-standard): add opt-in spell-gate (cspell dictionary allowlist) #54 wants scorecard on by default.
2. Have repo-standard.yml not reference actions the org doesn't permit (e.g. gate the whole job set differently), though (1) is cleaner given scorecard is meant to be a default-on floor.
3. Add a self-test caller in .github (a workflow that uses: its own repo-standard.yml with the defaults) so a future revision that can't start is caught before repos bump their pins.

Downstream impact

bounded-systems/conformance#19 (adopt the reusable spell job) is blocked on this: spell only exists from 60745f9b, and that pin can't start. conformance is staying on its standalone spell-gate.yml until this clears. Other repos are unaffected only because they haven't bumped their pin yet — any bump to 60745f9b will hit the same wall.

🤖 Generated with Claude Code

[bdelanghe]

Correction — the Actions-allowlist root cause in the issue body is FALSIFIED.

An org admin ran a dry-run against the live policy: bounded-systems's allowed_actions mode is all, not selected. Every action is already permitted org-wide, so there is no allowlist, and ossf/scorecard-action / anchore/sbom-action were never blocked. The theory in the original report (which I explicitly flagged as an inference I couldn't confirm — the Actions-permissions API wasn't readable from my environment) is wrong. Apologies for the misdirection.

What still stands: repo-standard.yml@60745f9b reproducibly startup_failures (zero jobs) for a caller — fresh push and manual re-run — while the previous pin d43c3280 works with the same caller and inputs. So the reusable workflow at that revision still can't be instantiated by callers; the cause is just not the allowlist.

New leading hypothesis (unconfirmed): job-level permission escalation. The delta from the working pin is that the new revision adds jobs whose permissions: exceed a contents: read caller:

• sbom → permissions: contents: write
• scorecard → permissions: actions: read (+ contents: read)

The old pin's jobs were all contents: read. GitHub validates a called workflow's job permissions against the caller's granted permissions at run-creation time, before if: conditions are evaluated — so a caller that grants only contents: read may have the whole run rejected because sbom/scorecard request more, even with sbom: false/scorecard: false.

Concrete test to confirm: have a caller grant permissions: { contents: write, actions: read } (superset) and see whether the startup_failure clears. If it does, the fix is either (a) document that callers must grant those permissions, or (b) drop the job-level permissions: escalation in the reusable workflow and let callers opt in. I can run this test from a conformance branch if useful.

The self-test-caller suggestion (item 3 in the original) still stands regardless — it would have caught this at merge.

---

Generated by Claude Code

[bdelanghe]

Root cause (evidence-backed): job-level permission escalation the caller doesn't grant.

Confirmed eliminations from an admin gh session: the org is on allowed_actions: all (allowlist ruled out), and all the new action SHAs resolve (SHA-pin ruled out). gh run view reports the generic "workflow file issue" banner — i.e. a load-time validation error.

A full diff of d43c3280 (works) → 60745f9b (fails) shows the only permission-relevant change is two new jobs that request more than the workflow's contents: read base:

• sbom → permissions: { contents: write }
• scorecard → permissions: { contents: read, actions: read }

The decisive detail: the failing run was a pull_request, and both of those jobs are gated if: ${{ … github.event_name != 'pull_request' }} — so both are skipped on a PR. The run startup_failured anyway ⇒ GitHub rejected it before evaluating if:. For a called reusable workflow, a job whose permissions: exceed what the caller's workflow grants is a load-time validation failure (the effective token can't be escalated), and it's evaluated for every job in the file regardless of if:. A caller granting only contents: read (the conformance caller's posture, and the restrictive default) therefore can't instantiate this revision at all.

This is why it reproduces for any caller, on fresh push and re-run, independent of the spell/scorecard/sbom input values.

Confirm (specific error text)

The generic banner hides the exact message; it's in the run's check annotations:

gh api repos/bounded-systems/conformance/actions/runs/28970952257/attempts/2 \
  --jq '.jobs_url'   # or, from the Actions UI, expand the red banner on the run page

Expect something like "The workflow is not valid … requests 'contents: write' but is only allowed 'contents: read'."

Fix options (in repo-standard.yml)

1. Don't set job-level permissions: above the caller's floor. Drop contents: write from sbom / actions: read from scorecard; let callers that enable those behaviors grant the extra scope in their own caller (documented per input). A caller can raise permissions; the reusable workflow shouldn't demand them for all callers.
2. Or split sbom (and any write-needing job) into a separate reusable workflow repos opt into, so the default repo-standard stays contents: read and instantiable everywhere.
3. Or document that every caller must grant permissions: { contents: write, actions: read } — but that forces write on repos that don't publish releases, so (1)/(2) are better.

A self-test caller in .github (item 3 of the original) would still have caught this pre-merge.

---

Generated by Claude Code

[bdelanghe]

Root cause confirmed — it is not the org Actions allowlist

Re-checked with admin:org (the API this issue couldn't reach at filing time):

• GET /orgs/bounded-systems/actions/permissions → {"allowed_actions":"all", ...}
• GET /orgs/bounded-systems/actions/permissions/selected-actions → 409 "All actions and workflows are allowed on this organization"

So ossf/scorecard-action and anchore/sbom-action are already permitted org-wide. Suggested fix 1 (allowlist those actions) is a no-op — there is no allowlist to add them to. The allowlist inference in the original description is disproven.

The real mechanism: permission escalation, before if:

In repo-standard.yml@60745f9b the workflow default is permissions: contents: read, but two jobs request more:

• sbom → permissions: contents: write
• scorecard → permissions: contents: read + actions: read

GitHub validates a called reusable workflow's requested permissions against the caller's granted GITHUB_TOKEN scope at run-creation time — before any job's if: is evaluated. A caller granting only contents: read therefore triggers a zero-jobs startup_failure even when sbom/scorecard are false and those jobs would be skipped. This matches every symptom (valid YAML, works on the old pin, fails on 60745f9b with identical inputs) and is exactly the analysis in #56.

Consequence for the fix

Suggested fix 1 won't work. The viable options are:

1. Callers grant the superset — contents: write + actions: read at the caller's top-level permissions:, even for a read-only spell/security run (every job's permission request is load-validated regardless of if:).
2. Split sbom/scorecard out of repo-standard.yml's always-loaded job set (e.g. a separate reusable workflow) so a spell/security caller can stay contents: read.

Option 2 keeps the common contents: read caller contract intact; option 1 forces every caller to over-grant. #56's self-test caller catches either regression pre-merge.

🤖 Generated with Claude Code