lock-file

Keywords: lock-file, package-lock, yarn.lock, npm-lock, supply chain, security, ESLint rule, CWE-829, deterministic builds CWE: CWE-829: Inclusion of Functionality from Untrusted Control Sphere
OWASP Mobile: OWASP Mobile Top 10 M2: Inadequate Supply Chain Security

CWE: CWE-829

ESLint Rule: lock-file. This rule is part of eslint-plugin-node-security.

Quick Summary

Vulnerability and Risk

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 Format

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 Components

Rule Details

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 Matters

Configuration

This rule supports the following configuration in your ESLint config:

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

Examples

❌ Incorrect

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

✅ Correct

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

Known False Negatives

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

Monorepo Complexity

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 Files

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.

References

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