ci: Dependency audit cannot pass — GHSA-vfj7-8cjw-p6xm names braces >=3.0.4, which was never published #129

What happened

I ran: pnpm audit --audit-level high, on a clean checkout of main with nothing of mine applied.

I expected: it to pass, as it did on main on 2 October (security workflow run #152).

It did: fail on a high advisory with no published fix.

GHSA-vfj7-8cjw-p6xm   braces   high
Vulnerable versions   <=3.0.3
Patched versions      >=3.0.4

The advisory names >=3.0.4 as the patch. That version does not exist. Against registry.npmjs.org:

pnpm view braces dist-tags   ->  { latest: '3.0.3' }
pnpm view braces versions    ->  ... '3.0.2', '3.0.3'   (nothing above)

So pnpm audit --audit-level high cannot pass, and the Dependency audit job fails on every pull request until something changes upstream. It is currently red on #126, #127 and #128, whose twelve test legs all pass.

memnox doctor

Not applicable — this is the repository's own dependency audit in CI, not an installed
runtime, so doctor output has no bearing on it.

Reproduced on a clean checkout of main at 82c2667 with pnpm install --frozen-lockfile.

Version

main at 82c2667. Node 24.10.0, pnpm 11.5.0.

Platform

macOS

Anything else

It cannot be fixed by moving a dependency. I tried the two obvious routes before reporting.

An override is impossible, because there is no version to override to:

overrides:
  braces: '>=3.0.4'

The latest release of braces is "3.0.3".

Worth noting on the way past: overrides in pnpm-workspace.yaml was not honoured here, and pnpm.overrides in package.json is refused outright — pnpm 11 prints The "pnpm" field in package.json is no longer read by pnpm. Whichever place is right for this repo, neither currently works, which is its own small trap for the next person reaching for an override.

Bumping the dependency that pulls it does not help either. @changesets/cli is pinned ^2.27.0 and 3.0.3 is out; @manypkg/get-packages@3 drops globby, so the changesets path does go away. The advisory stays, because something else pulls the same chain:

before:  braces@3.0.3 <- micromatch <- fast-glob <- globby <- @manypkg/get-packages <- @changesets/cli
after:   braces@3.0.3 <- micromatch <- fast-glob <- knip

knip reaches micromatch@4.0.8 on its own, and so would anything else built on fast-glob. I reverted that bump rather than push it: it is a major version of the tool pnpm ship runs, and it would not have fixed this anyway.

So the choice is a policy one, which is why I am filing it rather than pushing something. As far as I can see it is one of:

• Ignore this advisory, documented. braces is a devDependency only — it is not in anything the four packages publish — and there is no patch to take. auditConfig.ignoreGhsas would do it. For a project that is itself a security control, silencing a high advisory seemed like your call rather than mine.
• Qualify the gate, so a high advisory with no available patch reports rather than blocks, and a patchable one still fails.
• Leave it red until braces publishes, and merge past the check.

Happy to open the PR for whichever you prefer, with the reasoning in a comment next to it so the next person does not have to rediscover that 3.0.4 was never released.