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.