From a0e8e095d0b24748d92356380789da79d98a69f6 Mon Sep 17 00:00:00 2001 From: julien Date: Fri, 8 May 2026 00:18:56 +0200 Subject: [PATCH] fix(ci): run scanners before pnpm install to avoid node_modules false positives (#51) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ## Summary First successful gitleaks run flagged **381 "leaks"** — all inside `node_modules/` and `.pnpm-store/`, populated by the `pnpm install --frozen-lockfile` step that ran earlier in the job. Upstream npm packages routinely embed demo RSA keys / fake API tokens in their READMEs and test fixtures, and gitleaks correctly (by its rules) flags them. Same class of false-positive Trivy hit in #49 — solved there by `--scanners vuln`. Here, the cleanest solution is **reordering**: run the scanners *before* `pnpm install`, so the working tree contains only our committed source. - **Trivy** scans `pnpm-lock.yaml` (committed) — doesn't need install. - **Gitleaks** scans the working tree (`--no-git --source .` in ci.yml) — doesn't need install. - **pnpm audit** reads `pnpm-lock.yaml` against the advisory DB — also doesn't need install. The install before audit remains for the workspace-integrity sanity check. The ordering rationale is committed as a comment at the top of each job's `steps:` block, so a future contributor doesn't innocently shuffle the steps and re-flood the gate with FPs. Same reordering applied to `.gitea/workflows/security-scheduled.yml` for consistency, even though its deep-history gitleaks scan doesn't suffer this issue (`node_modules` is `.gitignore`d from day one — never in history). ## Test plan - [ ] `scan` job goes green end-to-end on this PR — gitleaks reports 0 leaks (or only real ones from our source, none expected). - [ ] On `push` to main post-merge, scan stays green. - [ ] Trigger `security-scheduled` manually before next Monday's cron to verify the same ordering doesn't break the deep scan. ## After this PR With #43 (TS/ESLint reverts), #45 (Trivy install), #49 (Trivy `--scanners vuln`), #50 (gitleaks install), and now this — every gate of the CI pipeline should be green end-to-end. Phase-1 CI bring-up is then complete and we can move to **A — local infra recipe** (Postgres + Redis + OTel Collector). --------- Co-authored-by: Julien Gautier Reviewed-on: https://git.unespace.com/julien/apf_portal/pulls/51 --- .gitea/workflows/ci.yml | 17 +++++++++++++++-- .gitea/workflows/security-scheduled.yml | 14 ++++++++++++-- 2 files changed, 27 insertions(+), 4 deletions(-) diff --git a/.gitea/workflows/ci.yml b/.gitea/workflows/ci.yml index 6bdcac4..23bd7df 100644 --- a/.gitea/workflows/ci.yml +++ b/.gitea/workflows/ci.yml @@ -55,14 +55,22 @@ jobs: scan: runs-on: [self-hosted, on-prem] + # Step ordering matters here: Trivy and gitleaks BOTH run before + # `pnpm install`. Reason: gitleaks scans the working tree + # (`--no-git --source .`), and after install, `node_modules/` + # and `.pnpm-store/` are full of upstream packages whose READMEs + # and test fixtures contain demo RSA keys / fake API tokens — + # gitleaks then false-positives on them by the hundreds (caught + # the hard way: 381 hits on the first run). Trivy reads + # `pnpm-lock.yaml` for its vuln scan, not `node_modules`, so it + # also doesn't need install. `pnpm ci:audit` does the same — it + # queries the advisory DB against the lockfile. steps: - uses: actions/checkout@v6 - uses: pnpm/action-setup@v6 - uses: actions/setup-node@v6 with: node-version-file: '.nvmrc' - - run: pnpm install --frozen-lockfile - - run: pnpm ci:audit # Dependency vulnerability scan. Trivy is a Go binary, not an npm # package, so it cannot live in package.json scripts as cleanly # as audit/lint do. @@ -150,6 +158,11 @@ jobs: --source . \ --redact \ --exit-code 1 + # npm-advisory check (against pnpm-lock.yaml). Run last so + # `pnpm install` does not pollute the working tree before the + # scanners above. + - run: pnpm install --frozen-lockfile + - run: pnpm ci:audit commits: # PRs opened by Renovate (apf-portal-bot) carry commit messages diff --git a/.gitea/workflows/security-scheduled.yml b/.gitea/workflows/security-scheduled.yml index 703313f..324dada 100644 --- a/.gitea/workflows/security-scheduled.yml +++ b/.gitea/workflows/security-scheduled.yml @@ -14,6 +14,13 @@ on: jobs: full-tree-scan: runs-on: [self-hosted, on-prem] + # Step ordering mirrors ci.yml: scanners run before `pnpm install` + # so the working tree is not polluted with node_modules content + # (READMEs / fixtures of upstream packages contain demo + # secrets that gitleaks false-positives on by the hundreds). + # The deep-history gitleaks scan here doesn't strictly need it + # (history doesn't contain node_modules), but consistency with + # ci.yml keeps the two workflows reading the same way. steps: # fetch-depth: 0 → full history. The per-PR gitleaks scan is # shallow + working-tree-only; this scheduled job is where we @@ -26,8 +33,6 @@ jobs: - uses: actions/setup-node@v6 with: node-version-file: '.nvmrc' - - run: pnpm install --frozen-lockfile - - run: pnpm audit # Full-tree Trivy (no skip-dirs, no severity filter — the per-PR # gate filters by severity for speed; this run wants the full # surface for the security feed). Manual install + curl, same @@ -69,6 +74,11 @@ jobs: --source . \ --redact \ --exit-code 1 + # npm-advisory check (against pnpm-lock.yaml). Run last so + # `pnpm install` does not pollute the working tree before the + # scanners above. + - run: pnpm install --frozen-lockfile + - run: pnpm audit lighthouse-prod: # Skipped silently if the prod URL hasn't been configured yet.