enh(secu): manage invalid-revision range error

[sc979]

Description

What are your needs or what are you planning to do in this PR?

enh(secu): manage invalid-revision range error

Resolves the "Invalid revision range" failures on the gitleaks job by replacing
gitleaks/gitleaks-action with a pinned gitleaks binary (8.30.1, verified against a
sha256 pinned in the workflow) driven by a script that resolves the scan range
defensively (authenticated re-fetch + retry), scans every commit of the analyzed
branch that is not already on the destination branch, and fails closed.

Quality gate

Every non-merge commit of the analyzed branch is scanned. Only the commits already on
the destination branch are excluded, whether or not they are also on other branches
(load, performance or security test branches…), so no new secret can reach the
destination unnoticed.

Destination branch	Analyzed branch	Gate
1 or more secrets	0 secrets	✅ OK
any	1 or more secrets	❌ KO

The workflow assumes no branch name (main, develop, dev-YY.MM.x…): the
destination comes from the event itself.

Supported events: pull_request (the quality gate) and workflow_dispatch (mostly to
debug the pipeline). Org usage, checked on 2026-10-07: 73 of the 76 non-archived
repositories (centreon + quanta-computing) call gitleaks-analysis.yml@main through
secu-secret-scan.yml, on exactly these two events. In this repository,
security-checks.yml now runs on these two events only (its push and schedule
triggers are removed). centreon/.github has no caller, and
quanta-computing/cxm-zone-probe is empty.

