Skip to content

OA003.md

Latest commit

 

History

History
84 lines (57 loc) · 3.23 KB

OA003.md

File metadata and controls

84 lines (57 loc) · 3.23 KB
Raw

OA003: Wrong section

Severity: high  ·  Action: move

What it catches

A package manager mismatch between the project's lockfile and the section where overrides are declared:

Project PM Bad section
npm (has package-lock.json) pnpm.overrides
pnpm (has pnpm-lock.yaml) top-level overrides
yarn (has yarn.lock) anything other than resolutions

The wrong section is silently ignored by the active package manager. Security pins sitting there are non-functional: they look correct in the file and accomplish nothing on install.

Example: the canonical footgun

// package-lock.json exists -> this is an npm project
{
  "pnpm": {
    "overrides": {
      "postcss": "8.5.15"   // <- npm ignores pnpm.overrides entirely
    }
  }
}

Output:

HIGH (1)
--------
  OA003  postcss
    package.json/pnpm/overrides/postcss
    Override declared in wrong package-manager section
    fix: applyable patch (1 op)

The fix is an RFC 6902 move patch:

{ "op": "move", "from": "/pnpm/overrides/postcss", "path": "/overrides/postcss" }

Why it matters

This is the single highest-impact category of override hygiene problem in the wild. Two real-world failure modes:

  1. Project migrated package managers. Started life as a pnpm project, switched to npm (or vice versa). The overrides were never moved.
  2. Copy-pasted from a different project. Developer borrowed a snippet from a pnpm project's README and dropped it into an npm package.json.

In both cases, every code review reads the override as "we're pinning postcss for CVE-X". Every install actually resolves postcss to whatever a transitive dep asks for, completely unconstrained.

This is why OA003 is severity high: the gap between perceived posture and actual posture is large, and the failure is silent.

Package-manager priority

Detection follows the same priority as the rest of the tool:

  1. Most-recently-modified lockfile wins.
  2. packageManager field in package.json.
  3. pnpm-workspace.yaml presence -> pnpm.

If both lockfiles exist and the older one wins by mtime, the project is treated as the older PM and the newer-PM section gets flagged. Run npm prune / pnpm install to refresh whichever lockfile reflects the real choice.

How to fix

cve-lite overrides --fix --rule OA003

The fixer applies the RFC 6902 move patch and rewrites package.json in place (atomic write that preserves your indent and trailing-newline style). Re-run npm install / pnpm install afterwards to actually apply the override at install time.

When you might want to keep both sections

Almost never. But a library author publishing a package that should be installable under both npm and pnpm consumers may want to declare both. The tool doesn't currently distinguish library projects from app projects; file an issue if this matters for your case.

References