Support path-scoped audit ignores with expiry dates (like audit-ci's allowlist)

[skrtheboss]

Contribution

• I'd be willing to implement this feature (contributing guide)

Describe the user story

pnpm audit lets you suppress advisories via audit.ignore, a flat list of GHSA IDs in pnpm-workspace.yaml/root manifest. Ignoring a GHSA id suppresses it everywhere, for every module that happens to pull in the vulnerable package, regardless of dependency path.

This is too broad for real-world usage:

1. No path scoping. If we accept a reviewed risk for a vulnerable dependency reached only through one specific parent package (e.g. some-deprecated-plugin > image-size), the same GHSA id also silently suppresses that vulnerability when it's later introduced through a completely different, unreviewed dependency path (e.g. directly as a production dependency, or via an unrelated package). A new, unreviewed occurrence of the same advisory elsewhere in the dependency graph goes unnoticed.
2. No expiry / re-evaluation mechanism. Ignored advisories stay ignored forever with no forcing function to revisit them (e.g. once a patched version becomes available, or a license constraint that blocked upgrading is resolved).

audit-ci (https://github.com/IBM/audit-ci) already solves both problems. Its allowlist entries support:

• Plain GHSA id → ignored everywhere (global).
• GHSA-id|package or GHSA-id|package>subpackage → only ignored when the advisory is reached through that specific dependency path (see lib/allowlist.ts, which detects |/> and treats the entry as path-scoped instead of a bare advisory/module match).
• An object form with active, notes, and expiry fields (lib/nsp-record.ts), so an entry can be documented and automatically stops being honored once expiry passes — forcing a re-audit instead of silently ignoring forever.

Example from our own audit-ci.jsonc:

{
  "GHSA-5p2g-fcmc-qvqq|*docusaurus*>image-size": {
    "active": true,
    "notes": "Ignore this until 30th September 2026. The repository is archived and will not receive a security patch; re-evaluate for a replacement/alternative.",
    "expiry": "2026-09-30T06:00:00.000Z"
  }
}

Describe the solution you'd like

Extend audit.ignore so entries can, optionally:

1. Be scoped to a dependency path, not just a bare GHSA id, e.g.:

audit:
  ignore:
    - GHSA-xxxx-xxxx-xxxx                      # ignored everywhere (current behavior — non-breaking)
    - GHSA-yyyy-yyyy-yyyy|some-package         # only ignored when the advisory comes through this package
    - GHSA-zzzz-zzzz-zzzz|parent-pkg>sub-pkg   # only ignored via this specific dependency chain

2. Optionally carry an expiry timestamp, so the ignore automatically stops applying (and the advisory resurfaces) after a given date. A separate notes field isn't necessary here — pnpm-workspace.yaml is YAML, so a plain # comment above/beside the entry already covers documenting why something is ignored:

audit:
  ignore:
    # Archived package, no patch available; re-evaluate for a replacement.
    - id: GHSA-yyyy-yyyy-yyyy
      path: parent-pkg>sub-pkg
      expiry: 2026-09-30T00:00:00.000Z

Behavior:

• Path-scoped entries only suppress the advisory when reached through the given dependency chain; the same GHSA id introduced via any other path is reported as usual.
• Once expiry passes, pnpm audit should report the advisory again (and ideally warn/fail loudly that a previously-ignored, now-expired entry needs re-evaluation, rather than silently going back to suppressing it).
• Plain string entries (bare GHSA id, no path/expiry) keep today's global, permanent-ignore behavior — fully backward compatible.
• Interacts with audit.ignorePrune: pruning should only drop an entry once it's unused for all of its scoped paths, and expired entries should presumably also be flagged for pruning/review.

This mirrors audit-ci's allowlist model (minus its redundant notes field, since YAML comments already serve that purpose) closely enough that a near drop-in migration path could exist for teams (like ours) currently running audit-ci alongside pnpm just to get this behavior.

Describe the drawbacks of your solution

No response

Describe alternatives you've considered

• Continuing to run audit-ci as a separate tool alongside pnpm audit — this is what we do today, but it duplicates configuration (audit-ci.jsonc vs pnpm-workspace.yaml), duplicates CI steps, and doesn't benefit from pnpm's native audit integration (e.g. lockfile-aware resolution, pnpm audit --fix).
• Tracking expiry dates manually in commit messages/PR descriptions and reviewing on a schedule — doesn't scale and isn't enforced by tooling.