[Security] Moderate uuid advisory via exceljs — not reachable in our usage; decide accept vs. pin

[TaekeK]

npm audit reports two moderate findings in both app/api and app/ui, left untouched by #985 (which cleared only the high). Nothing is blocked — the CI gate is --audit-level=high — but they will keep appearing in every audit run, so the repo should record a decision rather than re-deciding each time someone looks.

The finding

uuid  <11.1.1
Severity: moderate
uuid: Missing buffer bounds check in v3/v5/v6 when buf is provided
  -> GHSA-w5hq-g745-h8pq
node_modules/uuid
  exceljs  >=3.5.0
  Depends on vulnerable versions of uuid
  node_modules/exceljs

Counted as two because it is present in both packages.

It is not reachable in our dependency graph

The advisory is specific: v3/v5/v6, and only when buf is provided. exceljs@4.4.0 uses uuid in exactly one place, and it is neither:

// node_modules/exceljs/lib/xlsx/xform/sheet/cf-ext/cf-rule-ext-xform.js:1
const {v4: uuidv4} = require('uuid');
...
model.x14Id = `{${uuidv4()}}`.toUpperCase();       // :43
id: model.x14Id || `{${uuidv4()}}`,                // :77

v4, called with no arguments. Wrong function family, and no buf. The vulnerable code path cannot be entered through exceljs.

Why npm audit fix --force is the wrong answer

It would install exceljs@3.4.0 — a major downgrade from the current ^4.4.0, which is a direct dependency of both packages (app/api/package.json:36, app/ui/package.json:29) and is imported by the Excel export in six source files:

• app/api/src/export/excelWorkbook.js, app/api/src/app-bundle.mjs
• app/ui/src/utils/exportToExcel.js, exportAccessPackagesToExcel.js, exportRollupToExcel.js, components/AboutPage.jsx

And there is no upgrade path: 4.4.0 is the latest published exceljs, and it pins uuid: ^8.3.0. So the choice is not "fix or don't" — it is "accept, or break the Excel export to silence a finding we cannot reach".

Decision needed

Recommended: accept and document. Options, roughly in order of preference:

1. Record it as an accepted risk — a note in docs/reference/sbom.md or the maintenance-audit doc, with the reachability analysis above so it does not have to be re-derived. Costs nothing, changes no code.
2. npm audit --audit-level=high already ignores it, so no CI change is needed. If the noise in local npm audit output is the real irritant, an overrides entry forcing uuid@^11 under exceljs would clear it — but that ships an untested uuid major into exceljs's only call site to fix something unreachable, which is a worse trade than the noise.
3. Do nothing and revisit when exceljs publishes past 4.4.0. Effectively option 1 without the note, i.e. this gets re-investigated by whoever next reads an audit.

Not routed into the DoR pipeline deliberately: this is a decision to record, not a defect to build.

Related

• build(deps): bump nanoid to 3.3.18 to clear GHSA-2v37-7h3g-55p8 #985 — cleared the high (nanoid GHSA-2v37-7h3g-55p8); these two were explicitly left.
• [CI] Lockfile-only PRs skip both Vitest jobs — every npm Dependabot PR ships untested #997 — lockfile-only PRs skip the Vitest jobs, which is why dependency changes here need extra care.