Remediation queue: clear findings and remove report-only grace (it has no expiry and no owner)

[bdelanghe]

The rollout (#2) ships report-only: true as adoption grace so a pre-existing advisory doesn't block instrumentation. Grace is explicitly temporary — the template says "delete this once findings are clear" — but nothing enforces that. No expiry, no owner, no reminder.

That's the same failure shape as required-baseline.yml: a control that looks green while gating nothing. This issue exists so it doesn't become that.

Queue

repo	finding	fix
gh-project-room	GHSA-frvp-7c67-39w9 · @hono/node-server 1.19.14 → 2.0.5 · transitive via @modelcontextprotocol/sdk, from deno.lock	relock; SDK 1.30.0 widened its range to ^1.19.9 || ^2.0.5 for exactly this
prx	4 in bun.lock: hono 4.12.19→4.12.21, qs 6.15.1→6.15.2, ws 8.20.0→8.20.1 and →8.21.0 (incl. CVSS 7.5 GHSA-96hv-2xvq-fx4p)	bun update the four, run tests
site	3 known high (0 critical) via conformance-kit vuln-gate, threshold 0	enumerate from the run log, relock or accept with reason
site-mcp	not enumerated	read the osv run log
static-mcp	not enumerated	read the osv run log
verbspec-mcp	not enumerated	read the osv run log

Every other adopted repo scanned clean and runs at default hard-fail — grace is only on these.

Per repo

1. Read the osv run log for the finding table.
2. Relock (deno install, bun update, npm update as appropriate) and run the repo's tests.
3. If upstream has no fix: osv-scanner.toml with an [[IgnoredVulns]] entry and a written reason — reviewable, not a silent weakening.
4. Delete the report-only: true line (and the now-dangling with: block) from .github/workflows/deps.yml.
5. Confirm the lane goes green at hard-fail.

Precedent

front-desk#70 did exactly this end to end: maiden scan caught GHSA-frvp-7c67-39w9, relock took @hono/node-server to 2.0.12, 172/172 tests passed, lane green at hard-fail. That repo never needed grace.

Done when

• All six cleared or explicitly accepted
• Zero occurrences of report-only: true across the org
• Consider whether the shared lane should warn on grace older than N days so this can't silently recur

Note on scale

Early estimate was ~60% of repos carrying findings, based on wave 1 (5 of 8). That did not hold — waves 3–6 were almost entirely clean. Six repos, not forty. Smaller than feared, but unowned.

[bdelanghe]

Correction + escalation: site's findings are in vendor/conformance-kit/, not in site

I listed site as "3 known high via vuln-gate." That was the vendored gate's count. The shared osv lane found 12+, and grace is currently masking all of them. Enumerated from the run log:

package	version	max CVSS	fixed in	source
tar	6.2.1	8.8 (GHSA-r6q2-hw4h-h46w)	7.5.4	vendor/conformance-kit/integrity/verify/package-lock.json
tar	6.2.1	8.2 (GHSA-qffp-2rhf-9h96)	7.5.10	same
tar	6.2.1	6.9 / 5.3 ×4	7.5.16–7.5.21	same
brace-expansion	5.0.6	7.7 / 7.5	5.0.7 / 5.0.8	vendor/conformance-kit/package-lock.json
fast-uri	3.1.2	7.5 ×2	3.1.3 / 3.1.4	same
postcss	8.5.16	7.5	8.5.18	same
@mozilla/readability	0.5.0	2.9	0.6.0	same

Every single one is inside vendor/conformance-kit/. None are site's own dependencies.

Why this changes the shape of the problem

1. It's not a site problem — it's a conformance-kit problem, inherited by every repo that vendors it. Fixing it once upstream fixes all of them. Fixing it in site alone would be re-vendoring around the symptom.
2. The kit that ships the org's dependency gate is itself carrying the org's worst findings, including two CVSS 8+. That's the sharpest possible argument for #6 — whatever we decide about vuln-gate vs osv-scan, conformance-kit's own lockfiles need updating first.
3. conformance-kit adopted the lane in #47 and merged green. Worth checking whether its own scan sees these — if the kit's CI scans its source tree but the vulnerable lockfiles sit under paths its own run treats differently, that's a coverage gap in the kit, not just stale deps.

Revised queue

repo	status
gh-project-room	✅ cleared — @hono/node-server → 2.0.12, osv green (#88)
conformance-kit	🔴 new top priority — tar, brace-expansion, fast-uri, postcss in its vendored lockfiles; fixes flow to every vendoring repo
site	inherits the above; likely clears by re-vendoring once the kit is fixed
prx	hono, qs, ws ×2 in bun.lock
site-mcp / static-mcp / verbspec-mcp	still unenumerated — read each osv run log

The grace flag just proved its own risk

site's osv check reads green while masking a CVSS 8.8. That is exactly the "green check gating nothing" failure this issue exists to prevent, and it's live right now. Argues for the warn-on-stale-grace idea at the bottom of this issue moving from "consider" to "do".

---

Generated by Claude Code

[bdelanghe]

conformance-kit cleared — top queue item done, first repo at hard-fail

conformance-kit#53 closed: Dependabot #48–#52 took most of the table (tar left the tree entirely via the sigstore bump), #54 fixed the residual root-lock brace-expansion and removed report-only grace — its own osv check then passed at hard-fail, 8/8 green, merged.

Coverage question resolved: not a gap. The lane saw those lockfiles all along; #47 was green because grace downgraded findings to a warning, by design. Which is the cautionary tale for this whole issue — grace works exactly as configured, including when what it's masking is a CVSS 8.8.

Revised queue

repo	status
gh-project-room	✅ cleared (@hono/node-server → 2.0.12) — grace flag still present, should now come off
conformance-kit	✅ cleared, grace off, hard-fail live
site	🔶 unblocked — re-vendor vendor/conformance-kit/ from main@52e5234, findings should clear, then drop grace. Its 3-high vuln-gate failure on #173 likely clears with the same re-vendor.
prx	🔴 hono, qs, ws×2 in bun.lock — needs bun update, untouched
site-mcp / static-mcp / verbspec-mcp	still unenumerated

---

Generated by Claude Code

[bdelanghe]

site cleared and merged — 2 of 3 held PRs unstuck, 2 repos now at hard-fail

site#173 merged at b3b7243. 17/17 checks green including conformance, which had held it all day.

A hypothesis I had wrong, worth recording

I predicted site's conformance/vuln-gate failure would clear with the conformance-kit re-vendor. It didn't — the two failures had entirely separate causes and I only found that by running the gate under CI's own config:

• osv findings — all 12+ inside vendor/conformance-kit/. Fixed by re-vendoring the pinned 49-file subset from conformance-kit@52e5234 and regenerating the hash-pin. tar 6.2.1 gone from integrity/verify entirely.
• vuln-gate 3 highs — site's own devDependencies: sharp (inherited libvips CVE-2026-33327 / 33328 / 35590 / 35591) pulling miniflare and wrangler. Nothing to do with the kit.

The tell was that vuln-gate passed on my first run and failed on the second. CI sets VULN_OMIT_DEV: false; the default is production-only. Had I trusted the first run I'd have declared it fixed and pushed a re-vendor that didn't touch the actual problem. Worth generalizing: run a repo's gate with the repo's CI env, not the gate's defaults.

npm audit fix --package-lock-only cleared all three with wrangler staying inside its declared ^4, so no manifest change.

Queue

repo	status
conformance-kit	✅ cleared, grace off, hard-fail
site	✅ cleared, grace off, hard-fail
gh-project-room	✅ finding cleared — but grace flag still on; dry-run/jsr-check still red for unrelated reasons, so the PR can't merge to remove it
prx	🔴 hono, qs, ws×2 in bun.lock — untouched
site-mcp / static-mcp / verbspec-mcp	still unenumerated

2 of 45 instrumented repos now run at the intended hard-fail steady state. The rest still carry grace — most because they never had findings, which means their grace flag is pure dead weight and could be removed in bulk. That's probably the cheapest remaining win: a sweep removing report-only: true from every repo whose osv run reports zero findings.

---

Generated by Claude Code