Files
apf_portal/.gitea/workflows
Julien Gautier 9b6967d352
CI / commits (pull_request) Successful in 2m20s
CI / check (pull_request) Successful in 2m41s
CI / scan (pull_request) Failing after 2m50s
CI / a11y (pull_request) Successful in 2m52s
CI / perf (pull_request) Successful in 5m31s
fix(ci): restrict Trivy to vulnerability scanner only
The first successful Trivy run (after #45 wired the manual install)
came back red on three "secret" findings, all of them demo RSA
private keys embedded in the README / test fixtures of a
cryptographic npm package, sitting deep in `.pnpm-store/v10/files/`
where pnpm content-addressably caches its packages. They are not
our secrets.

Two observations:

- The job already chains `gitleaks/gitleaks-action@v2` after Trivy
  — running two secret scanners over the same tree is just twice
  the false-positive surface.
- Trivy's own log helpfully suggests `--scanners vuln` when secret
  scanning is not the focus, and ADR-0015 always framed this step
  as "dependency vulnerability scan", singular.

Restrict Trivy to `--scanners vuln` so it only runs the vuln check
(against `pnpm-lock.yaml`, complementing `pnpm audit`'s npm-advisory
view with Trivy's broader source). Gitleaks remains the single
secret-scan source.

No `--skip-dirs` change needed: the vuln scan reads `pnpm-lock.yaml`,
not the unpacked store contents.
2026-05-07 12:42:42 +02:00
..