{
  "low": true,
  "moderate": true,
  "high": true,
  "critical": true,
  "report-type": "summary",
  "$allowlist-rationale": {
    "$status": "EMPTY as of 2026-09-07 — nothing is suppressed. The notes below stay because this allowlist has filled up before and will again; they are the playbook, not a record of active exceptions.",
    "$root-cause": "Entries land here when an advisory resolves to a dependency BUNDLED INSIDE THE npm CLI TARBALL (node_modules/npm/node_modules/*). npm ships those via bundleDependencies, so `overrides` in package.json cannot reach them — raising the `npm` override itself is the only lever. The npm CLI is dev/release-only (devDependencies -> @semantic-release/npm -> npm) and is stripped from the runtime Docker image, which is why suppressing was acceptable while no patched npm existed. Note @semantic-release/npm@13.1.5 declares `npm: ^11.6.2`, so a fix landing only in npm 12.x would need that constraint revisited.",
    "$cleared-2026-09-07": "npm 11.19.1 rebundled the entire stale set at patched versions in one release — tar 7.5.22 (needed >=7.5.21), undici 6.28.0, ip-address 10.5.0, brace-expansion 5.0.9 — clearing GHSA-r292-9mhp-454m, GHSA-8xcm-r25x-g524, GHSA-m8rv-5g2x-5cg5, GHSA-v3r7-h72x-cjcm, GHSA-mwp4-54f8-5fhr, GHSA-4xrf-jv44-h6hh, GHSA-22jq-vg5j-6vgg, GHSA-mh99-v99m-4gvg and GHSA-rgw5-rvv9-x895 together. `overrides.npm` is now pinned at `^11.19.1` (raised from `^11.16.0`), so this repo DECLARES 11.19.1 as its minimum rather than merely happening to install it. $root-cause names that key as the only lever over the bundled set, and the pin is what makes the lever declarative instead of incidental. Two things to keep in proportion: resolution takes the highest match, so the installed npm would be >=11.19.1 anyway and `npm ci` reads the lockfile regardless — the pin buys intent, not a behaviour change; and with the allowlist empty, any regression fails the gate loudly rather than being silently suppressed. Going forward, re-derive this floor rather than trusting it. A floor that was correct when written goes stale the moment npm rebundles again, and a stale floor mistaken for a vetted one is precisely how `^11.16.0` outlived its own rationale. Always check whether a newer npm rebundles the package before adding an entry back.",
    "$scoping": "If an entry is ever needed again, path-scope it (`GHSA-ID|path`) rather than using a bare advisory ID, so a REACHABLE reintroduction of the same advisory still fails CI. Render the path the way audit-ci does — from npm audit's `effects` chain, NOT the full path to the root: npm's bundled tar renders as `npm>tar`, and a package nothing depends on renders as its bare name. This bit CI on 2026-09-07: the entry read `semantic-release>@semantic-release/npm>npm>tar` and silently stopped matching once the graph shifted. audit-ci only prints `Consider not allowlisting path: ...` for a stale entry and still exits 0, so that warning is a real signal — an advisory you believe is suppressed no longer is."
  },
  "allowlist": []
}