lint-workflows: Check SHA-Pinned Actions red on main (31 tag-pinned refs + 5 actions.lock false positives) #127

What is red

lint-workflows / Check SHA-Pinned Actions (workflow "Workflow Security Linter") is red on main. It was measured on run 36649482714 at b12657f5, whose workflows are identical to a4cd088. PR #126 inherits the red. It does not cause it: on #126's head the step reports 36 findings, all in files that PR does not touch, and the PR removes 3 of main's 39.

The 36 findings fall into two groups:

• 31 real tag-pinned uses: refs:
  • static-analysis-gate.yml: 11
  • dogfood-gate.yml: 6
  • pages.yml: 4
  • codeql.yml: 3
  • one each in workflow-linter.yml, rhodibot.yml, quality.yml, push-email-notify.yml, estate-rules.yml, e2e.yml and dependabot-automerge.yml
• 5 false positives. The step's grep -rnE "^[[:space:]]+uses:" .github/workflows/ also matches the nested uses: keys inside .github/workflows/actions.lock.

Acceptance criteria

• lint-workflows / Check SHA-Pinned Actions is green on main.
• The 31 tag-pinned refs in the files above are SHA-pinned (@<40-hex> # vX.Y.Z), and actions.lock covers them: bash scripts/check-lock-sync.sh exits 0 and gh actions-lock --no-fix exits 0.
• The step no longer reads actions.lock, for example by restricting the grep to *.yml/*.yaml. A planted tag-pinned ref in a workflow still turns the step red (positive control).

Deferred from #126 under the standing owner ruling that a red check found at a PR boundary becomes an issue with acceptance criteria rather than a merge blocker.