fix(ci): unblock the audit gate and raise the callback secret floor

[edycutjong]

Why CI is red

The Security — dependencies · secrets job has failed on every run since 2026-08-12T19:22Z, when GHSA-jmr9-qjv8-65gv was updated. The 14:35Z run that day was green; the 23:10Z run — a release-please version bump with no source change — was red. No code change caused it.

None can clear it either:

• extract-zip@2.0.1 is both the latest published release and the vulnerable one
• the advisory's firstPatchedVersion is null and the package is unmaintained
• so neither a version bump nor a pnpm.overrides entry resolves it

It reaches us only as dev tooling — @lhci/cli > lighthouse > puppeteer-core > @puppeteer/browsers > extract-zip — where it unpacks a browser download from a trusted source during pnpm lighthouse. It is not in the shipped agent's dependency graph.

This was skipping the whole pipeline

quality declares needs: [security], and contracts, e2e and perf all gate on quality. One unfixable transitive advisory was therefore skipping Quality, Contracts, E2E, Perf and Ready-to-ship — and the gitleaks scan and check-no-credentials.sh too, since both sit after the failing step inside the same job. The security gate was the part that wasn't running.

The fix

Exempted by advisory id via pnpm's auditConfig, rather than dropping the gate to --prod — every other high in every other dev dependency still fails CI. pnpm audit --audit-level=high now exits 0 and still prints the advisory as 1 ignored rather than hiding it. Carries a comment recording why and when to re-check.

Weak-credential gap, found while confirming the rest of the pipeline

REVOKER_CALLBACK_SECRET had no length floor, so a three-character token was accepted as a valid bearer credential on POST /revoke — the one endpoint that submits transactions. The 20/min limiter bounds online guessing but does not end it: a four-character lowercase secret still falls inside a day.

Anything under 16 characters is now normalised to unset, leaving the endpoint closed and reporting revokeCallback: "unconfigured" rather than looking armed. The 503 names which of the two faults it is.

Enforced on both sides. scripts/deploy-workflow.ts already had its own 8-character check, which would have become a trap once the server floor landed: the deploy would report success and wire the token into the live workflow, and the agent would then refuse every callback with a 503 nobody is watching for. Raised to 16 to match, with the two sites cross-referenced in comments.

Its base64 fixture was also corrected from 12 characters to the 44 that openssl rand -base64 32 actually produces — the command named in the error message has to produce something the check accepts, and a token-sized fixture would have let the floor regress without failing the test.

Verification

Gate	Result
pnpm audit --audit-level=high	exit 0 (1 ignored)
pnpm test	726 passed (+2 new)
pnpm lint	clean
pnpm typecheck	clean
pnpm install --frozen-lockfile	unaffected

Scope note

Everything else in the audit came back clean: CodeQL 0 open alerts, no secrets in history (every 0x[a-f0-9]{64} in tracked files is a Sepolia tx hash), and the /revoke auth path is otherwise well-hardened — constant-time compare, rate limiting applied before the secret is examined, a body cap measured on received bytes rather than trusted Content-Length, owner taken from config and never from the request, and tx-hash idempotency keys.