lock-file

Quick SummaryCopy Anchor Link

Vulnerability and RiskCopy Anchor Link

Vulnerability: Missing dependency lock files (e.g., package-lock.json, yarn.lock) in a project. Without a lock file, the package manager may install different versions of dependencies across different environments or developer machines.

Risk: Dependency version drift can lead to "it works on my machine" bugs, but more critically, it opens the door for dependency confusion and supply chain attacks. If a malicious package is published with a version satisfy a range in package.json, it might be installed automatically if no lock file pins the known-good version.

Error Message FormatCopy Anchor Link

The rule provides LLM-optimized error messages (Compact 2-line format) with actionable security guidance:

🔒 CWE-829 OWASP:M2 | Missing Lock File detected | HIGH [DeterministicBuilds]
   Fix: Run 'npm install' or equivalent to generate a lock file and commit it | https://cwe.mitre.org/data/definitions/829.html

Message ComponentsCopy Anchor Link

Rule DetailsCopy Anchor Link

This rule ensures that a package lock file exists for the configured package manager. Lock files are critical for supply chain security as they ensure deterministic builds and prevent unexpected dependency updates.

Why This MattersCopy Anchor Link

ConfigurationCopy Anchor Link

This rule supports the following configuration in your ESLint config:

{
  "rules": {
    "node-security/lock-file": ["error", {
      "packageManager": "npm" // "npm", "yarn", or "npm"
    }]
  }
}

Where the rule looksCopy Anchor Link

The rule searches from the linted file's directory upward, and stops at the repository root: the nearest ancestor containing .git (a directory, or the .git file of a worktree or submodule). A lock file above the repository — a stray ~/pnpm-lock.yaml, say — is not committed with the project and pins none of its installs, so it does not count. With no .git anywhere above the file, the search continues to the filesystem root.

ExamplesCopy Anchor Link

❌ IncorrectCopy Anchor Link

// Project root without any of the following:
// - package-lock.json (npm)
// - yarn.lock (yarn)
// - npm-lock.yaml (npm)

✅ CorrectCopy Anchor Link

// Project root containing:
// - package-lock.json

Known False NegativesCopy Anchor Link

The following patterns are not detected due to static analysis limitations:

Monorepo ComplexityCopy Anchor Link

Why: In complex monorepos, a lock file might exist at the root but not in sub-packages. If the sub-package is analyzed in isolation, the rule might report a false positive or miss a missing leaf-level lock file if not configured correctly.

Mitigation: Run the check from the workspace root or ensure sub-packages are correctly mapped to their respective lock files.

Alternative Lock FilesCopy Anchor Link

Why: If you use a non-standard or custom package manager that uses a different filename, the rule will not recognize it.

Mitigation: Standardize on npm, yarn, or npm.

ReferencesCopy Anchor Link

• CWE-829: Inclusion of Functionality from Untrusted Control Sphere
• OWASP Mobile Top 10 M2: Inadequate Supply Chain Security
• npm-lockfile-security

⚙️ OptionsCopy Anchor Link

Use this rule

npm install -D oxlint-plugin-node-security

{  "jsPlugins": ["oxlint-plugin-node-security"],  "rules": {    "node-security/lock-file": "error"  }}

import { defineConfig } from 'vite-plus';export default defineConfig({  lint: {    jsPlugins: ['oxlint-plugin-node-security'],    rules: {      'node-security/lock-file': 'error',    },  },});