The branch is up to date with main (merged, not rebased, to keep the PR history):
it keeps actions/checkout v7.0.1 with persist-credentials: false (#69, #71) and
the shallow PR checkout from #74 (fetch-depth = PR commits + 2, full clone otherwise).
The job token is scoped to contents: read only: the script calls no GitHub API, so
the pull-requests: read added for the action in #72 is dropped.

Scan range per event

The range is passed to gitleaks as --log-opts and validated with git log first.
Every range carries --text, so a repository's .gitattributes (e.g. * -diff)
cannot hide file contents from the scan.

Event	Range
pull_request	base..head, --no-merges: every commit not on the PR base, including commits merged in from other branches (gitleaks-action's --first-parent skipped them), excluding the base commits merged into the PR. A PR with an unrelated history scans its own history
workflow_dispatch	the ref's whole history, --no-merges: no destination to exclude
pull_request_target	job always fails, from a first step that runs before checkout: the event is not compliant with our security posture (the scan script refuses it too)
any other event (push, schedule, merge_group…)	job fails: not supported

An empty range (e.g. a PR whose head is already on its base) passes with a notice,
without running gitleaks.

Shallow PR checkout (#74)

Pull requests are checked out with fetch-depth = PR commits + 2, which holds every PR
commit. When the base branch moved further than that since the PR forked, the base side
does not reach the shared history yet, and a shallow boundary commit looks parentless:
gitleaks would scan its whole tree and report every pre-existing secret. So, for
pull_request, the range is trusted only once base..head holds no parentless commit:

• only the base side is deepened (--depth = PR commits + 1 + 32, 64 … 1024 from the
  base SHA, through the same authenticated fetch), so the PR side is not fetched again;
  --unshallow is the last resort (e.g. unrelated histories);
• a deepen fetch that brings nothing stops the round, and the retry loop below takes over.

In the tests, with main 100 commits ahead of a 1-commit PR, 3 deepen rounds fetch
about 130 base commits, and the clone stays shallow. workflow_dispatch keeps a full
clone (depth 0).

Re-fetch when hashes changed after checkout

actions/checkout pins its refs and can't be re-run in a loop. When the event's SHAs
are missing from the clone, the step re-fetches and retries, up to 5 attempts with a
5/10/15/20 s backoff:

• pull_request → refs/pull/<n>/head, the base branch, and the event's head/base
  SHAs if still served. A head (or base) SHA force-pushed away falls back to the live
  PR tip (or base branch tip), with a ::warning::.
• workflow_dispatch → all branch heads and the dispatched SHA. If it was
  force-pushed away, falls back to the live tip of the branch, with a ::warning::
  (branches only: a tag never falls back to a same-name branch).

Failed fetches are logged as ::warning::. If the range is still unresolvable, the job
fails and points to those warnings.

Credentials stay unpersisted. persist-credentials: false is kept as a hardening
measure, so the clone holds no token. The re-fetches authenticate with the job token,
set on each git fetch process only through env-scoped git config
(GIT_CONFIG_COUNT / KEY_0 / VALUE_0): never written to .git/config, never on a
command line, masked in the logs, and not exported to the gitleaks process.

Build outcome

Situation	Job
No secrets in the scanned commits (PR: even with secrets on the destination)	✅ success
No commit to scan	✅ success
Secrets found in the scanned commits (gitleaks exit 2)	❌ fail
gitleaks error (any other exit, e.g. a broken .gitleaks.toml)	❌ fail — fail closed, the scan did not complete
Range unresolvable after all retries	❌ fail
pull_request_target	❌ fail, before checkout
Other event (push, schedule…)	❌ fail

Test coverage

Both run: steps are extracted verbatim from the workflow and run with bash -e,
as GitHub does. The scan runs against throwaway repos whose remote is served over smart
HTTP and rejects any request without the job token: a runner-like full clone
(fetch-depth: 0, no persisted credentials, detached HEAD) with commits pushed after
the clone, and a shallow PR checkout (merge commit fetched at depth PR commits + 2, as
actions/checkout does, main 100 commits ahead of the fork point).

Area	Cases
Quality gate (real gitleaks 8.30.1)	PR: secrets on main and dev-26.10.x + clean branch → OK; branch leak → KO, only the branch's file reported; after merging main that brought a new secret → OK; unrelated history → OK when clean, KO when it leaks. Dispatch: whole history scanned (KO on any secret in it, OK on a clean orphan branch)
Range selection	PR: base commits excluded, merged-in side branch scanned, unrelated history scans its own commits; dispatch on a branch and on a tag; head / base / dispatched SHA missing from the clone → retry
Shallow PR checkout (real gitleaks)	clean PR with main 100 commits ahead → pass, 3 base-side deepen rounds, no boundary commit scanned, no unshallow; PR's own leak reported (not main's); main merged in → main's secret not reported; leaking side branch reported; unrelated history with secrets on base → unshallow, pass; deepen with an invalid token → fail closed, one fetch per attempt, token not in argv
Re-fetch (authenticated remote)	negative control without token; PR head pushed after checkout; PR head / PR base / dispatched SHA force-pushed away → live tips; head and ref both gone → clean failure, no garbage in variables; backoff 5/10/15/20 s; invalid token → ::warning:: + failure; tag dispatch with its SHA gone → no fallback to a same-name branch
Fetch depth step	PR → commits + 2; other events → 0; checkout uses it; step order (reject, depth, checkout, install, scan)
Token hygiene	not under .git/, not in any git argv, not in gitleaks' environment, base64 header masked
Events	push, schedule, merge_group → fail (unsupported); pull_request_target rejected by the first step (before checkout) and by the script; security-checks.yml triggers on PR and dispatch only
Exit codes (stub)	0 pass; 2 fail; 1 / 126 fail; empty range → pass without running gitleaks
Real gitleaks 8.30.1	.gitattributes * -diff doesn't hide a leak (PR and dispatch); broken .gitleaks.toml → job fails
Install step	pinned digest → installs 8.30.1, download dir cleaned up; wrong digest → step fails, nothing installed

Result: 107 / 112 passed. The 5 failures are the install-step cases: the test
machine's network intercepts TLS to GitHub (curl exit 60, self-signed certificate),
so the release could not be downloaded there. The same cases passed on 2026-10-02, and
the real-gitleaks cases ran with the 8.30.1 binary verified against GITLEAKS_SHA256.

Not covered: a real GitHub runner (the PR's own security-checks run calls
gitleaks-analysis.yml@main, not this branch).

🤖 Generated with Claude Code

[sc979]

✅ Automated Review — Passed

This PR was reviewed using the Centreon automated review skill.

Complexity: high — Recommended reviewers: 2

No blocking issues found. Ready for human review.

Security review: no findings.

Areas that deserve careful human attention:

• .github/workflows/gitleaks-analysis.yml — compute_range() (range selected per event) and refetch() (authenticated re-fetch with persist-credentials: false).
• The job fails closed: gitleaks errors, unresolvable ranges and unsupported events fail it, and pull_request_target always fails before checkout.
• This PR's own security-checks run calls gitleaks-analysis.yml@main, so CI does not exercise the new workflow. Every consumer picks it up on merge.