fix(ci): restrict Trivy to vulnerability scanner only (#49)
## Summary First successful Trivy run (post #45's manual install) came back red on three "secret" findings — all demo RSA private keys embedded in the README / test fixtures of a cryptographic npm package, sitting deep in `.pnpm-store/v10/files/...`. None of them are our secrets. Two observations: - The `scan` job already chains `gitleaks/gitleaks-action@v2` right after Trivy. Running two secret scanners over the same tree just doubles the false-positive surface. - Trivy's own log suggests `--scanners vuln` when secret scanning isn't the focus. And [ADR-0015](docs/decisions/0015-cicd-gitea-actions.md) always framed this step as "dependency vulnerability scan" — singular. Restrict Trivy to `--scanners vuln`. Result: vuln scan against `pnpm-lock.yaml` complementing `pnpm audit` (which uses the npm advisory DB; Trivy's DB is broader, sources from OSV/GHSA/etc.). Gitleaks stays the single secret-scan source. No `--skip-dirs` change needed: vuln scanning reads `pnpm-lock.yaml`, not the unpacked store. ## Test plan - [ ] `scan` job goes green end-to-end on this PR — `pnpm ci:audit` ✓, `Install Trivy` ✓, `Run Trivy` ✓ (no secret findings reported), `gitleaks` ✓. - [ ] On `push` to main post-merge, scan stays green. - [ ] Future Trivy bumps (manual, see workflow comment) keep this `--scanners vuln` flag. --------- Co-authored-by: Julien Gautier <julien.gautier@apf.asso.fr> Reviewed-on: #49
This commit was merged in pull request #49.
This commit is contained in: