Articles

Entropy-based credential detection misses a surprising share of hardcoded secrets — because most secrets look like regular strings until you see their context. Our no-hardcoded-credentials rule fired 842 times on vercel/ai. The peer plugin fired 380. I assumed we had better recall — until I sampled. 807 of the 'extra' findings were TypeScript union-type literals, error class names, and the string 'test'. Here's what catches the rest.

{ "$ne": null } as a password bypasses MongoDB auth — no SQL string, no injection your generic linter understands. One install command, four lines of config, and the first run on a 19-line Express login route returns 7 real findings. NoSQL operator injection, the $where RCE behind CVE-2025-23061, and the 16 CWE-mapped ESLint rules built specifically for MongoDB/Mongoose — catching 3 of the 4 bugs below in CI, with the fourth named as the gap it is.

Math.random() is a PRNG, not a CSPRNG — its outputs are predictable once an attacker recovers the internal state. I found this pattern in a 44K-star open-source codebase generating integration API keys. Here is the attack class, the ESLint rule that catches it, and the one-line fix.

38 million weekly downloads. 3 categories of import-related bugs it silently misses. Here's what's in your codebase right now that eslint-plugin-import won't catch — and why 38 million teams haven't noticed.

The codebase had 2 years of feature PRs and zero security audits. A 12-second ESLint run surfaced 47 violations across 6 distinct vulnerability classes — auth bypass, sensitive field leaks, brute-force exposure, and three more. Here's what each one looks like, why experienced developers didn't catch it, and why your AI assistant writes the same six today.

The most-installed security linter on npm flags one safe pattern for every real vulnerability it catches — a 1:1 true-positive-to-false-positive ratio at 27.5% recall. Six plugins benchmarked side-by-side, with the false-positive code samples that train teams to ignore the tool.

I ran 40 real-world vulnerable patterns through 17 ESLint plugins — eslint-plugin-security, SonarJS, Microsoft SDL. The old pinned version crashes on ESLint 9; the current one doesn't crash but still misses SQL injection entirely. Most others miss 60–100%. Here's the reproducible benchmark, re-verified against the current version of every plugin.

The 'most dangerous' AI model fixes 93% of the database vulnerabilities it writes; the 'safest' fixes 45%. Same 700 functions, opposite conclusion. When I broke a 5-model security benchmark down by domain — database, auth, file I/O, command execution — the rankings inverted. Aggregate numbers hide domain expertise. Here's the per-domain data and how to gate it in CI.

Nine flagship ESLint rules. Months of green unit tests, weeks of OSS benchmarking. A 5KB ground-truth corpus failed three of them at F1=1.00 the first time we ran it — and two of the three blind spots are the exact patterns AI assistants emit. Three diagnostics, three fixes, one CI gate, and why both green signals shared one hole.

700 AI-generated functions. 5 models. The cheapest model leads the aggregate leaderboard — but one model writes clean-scanning JWT code where the flagship is flagged every time, and the 'worst' model fixes 93% of database bugs. The rankings don't tell you any of this.

When AI fixes a security bug, the original finding disappears — but 1 in 3 'fixes' quietly introduced a brand-new vulnerability in a different category. I tested this across 3 remediation rounds with Claude (opus alias, Feb 2026 run) using two approaches — ESLint-guided feedback vs. prompt engineering alone. I call it the Hydra Problem, and it exposes a fundamental limit of 'fix it again' workflows.

A reproducible benchmark: @microsoft/eslint-plugin-sdl (17 rules, Angular/Electron/browser-focused) vs the Interlace security plugins, on one Node fixture. SDL's recommended config catches 5 — frontend hardening is exactly why it's the wrong layer for a Node backend, and exactly the gap your AI assistant ships into.