audit-severity

Venue: check — A dependency carries a high or critical security advisory.

Rule

npm audit runs over your workspace — the whole installed tree, devDependencies and transitive packages included — and a violation is reported for each advisory at severity high or critical.

Low and moderate advisories are a deliberate pass. They are not “not yet enforced” — they are not enforced. Nobody will ask you to clear them.

There is no suppression mechanism. No inline waiver, no ignore file, no severity override. If you are looking for the flag, there isn’t one, and that is the design.

Reason

The kit lets you reach for third-party packages — a carousel, a map SDK, a date formatter — because a section that has to hand-write everything is a section nobody finishes. The consequence is that your dependency tree ships to a published page we host for a customer, so the supply chain is part of the submission.

This gate is the floor, not a review. Cutting at high/critical is what keeps it a floor: a rule that fired on every transitive moderate would be a rule everyone learned to route around, and the exception would swallow the check. Two severities, no exceptions, and a clear answer to “can I ship this.”

Fix

In order of preference:

1. npm audit fix — resolves most advisories by moving a transitive dependency inside its existing range.
2. Upgrade the offending package. If the fix is in a new major, npm audit fix --force will take it, but read what it changes first.
3. Drop the package. An advisory with no fix available is a package with no fix available. Replace it, or hand-write the part of it you actually use.

Then re-run npm audit and commit the lockfile.

Before

$ npm audit
# npm audit report

marked  <4.0.10
Severity: high
Inefficient Regular Expression Complexity in marked
fix available via `npm audit fix --force`

1 high severity vulnerability

package.json

{
  "dependencies": {
    "marked": "^3.0.8"
  }
}

After

package.json

{
  "dependencies": {
    "marked": "^14.1.2"
  }
}

$ npm audit
found 0 vulnerabilities

When the advisory is in a package you did not choose

It can be one of the toolchain devDependencies your workspace was scaffolded with — eslint, typescript, vite, tailwindcss — or something underneath one of them. The answer is still step 2, applied to that package: upgrade it, rather than chase the transitive dependency it pulled in. An overrides pin on the vulnerable transitive package is the tempting shortcut and usually the wrong one — the version that clears the advisory is often incompatible with the dependent that requires it, so the audit goes green and the tool breaks at runtime.

When such an upgrade crosses a major, update @homepages/eslint-plugin-template in the same install: the preset declares eslint and @typescript-eslint/parser as peers, so a toolchain major its range does not cover fails at npm install with a peer conflict rather than at lint time.

When the audit could not run

When check cannot get an answer out of npm audit, this rule reports nothing was measured rather than a violation:

⚠ workspace — 1 gate(s) not measured
    [template-kit/audit-severity] npm audit returned no parseable report, so no advisory was ever read.
    not measured: audit-severity

No advisory was read, so nothing here is a claim about your dependencies. The usual causes are npm not being resolvable from the environment check runs in, or no network access to reach the registry’s advisory feed.

This is a coverage hole, not a finding — it does not fail the run, exactly like lockfile-missing. It is also not a pass: a submission is only accepted on a run that measured every gate, so this has to be cleared before yours is looked at.

Run the command yourself in the workspace:

npm audit --json

Whatever stops it printing a JSON report is the thing to fix, then re-run check.

See also

• lockfile-stale — commit the lockfile the fix regenerated; it answers an npm it could not run the same way this rule does.