feat(gitleaks): make the estate baseline shareable instead of copy-only

[hyperpolymath]

The estate gitleaks baseline could not be inherited, only duplicated. This adds the sharing mechanism that several repos already assume exists.

The problem

A consumer repo wanting the shared allowlist had two options, both bad:

• Copy it — copies drift; a fix to one is a fix to none of the others.
• Push its repo-specific entries into the shared file — which blinds all 400+ repositories.

There was no third option, because the mechanism did not exist.

metadatastician/stapeln#21 is what surfaced it. It ships a well-reasoned config doing [extend] path = ".gitleaks-estate.toml", on the stated premise that this workflow stages that file. It does not, and never did:

FTL failed to load extended config, err: open .gitleaks-estate.toml: no such file or directory

That is worse than a missing feature. The config loads nothing, the scan runs over no files at all, and the failure presents as a findings failure — a scanner that appears to be working and is scanning nothing.

What this adds

config/gitleaks/estate-baseline.toml	The shared baseline, git mvd out of this repo's root config so history is preserved. Only universally-true entries belong here.
.gitleaks.toml (this repo)	Now a four-line consumer of it. Deliberate dogfooding — the mechanism is exercised by standards' own scan, so a change that breaks consumers breaks us first.
secret-scanner-reusable.yml	Stages the baseline as .gitleaks-estate.toml, only when the repo's config actually references it.
docs/GITLEAKS-ESTATE-BASELINE.adoc	How to opt in, and the two traps below.

This is a no-op for every existing caller. A repo that does not reference the baseline gains nothing in its scanned tree.

Two things verified rather than assumed

1. [extend] path resolves against the process working directory — not the config file's directory. Tested directly: the same relative path resolves from the repo root and fails from a subdirectory. That is why the baseline is staged at the workspace root, and it confirms the premise #21 was written against was correct.

2. Moving the baseline made it scannable. As .gitleaks.toml gitleaks excluded it automatically as its own config. At its new path it is an ordinary file, and its documented placeholder shapes immediately tripped generic-api-key — a finding caused purely by renaming the file.

Caught by scanning before and after:

before the move:                 9 findings
after the move:                 10 findings   <- the baseline flagging itself
after allowlisting both paths:   9 findings   <- zero regressions

Both the canonical path and the staged .gitleaks-estate.toml are now in the baseline's own paths. If it moves again, those entries move with it.

Design notes

Pinned by construction. The baseline is fetched at ${{ github.job_workflow_sha }} — the commit of this reusable workflow — so a caller pinned to an old SHA gets that SHA's baseline. The workflow and the baseline it stages can never disagree, and there is no moving @main fetch.

The checkout is removed before scanning. Otherwise standards' own tree is scanned as if it were the caller's, which is how a shared config turns into a wall of someone else's findings.

Failure is loud. If the baseline is referenced but cannot be fetched, the job errors rather than scanning with a silently reduced config. A scan that quietly loses its allowlist produces a wall of false positives, and the usual response to that is to switch the gate off — which is exactly the history this file already records from before #500.

Verification

gitleaks detect --source . --no-git   # 9 before, 9 after — no regression
python3 -c "import yaml; yaml.safe_load(open(...))"   # workflow parses

Unrelated pre-existing local edits in this checkout were deliberately left unstaged; this PR touches four files.

Follow-up

Once this lands, stapeln#21 becomes viable as written — its estate-extension approach and its documentation discipline ("each entry names what the value is"; plant a canary and confirm it is still detected) are better than the useDefault-plus-local-paths approach currently proposed in stapeln#20.

🤖 Generated with Claude Code

---

Summary by Gitar

• Documentation & Standards:
  • Added ZIGZAG-TESTING.md and ZIGZAG-TESTING.adoc defining aspect-oriented testing methodology
  • Updated TEST-NEEDS.md to require Zigzag Testing for CRG Grade B/A

_{This will update automatically on new commits.}

[gitar-bot]

Note

Automatic reviews are paused because your trial's included automatic processing has been used for this period. Upgrade now, or comment "Gitar review" to run a review anytime.
Learn more

Code Review ✅ Approved

Makes the Gitleaks estate baseline shareable via [extend] path and workflow staging, alongside the new Zigzag Testing documentation standards. No issues found.

Auto-approved and auto-merge armed: No blocking issues found.
Please see Auto-approve Docs for details on setting custom approval criteria. — merges when pipeline and required approvals pass.

Options

Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Compact

gitar display:verbose

---

Important

Your trial ends in 3 days — upgrade now to keep code review, CI analysis, auto-apply, custom automations, and more.

_{Was this helpful? React with 👍 / 👎 | Gitar}

[gitar-bot]

Gitar has auto-approved this PR and enabled auto-merge (configure)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud