Skip to content

secret-scanner: add canonical .gitleaks.toml allowlist (unblocker for re-pinning after #500) #504

Description

@hyperpolymath

Follow-up to merged PR #500 — the unblocker before consumers re-pin

PR #500 (ci(secret-scanner): make gitleaks gate for real, not continue-on-error) is merged. secret-scanner-reusable.yml now runs a pinned, checksum-verified gitleaks 8.18.4 binary with --exit-code 1, so the estate's primary secret scanner can finally fail a PR (previously continue-on-error: true — it could not).

Why this is not yet safe to roll out. Consumers pin hyperpolymath/standards/.github/workflows/secret-scanner-reusable.yml@<sha>, so the real gate only reaches a repo when that repo re-pins. Running the now-gating scan against standards' own tree surfaced 15 false positives with default rules:

  • deno.lock integrity hashes
  • Julia Project.toml UUIDs
  • docs/ examples and example.zig fixtures

With no shared allowlist, the first consumer to re-pin turns a real gate into a noise cannon — findings that are all benign, training everyone to ignore the scanner. That is the opposite of the doctrine's intent (a check that fails only when something is actually wrong).

Task

Add a canonical .gitleaks.toml allowlist to standards, consumed by the reusable (or referenced via a documented path convention), that:

  1. Allowlists the known-benign classes above by rule + path pattern (not blanket path excludes — a real secret in deno.lock should still fire).
  2. Is validated against the current standards tree: after adding it, gitleaks detect --source . --no-git --exit-code 1 must exit 0 on a clean tree and still exit 1 on a planted fixture (prove both, per "install and run — no handwaving").
  3. Ships with a short docs/ note telling consumers to re-pin the secret-scanner reusable only after adopting the allowlist, and how to extend it per-repo.

Acceptance

  • .gitleaks.toml present; standards own tree scans clean (exit 0) with it.
  • Planted-secret fixture still exits 1 (allowlist scoped, not blanket).
  • Rollout note added; then a tracked re-pin sweep of consumers can begin (separate issue).

Consumers known to be affected on re-pin include invariant-path (its recent work is on this very reusable's caller permissions).

Refs: PR #500. Audit provenance: nexia-list full CI failure-path audit, 2026-07-17.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions