fix(ci): scheduled gitleaks sweep flags unmerged-branch history — scope to main + require per-PR secret check

[scottschreckengaust]

Problem

The scheduled security suite (.github/workflows/security.yml, weekly cron) runs //:security:secrets:

gitleaks git . --no-banner --redact

with the runner checked out at fetch-depth: 0. With no --log-opts, gitleaks scans secrets across all reachable git objects from every fetched ref — not just main. So a secret in an unmerged, no-PR branch's history fails the mainline scheduled suite, even though it never reached main.

Confirmed instance (main @ 3a5b4cb, 2026-08-05)

gitleaks git . --no-banner --redact               → leaks found: 4
gitleaks git . --no-banner --redact --log-opts=HEAD → no leaks found

All 4 findings are the same rule+file: aws-account-id in docs/design/AGENTCORE_GATEWAY_MCP_SPIKE.md, in commits 6c0cf601 / d773e3eb that live only on origin/feat/agentcore-gateway-mcp (a 381-commit spike branch, no PR ever opened, file absent from main). It is a bare 12-digit AWS account ID in a design doc — not a live credential.

This is the residual half of the split fixed by #335/#336 (which scoped the PR/merge_group gitleaks scan to the commit range via security:secrets:range + GITLEAKS_RANGE). The scheduled full-sweep was left unscoped — same class of bug, other surface. Lineage: #327 (P0 "make the merge gate enforceable"), #330 (required fast PR scans), #335/#336 (merge_group range scoping).

Why this matters

• A branch someone "messes up" (or abandons) can redden the mainline scheduled suite indefinitely, generating noise and auto-filed failure issues (e.g. Security suite failed (main @ db52d5f) #593) that have nothing to do with main.
• It trains reviewers to ignore a red security suite — the worst outcome for a security gate.

Requirements

Part 1 — scope the scheduled sweep to main's own history.

• In mise.toml, change //:security:secrets from gitleaks git . --no-banner --redact to scan only history reachable from the mainline, e.g.:

  gitleaks git . --no-banner --redact --log-opts="--first-parent main"
  

  (--first-parent main or HEAD both restrict to the checked-out mainline; prefer an explicit, documented choice.)
• Keep //:security:secrets:range (per-PR) and //:security:secrets:staged (pre-commit) unchanged.

Part 2 — make the per-PR secret scan a REQUIRED status check.

• Ensure the range-scoped secret scan (security-pr.yml → "Secret scan (gitleaks, range-scoped)") is a required check in the main branch protection / ruleset so a leak introduced in a PR's own diff blocks merge.
• Verify interaction with the merge queue (repo uses merge_queue + required pull_request review): the required check must be enforced on the queue entry, not just the PR head.

Gotcha / correctness caveat (LOAD-BEARING — both parts ship together)

Scoping the scheduled sweep to main-only means a secret sitting only in unmerged branch history is no longer caught by the scheduled sweep. That is acceptable only because Part 2 guarantees secrets are caught at introduction on the PR range-scan. Do not land Part 1 without Part 2 — together they move detection to the right place (merge time, on the actual diff) without the false-positive drag of unrelated branches. Note the leak commit above is in origin/main..branch, so if that branch ever opens a PR the range-scan will correctly flag it — which is the intended behavior.

Optional (owner action, not required by this issue)

The feat/agentcore-gateway-mcp branch owner may delete the stale no-PR spike branch to clear the current noise. Do NOT force-rewrite the branch (it is 381 commits, not the reporter's work); deletion is recoverable and appropriate, an in-place history rewrite is not. This issue's mechanism fix makes branch cleanup optional rather than necessary.

Acceptance criteria

• mise run security:secrets (scheduled task) reports no leaks on main @ current tip (the 4 unmerged-branch findings no longer fail it).
• A PR that adds a secret to its own diff fails the required per-PR gitleaks check and cannot merge / cannot pass the merge queue.
• No change to the pre-commit (:staged) or per-PR range (:range) task behavior beyond making the PR check required.
• Docs: a one-line note in the security:secrets task comment explaining the main-scope decision and pointing here.

References

#327, #330, #335, #336 (lineage); #593 (the failure symptom this removes); ADR-003 (governance).

[scottschreckengaust]

Blocked on a design decision → #723.

While implementing, two facts changed the scope of this issue:

1. Part 2 (required per-PR secret check) is ALREADY DONE. The required check "Secrets, deps, and workflow scan" (security-pr.yml) runs security:secrets:range with no continue-on-error, so a leak in a PR's own diff already blocks merge (delivered by feat(ci): require secrets/deps/SAST on every PR — make the merge gate enforceable (incident #313 class) #327/feat(ci): require fast security scans on every PR — secrets/deps/workflow gate (#327) #330). No work needed on the PR side.

2. The only open question is the scheduled full-history sweep (security:secrets via mise run security), which is what actually reddens on unmerged-branch history. Whether to drop it (rely solely on the per-PR range gate) or scope it to main (--log-opts=HEAD) is a real security trade-off — the range gate is diff-only and post-feat(ci): require fast security scans on every PR — secrets/deps/workflow gate (#327) #330, so dropping the sweep loses the backstop over main's older/non-PR history. Split that decision into decision: scheduled gitleaks sweep — drop it (rely on per-PR range) or scope it to main? (blocks #721) #723.

This issue stays as the implementation; it should land whichever option #723 selects. Recommendation in #723 is Option 2 (scope to main), with a verified HEAD-vs---remotes fail-open gotcha noted.

[scottschreckengaust]

Starting implementation.

Branch: fix/721-gitleaks-mainline-scope (off main @ a94be94c). Implementing Part 1 only, plus two findings below.

Part 2 is already satisfied — no ruleset change needed

The issue flags Part 1 + Part 2 as "LOAD-BEARING — both parts ship together." Part 2 is already in place on the main ruleset (id 14980587):

$ gh api repos/.../rulesets/14980587 --jq '.rules[] | select(.type=="required_status_checks") | .parameters.required_status_checks[] | .context'
build (agentcore)
Secrets, deps, and workflow scan

The range-scoped secret scan is already a required check, so the correctness caveat is met and Part 1 can land on its own.

HEAD vs main is a real distinction on the pre-push surface

The issue text offers --first-parent main or HEAD as equivalent ("prefer an explicit, documented choice"). On the scheduled run they are equivalent — the runner checks out main, so HEAD is main. On pre-push in a feature worktree they are not, and only HEAD is safe.

Measured by planting a detectable secret in a feature-branch commit and running the real task:

--log-opts	secret in your own unpushed commit
"HEAD"	leaks found: 1, exit 1 — blocks the push
"main"	no leaks found, exit 0 — push sails through

Pinning to main would walk mainline only, skipping the very commits being pushed — turning the pre-push hook into a no-op exactly when it matters. Commit counts from the #681 worktree make the scope concrete: HEAD 275, main 269 (the 6-commit delta is that branch's own work), --first-parent main 253.

Landing --log-opts="HEAD", with the rationale and the --remotes fail-open trap recorded in the task comment.

Verification

• mise run security:secrets on this branch → 269 commits scanned. no leaks found (exit 0) — the 4 unmerged-branch findings no longer fail it (acceptance criterion 1).
• Fail-close re-verified against the real task (not a bare gitleaks invocation) with a planted account id in a local commit → exit 1. Probe commit and file removed afterward; branch is main + the one-line change.
• :range and :staged unchanged.

Discovered while five rebased PR branches (#673, #674, #679, #680, #681) could not be pushed: the pre-push hook ran the unscoped sweep and failed on origin/feat/agentcore-gateway-mcp history. Each branch's own range-scoped scan is clean, and main's own history is clean (269 commits) — confirming this is the #721 false-positive class, not a real leak.