ci: adopt the shared osv-scan lane (infra#104)

[bdelanghe]

Byte-identical copy of templates/deps.yml pinned to osv-scan.yml@162accb, verified with diff. Adopted at hard-fail (ci-workflows#15).

Real coverage

This repo carries deno.lock, so the scan has something to work on — green here will mean "scanned and clean", not "nothing to scan".

Deno is the harder ecosystem to remediate

Worth flagging up front: static-mcp needed a parent bump and a lockfile promotion for the same three transitive packages that npm resolved correctly on a plain relock (bounded-tools-mcp#3 cleared all five findings at rung 1, no manifest change). If this lane reds, rung 1 is less likely to suffice here than it was on the npm repos.

Triage order if red

REMEDIATION.md — rung 1 first, stop at the first rung that works, don't skip to an acceptance. Grace is a dated exception now, not a default.

---

Generated by Claude Code

[bdelanghe]

osv / osv-scan is red with 9 advisories across 4 packages. I can fix half of it and am blocked on the other half by an environment egress denial, so I'm reporting rather than pushing something unverified.

The findings

Targets are the highest fix per package — fast-uri alone carries four advisories with four different fix lines, and taking the first row would leave three live.

package	locked	target	why
ajv	8.17.1	8.18.0	GHSA-2g4f-4pwh-qvx6 (5.5)
fast-uri	3.1.0	3.1.4	4 advisories, all 7.5
linkify-it	5.0.0	5.0.2	GHSA-22p9-wv53-3rq4 (8.7), GHSA-v245-v573-v5vm
markdown-it	14.1.0	14.2.0	GHSA-38c4-r59v-3vqw, GHSA-6v5v-wf23-fmfq

Rung 1 clears two of the four — verified

ajv is a direct import at ^8.17.1, so the declared range already permits the fix. A relock resolves ajv 8.20.0 and fast-uri 3.1.4 with no deno.json change.

What blocks the other two

linkify-it and markdown-it come in through lume, imported by pinned URL (https://deno.land/x/lume@v3.1.4/). A lockfile relock can't move them — that's a rung 2 parent bump. Evaluating one means resolving lume's graph, and lume pulls vento from cdn.jsdelivr.net, which this environment's network policy 403s at CONNECT:

"kind": "connect_rejected",
"detail": "gateway answered 403 to CONNECT (policy denial or upstream failure)",
"host": "cdn.jsdelivr.net:443"

deno.land, jsr.io and registry.npmjs.org all resolve fine — it's specifically jsdelivr. Same class of gap as the api.osv.dev denial that started this work, and the durable fix is the same: add the host to cloud-environment.json.

A trap worth recording

deno install on its own does produce a lockfile that scans green — because it drops the lume-derived graph entirely, 52 npm entries down to 7. markdown-it and linkify-it stop being findings because they stop being present. Regenerating through the real entrypoints (deno cache src/unfold/server.ts …) keeps all 52 and is what hits the jsdelivr wall.

That green would have been a lie of exactly the kind this rollout exists to remove, so I'm flagging it for REMEDIATION.md: on deno repos, check the lock's entry count before and after a relock. A shrinking lock is a false green, not a fix.

State

The lockfile in this branch is byte-identical to main — I restored it after each experiment; nothing unverified has been pushed. The lane is honestly red.

Unblocking needs cdn.jsdelivr.net allowlisted; then rung 1 + a lume bump can be evaluated properly.

---

Generated by Claude Code

[bdelanghe]

The jsdelivr blocker is gone — cdn.jsdelivr.net went 000 → 301 live once it was allowlisted, no session restart. 8 of 9 advisories are now cleared. One remains, and it's genuinely stuck upstream.

Cleared

package		advisories
ajv	8.17.1 → 8.20.0	GHSA-2g4f-4pwh-qvx6
fast-uri	3.1.0 → 3.1.4	all four
linkify-it	5.0.0 → 5.0.2	GHSA-22p9-wv53-3rq4 (8.7), GHSA-v245-v573-v5vm
markdown-it	14.1.0 → 14.1.1	GHSA-38c4-r59v-3vqw

Everything except markdown-it came from rung 1 with deno.json untouched. markdown-it needed rung 2 — lume v3.1.4 → v3.2.5.

The one left, and why it isn't laziness

GHSA-6v5v-wf23-fmfq on markdown-it 14.1.1 needs 14.2.0. Latest lume pins 14.1.1 exactly, so no lume version reaches it. I checked deps/markdown_it.ts in v3.2.2, v3.2.4 and v3.2.5 directly rather than inferring.

That leaves a lockfile promotion or a dated acceptance. Both are judgment calls — your call, not mine. It's the lowest-severity finding of the nine (5.3).

A correction

My previous comment said "v3.2.1 is the newest lume published." That was wrong, and wrong in an instructive way: I'd been guessing version numbers one at a time against deno.land, which skipped v3.2.2/v3.2.4/v3.2.5 entirely. Once cdn.deno.land was allowlisted the registry answered definitively — 213 versions, latest v3.2.5 — and that's what made the eighth fix possible. Guessing looked like checking right up until it didn't.

Lock went 52 → 46 → 68

The 52 → 46 dip was correct: what left was nunjucks and its four deps plus a duplicate zod. Nothing in src/ imports lume's nunjucks plugin (site.ts imports json_ld, metas, robots, sitemap, vento), so those were stale entries the committed lock had been carrying. markdown-it stayed present and stayed reported — the proof the scan didn't go quiet by omission. Then lume 3.2.5 brought the count to 68.

Verification limit

deno check src/unfold/site/site.ts passes against the new lume. deno test fails, and failed identically before this change — manifest.ts imports src/unfold/site/site_url.ts, which doesn't exist in the repo. Pre-existing and unrelated to dependencies (verified by stashing), but it does mean the test suite can't corroborate the lume major bump.

---

Generated by Claude Code

[bdelanghe]

Green. 8 of 9 advisories fixed, 2 accepted with expiries — and the second acceptance is one this PR created, which is worth stating plainly.

Rung 3 was tried, and doesn't apply here

REMEDIATION.md says to promote the package to a direct import so the resolver can't keep a stale transitive entry. I did exactly that:

"markdown-it": "npm:markdown-it@^14.2.0"

and relocked. The lock still resolved 14.1.1 and the npm entry count didn't move (68 → 68). The mapping was inert: an import-map entry can only redirect a bare specifier, and lume's is fully qualified (npm:markdown-it@14.1.1). Nothing in src/ imports markdown-it directly either. I reverted the dead mapping rather than commit a manifest diff that fixes nothing.

That's a genuine gap in rung 3's guidance for deno — it works when your code imports the package, not when a URL-imported dependency pins it internally.

The lume bump is a trade, not a free win

Bumping to v3.2.5 cleared one markdown-it advisory and introduced an esbuild one. The esbuild advisory's range is introduced 0.27.3 / fixed 0.28.1, and lume v3.1.4 pinned 0.27.2 — below the range by luck, not design.

	markdown-it	esbuild	findings
lume v3.1.4	14.1.0 — 5.5 + 5.3	0.27.2 clean	2
lume v3.2.5	14.1.1 — 5.3	0.28.0 — 2.5	2

Same count either way. I kept v3.2.5 because its worst is 5.3 rather than 5.5, and the newest lume is where an upstream fix will actually land. v3.2.2 was checked as a possible sweet spot and isn't one — it pins esbuild 0.27.3, already inside the range.

If you'd rather not carry a self-inflicted finding, reverting to v3.1.4 is defensible — it just costs the 5.5.

The acceptances

Both ignoreUntil = 2026-10-31, both carrying the exact curl to re-check whether lume has moved. osv-scanner fails closed once the date passes, so neither becomes permanent by neglect. The esbuild one is CVSS 2.5, local vector, integrity-only (AV:L/AC:H/PR:L/.../C:N/I:L/A:N) — it needs access to a build host.

Net

linkify-it 8.7, four fast-uri 7.5s, ajv, and one markdown-it — fixed. Two lows deferred with dates and removal conditions.

---

Generated by Claude Code