SLSA-BUILD-L2 — Permissions block grants overly broad scopes

An explicit permissions block that grants write-all defeats least privilege.

Field	Value
Rule ID	slsa-build-l2-perms-overly-broad
Severity	HIGH
SLSA level	v1.2 Build L2
Auto-fix	partial (what it does)

What the check does

Fires when a workflow- or job-level permissions: block either:

• Sets the scalar permissions: write-all, or
• Declares four or more scopes all set to write (an exhaustive write map).

Why it matters

SLSA Build L2 hardening expects least privilege — only the scopes the workflow actually needs should be writable. write-all is strictly worse than the implicit default: it gives reviewers the impression that permissions have been considered when they haven’t been.

This rule is the sibling of cicd-sec-5-missing-permissions: one fires on absence of a block, this one fires on excess.

Vulnerable example

name: ci
on: push
permissions: write-all              # ← antipattern
jobs:
  build:
    runs-on: ubuntu-latest
    steps: [{ run: ./build.sh }]

Safe example

name: ci
on: push
permissions:
  contents: read
jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write              # ← only this job actually needs it
    steps: [{ run: ./publish.sh }]

Auto-fix

--fix handles the scalar form: permissions: write-all (workflow- or job-level) is rewritten to permissions: read-all. That’s the safe default — every step can still read code and metadata, no writes.

The mapping form (4+ scopes all set to write) is left for manual review. We can’t tell from YAML alone which of those scopes the workflow actually needs, and silently dropping them would break the build. Start from contents: read and add scopes per-job as needed.