scorecard.yml has never run: 20/20 startup_failure (jobs=0); Scorecard is a required code_scanning tool with zero analyses

[hyperpolymath]

Finding

.github/workflows/scorecard.yml has never run: 20 of 20 runs are startup_failure with jobs = 0, from the first run on 2026-07-19 through the latest scheduled run on 2026-09-21 (run 35561762652). No Scorecard SARIF has ever reached code scanning: the last 30 days of analyses are CodeQL ×58 and Hypatia ×42, Scorecard ×0. Ruleset default-branch-protection (18110203) nevertheless lists Scorecard as a required code_scanning tool, which no PR can satisfy (owner decision surface D85, standards#787).

What it is not

• Not the lockfile: .github/workflows/actions.lock carries '.github/workflows/scorecard.yml': [] (same shape as the green rust-ci.yml and governance.yml keys) and dependencies: entries for the callee's three inner actions (actions/checkout@3d3c42e5, ossf/scorecard-action@2d114668, actions/upload-artifact@043fb46d).
• Not the allow-list: ossf/scorecard-action@* is in selected-actions; the callee is same-owner.
• Not the callee: hyperpolymath/standards/.github/workflows/scorecard-reusable.yml runs green on standards itself (three runs 2026-09-22), hypatia (daily, green 2026-09-22), echo-types, januskey and nextgen-typing.

Caller diff against a green caller (hypatia, comments stripped)

-permissions:
-  actions: read
-  contents: read
-  id-token: write
-  security-events: write
+permissions: read-all
 on:
+  branch_protection_rule:
   schedule:
-    - cron: '0 4 * * *'
-  workflow_dispatch:
+    - cron: '23 4 * * 1'
 jobs:
-  scorecard:
-    uses: hyperpolymath/standards/.github/workflows/scorecard-reusable.yml@da2c748aad55c1a1dcba00b60fe4a35017bc6540
+  analysis:
+    uses: hyperpolymath/standards/.github/workflows/scorecard-reusable.yml@bd0df9ead7faf0cdfe0e13e7966d91e28d0101d4
     permissions: {actions: read, contents: read, security-events: write, id-token: write}
     secrets: inherit

The workflow-level read-all combined with a reusable-call job that asks for security-events: write and id-token: write is the only structural difference that touches token scopes; the missing workflow_dispatch is why nobody could probe it (a startup death can be event-specific, and there is no way to trigger this file except waiting for Monday 04:23 UTC).

Acceptance criteria

• Caller rewritten to the estate shape: explicit workflow-level permissions granting exactly the four scopes the job passes, workflow_dispatch added, callee pinned to the SHA the green callers use (or newer), lock entry kept as [] per the standing job-level-reusable-ref policy.
• gh workflow run scorecard.yml produces a run with jobs > 0 and conclusion success; the run id is recorded in this issue.
• A Scorecard analysis appears in GET /repos/hyperpolymath/absolute-zero/code-scanning/analyses.
• Mutant: restoring permissions: read-all alone and dispatching again reproduces startup_failure with jobs = 0 (or, if it does not, the diagnosis above is wrong and the issue records the real cause).
• Ruleset 18110203's code_scanning rule is re-scoped per D85 before or independently of this cure, so the cure does not gate merges.

🤖 Generated with Claude Code

[hyperpolymath]

Root cause, proven and re-proven

The run page of every failed run since 09-07 (the API carries no log for a jobs=0 run) says:

The workflow is not valid. .github/workflows/scorecard.yml (Line: 15, Col: 3): Error calling workflow 'hyperpolymath/standards/.github/workflows/scorecard-reusable.yml@bd0df9ea…'. The workflow is requesting 'actions: read, contents: read', but is only allowed 'actions: none, contents: none'.

A job-level permissions: block replaces the workflow-level map. The analysis job carried only security-events: write + id-token: write, so permissions: read-all at the workflow level did nothing for it and the callee's actions: read / contents: read were refused at startup.

Two corrections to this issue's text:

1. fix(ci): correct reusable-workflow caller permissions and inputs #158 (a551037, 09-21 07:49Z) had already added the two scopes to the job block, so main has been cured at startup since then. Nothing showed it because the file triggered only on branch_protection_rule and the weekly cron (23 4 * * 1; next 09-28) and had no workflow_dispatch. All 20 failures pre-date fix(ci): correct reusable-workflow caller permissions and inputs #158.
2. AC4's mutant ("restoring permissions: read-all alone") is the wrong shape: read-all was never the killer. Measured 2026-09-22T23:26:30Z, three dispatches on throwaway branches (branches deleted, runs persist):

shape	run	result
read-all + job block of only security-events/id-token (the pre-#158 shape) — Mutant A, 45f97fb	35797435300	startup_failure, jobs=0: "The nested job 'scorecard' is requesting 'actions: read, contents: read', but is only allowed 'actions: none, contents: none'."
read-all + four job scopes (this issue's AC4 mutant) — Mutant B, 867847c	35797440576	passed startup, jobs=2
the cure (PR #169, 6f01307)	35797429801	passed startup, jobs=2

Both survivors then died inside ossf/scorecard-action with Only the default branch main is supported — the action refuses non-default branches on workflow_dispatch by design, so a branch dispatch can only ever prove "passed startup". The runtime lanes are pull_request (the callee's Local-mode job) and push: main.

Why a pin bump is required, not cosmetic (AC3)

Callee bd0df9ea runs Scorecard with results_format: json and uploads nothing, so even a green run produced no Scorecard analysis under code scanning. PR #169 pins standards 0f13f51f, which emits SARIF and uploads it (green on standards push run 35794990055 and pull_request run 35795130513), adds push: main / pull_request / workflow_dispatch, keeps the cron and branch_protection_rule, and drops secrets: inherit (the callee references no secrets). actions.lock key stays []: a callee's steps are not validated against the caller's lock (hypatia-scan is the control).

Merge and post-merge evidence (measured 2026-09-22T23:46Z)

• PR ci(scorecard): cure the 20/20 startup death and emit SARIF (#168) #169 was merged by the owner account at 2026-09-22T23:34:28Z as dd87b48, about three minutes after it opened and while all 27 checks were still queued. The rule-suite entry for that push to main records bypass. Recorded as it happened; this session merged nothing.
• PR lane (pull_request on 6f01307): run 35797967530 finished success, jobs=2 (scorecard / Run Scorecard PR success; scorecard / Run Scorecard skipped by design). It went green after the merge, so the merge did not wait for it.
• Main lane (push: main on dd87b48): run 35798071972 finished success, jobs=2 (scorecard / Run Scorecard success; the PR job skipped). First non-startup_failure run of this workflow since 09-07 outside the throwaway dispatches above.
• AC3 met: three Scorecard analyses on refs/heads/main at dd87b48, created 2026-09-22T23:41:54–56Z — supply-chain/branch-protection results=1, supply-chain/local results=5, supply-chain/online-scm results=2. The previous newest analysis was 2026-05-27 at 7c377cd.
• Open Scorecard alerts on main after the new analysis: high=5, medium=2, low=1 (before: high=4, medium=2, low=2); 43 alerts are now in state fixed. Those alert deltas are Scorecard's own findings on the current tree, not this cure's subject — the code_scanning rule on ruleset 18110203 still requires Scorecard at high_or_higher, so a triage of the 5 highs is the next issue, per the standing rule that a new scanner finding is an issue with acceptance criteria, not a blocker.

AC5

Superseded by the owner's rulings of 09-22: D85 keeps Scorecard as a required code-scanning tool and cures this first; D86 dropped CodeRabbit as a required status. AC3 (an analysis on main) is produced by the push: main run after #169 merges; this issue closes on that receipt.

🤖 Generated with Claude Code

[hyperpolymath]

Closing on the receipt above: the push:main run 35798071972 on dd87b48 succeeded with jobs=2 and three Scorecard analyses now exist on refs/heads/main (2026-09-22T23:41Z). AC5 is superseded by D85/D86; the 5 open high alerts are Scorecard's own findings and get their own issue.

🤖 Generated with Claude Code