Files
Dragan Spiridonov a39d4ad010 ci(security): add consumer-side audit gate (npm overrides workaround)
Closes the gap surfaced by the @xenova/transformers → protobufjs
investigation: `npm audit` in this repo lies about user-facing CVEs
because the top-level `overrides` block in package.json forces patched
versions of vulnerable transitives — but npm `overrides` are root-only
by design and do NOT propagate to downstream consumers. A clean
`npm install agentic-qe` from a user's perspective can therefore see
high/critical CVEs that our in-repo audit reports as 0.

Two new gates run against an actual consumer install tree:

1. `consumer-audit` job in npm-publish.yml (BLOCKING pre-publish).
   Packs the local build with `npm pack`, installs the tarball into a
   fresh tmp project, runs `npm audit --audit-level=high` there. Now a
   `needs:` of the publish job, so a CVE invisible to repo-level audit
   still blocks publish.

2. Consumer-audit step + P1 issue creation in post-publish-canary.yml
   (NON-BLOCKING). Same idea, but against the freshly-published tarball
   from the registry — catches discrepancies between what we built and
   what the CDN serves. Findings open an auto-labelled P1 issue
   (security/canary/release) and surface in the run's step summary.

The two together replicate the actual user view at both the
pre-publish gate and the post-publish safety net.

Local simulation of the consumer-audit logic on the current head:
183 packages installed, 0 vulnerabilities — confirming the
@huggingface/transformers migration in 122f223c actually fixed the
consumer view (was 4 high + 1 critical pre-migration).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-18 09:30:35 +00:00
..
2026-04-05 18:51:49 +02:00
2026-04-05 18:51:49 +02:00