First successful gitleaks run flagged 381 "leaks" — all of them
inside `node_modules/` and `.pnpm-store/`, populated by the
`pnpm install --frozen-lockfile` step that runs earlier in the
job. Upstream packages routinely embed demo RSA keys / fake API
tokens in their READMEs and test fixtures, and gitleaks
(correctly, by its rules) flags them all. This is the same class
of false-positive Trivy hit before us in #49.
Move both scanners (Trivy + gitleaks) to BEFORE `pnpm install`:
- Trivy scans `pnpm-lock.yaml` for vulns; the lockfile is
committed, no install required.
- Gitleaks scans the working tree (`--no-git --source .` in
ci.yml; deep history in security-scheduled.yml). Without
`pnpm install`, the only files present are our own source
code, which is what we actually want to scan.
- `pnpm audit` reads `pnpm-lock.yaml` against the advisory DB —
also doesn't need node_modules. The install before audit
remains for the workspace-integrity sanity check.
Net result: clean scans, no allowlist file to maintain, scanners
run faster (smaller tree to walk).
The ordering rationale is documented inline at the top of each
job's `steps:` block so a future contributor doesn't innocently
shuffle the steps and re-introduce the false-positive flood.
Apply the same reordering to `security-scheduled.yml` for
consistency, even though its deep-history gitleaks scan does not
suffer the same false positives (history does not contain
node_modules; gitignored from day one).
Julien Gautier