Benchmark Report: Why Most Security Linters Miss 80% of Vulnerabilities

Generic linting creates a false sense of security. We benchmarked the industry's leading tools and found they miss 80% of critical vulnerabilities. Here is the data-driven case for deep static analysis.

I ran a rigorous benchmark comparing the two major ESLint security plugins. This article covers the full methodology, test files, and results—including why 0 false positives matters more than raw speed.

Benchmark Methodology

The Test Files

vulnerable.js (218 lines) - Contains 12 categories of real vulnerabilities:

// 1. Command Injection
exec(`ls -la ${userInput}`);
execSync("echo " + userInput);
spawn("bash", ["-c", userInput]);

// 2. Path Traversal
fs.readFile(filename, "utf8", callback);
fs.readFileSync(filename);

// 3. Object Injection
obj[key] = value;
data[key][value] = "test";

// 4. SQL Injection
db.query("SELECT * FROM users WHERE id = " + userId);

// 5. Code Execution
eval(code);
new Function(code);

// 6. Regex DoS
const evilRegex = /^(a+)+$/;
new RegExp(userInput);

// 7. Weak Cryptography
crypto.createHash("md5").update(password);
Math.random().toString(36);

// 8. Timing Attacks
if (inputToken === storedToken) {
  return true;
}

// 9. XSS
document.getElementById("output").innerHTML = userContent;

// 10. Insecure Cookies
document.cookie = `${name}=${value}`;

// 11. Dynamic Require
require(moduleName);

// 12. Buffer Issues
const buf = new Buffer(size);

safe-patterns.js (167 lines) - Contains defensive patterns that should NOT trigger warnings:

// Safe: Validated key access with allowlist
const VALID_KEYS = ["name", "email", "age"];
if (VALID_KEYS.includes(key)) {
  return obj[key];
}

// Safe: hasOwnProperty check
if (Object.prototype.hasOwnProperty.call(obj, key)) {
  return obj[key];
}

// Safe: Path validation with startsWith
if (!safePath.startsWith(SAFE_DIR)) throw new Error("Invalid");
fs.readFileSync(safePath);

// Safe: Timing-safe comparison
crypto.timingSafeEqual(bufA, bufB);

// Safe: DOMPurify sanitization
const clean = DOMPurify.sanitize(userContent);
element.innerHTML = clean;

Benchmark Configuration

• Iterations: 5 runs per test
• Metrics: Average time, min/max time, issues found, rules triggered
• Assumption: Run-to-run variance estimated at ≤15%; reported differences (2.83x, 3.8x) exceed this margin

Test 1: Fair Fight (Same 14 Rules)

First, I tested both plugins with only the 14 equivalent rules that exist in both packages. This ensures an apples-to-apples comparison.

Results

Rule-by-Rule Detection

Key Finding: With the same rule categories, secure-coding finds 38% more issues while maintaining nearly identical efficiency per issue.

Test 2: Recommended Presets

Next, I tested each plugin's recommended configuration—the out-of-box experience.

Results

Detection Breakdown

secure-coding rules triggered on vulnerable.js:

• no-unvalidated-user-input: 8 issues
• detect-non-literal-fs-filename: 5 issues
• detect-object-injection: 5 issues
• no-timing-attack: 5 issues
• detect-child-process: 4 issues
• database-injection: 4 issues
• no-unsafe-deserialization: 4 issues
• no-sql-injection: 3 issues
• detect-non-literal-regexp: 3 issues
• no-hardcoded-credentials: 2 issues
• detect-eval-with-expression: 2 issues
• no-weak-crypto: 2 issues
... and 18 more categories

security rules triggered:

• detect-non-literal-fs-filename: 5 issues
• detect-object-injection: 5 issues
• detect-child-process: 2 issues
• detect-unsafe-regex: 2 issues
... and 6 more categories

Test 3: False Positive Analysis

This is where precision matters. I ran both plugins against safe-patterns.js—a file with only safe, validated code.

Results

The 4 False Positives from eslint-plugin-security

FP #1: Validated key access (line 38)

// Pattern: Allowlist validation before access
const VALID_KEYS = ["name", "email", "age"];
function getField(obj, key) {
  if (VALID_KEYS.includes(key)) {
    return obj[key]; // ⚠️ security flags "Generic Object Injection Sink"
  }
}

The developer validated key against an allowlist. This is a safe pattern.

FP #2: hasOwnProperty check (line 45)

// Pattern: Property existence check before access
function safeGet(obj, key) {
  if (Object.prototype.hasOwnProperty.call(obj, key)) {
    return obj[key]; // ⚠️ security flags "Generic Object Injection Sink"
  }
}

hasOwnProperty ensures key exists on the object itself, not the prototype chain.

FP #3: Guard clause with throw (line 153)

// Pattern: Early exit guard clause
const ALLOWED_THEMES = ["light", "dark", "system"];
function setTheme(userTheme) {
  if (!ALLOWED_THEMES.includes(userTheme)) {
    throw new Error("Invalid theme");
  }
  config[userTheme] = true; // ⚠️ security flags despite throw guard
}

The throw acts as a guard—execution cannot reach line 153 with an invalid theme.

FP #4: Path validation (line 107)

// Pattern: basename + startsWith validation
function safeReadFile(userFilename) {
  const safeName = path.basename(userFilename);
  const safePath = path.join(SAFE_DIR, safeName);

  if (!safePath.startsWith(SAFE_DIR)) {
    throw new Error("Invalid path");
  }

  return fs.readFileSync(safePath); // ⚠️ security flags "non literal argument"
}

The path is fully validated: basename strips traversal, startsWith confirms the directory.

Why secure-coding Avoids These

We use AST-based validation detection:

OWASP Coverage Comparison

LLM/AI Message Comparison

Security rules are increasingly consumed by AI coding assistants. Compare the messages:

eslint-plugin-security:

Found child_process.exec() with non Literal first argument

eslint-plugin-secure-coding:

🔒 CWE-78 OWASP:A03-Injection CVSS:9.8 | Command injection detected | CRITICAL
   Fix: Use execFile/spawn with {shell: false} and array args
   📚 https://owasp.org/www-community/attacks/Command_Injection

Feature & Documentation Comparison

Beyond detection metrics, here's the full feature comparison:

Final Verdict

Key Insights

1. Performance per issue matters — secure-coding is 2.83x more efficient per detected issue.

2. "Speed advantage" = detection gap — The incumbent is faster because it misses vulnerabilities.

3. 0 false positives — Every flagged issue is a real vulnerability.

4. 6x more rules — 89 rules vs 14, covering web, mobile, API, and AI security.

5. Developer experience — Every rule includes CWE/OWASP references, CVSS scores, and 3-6 fix suggestions.

Try It Yourself

npm install eslint-plugin-secure-coding --save-dev

// eslint.config.js
import secureCoding from "eslint-plugin-secure-coding";

export default [secureCoding.configs.recommended];

The benchmark code is open source: benchmark on GitHub

The Interlace ESLint Ecosystem Interlace is a high-fidelity suite of static code analyzers designed to automate security, performance, and reliability for the modern Node.js stack. With over 330 rules across 18 specialized plugins, it provides 100% coverage for OWASP Top 10, LLM Security, and Database Hardening.

Explore the full Documentation

© 2026 Ofri Peretz. All rights reserved.

Build Securely. I'm Ofri Peretz, a Security Engineering Leader and the architect of the Interlace Ecosystem. I build static analysis standards that automate security and performance for Node.js fleets at scale.

ofriperetz.dev | LinkedIn | GitHub