Articles

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.

A reproducible fixture benchmark: eslint-plugin-sonarjs (269 rules) vs the Interlace security plugins on 40 known vulnerabilities. SonarJS is one of the best quality linters in the ecosystem — which is exactly why a green run isn't a clean Node.js security bill. Recall 35%, the 26 it misses, why they survive review, and what happens when Claude and Gemini write them. Result JSON linked.

eslint-plugin-security is the foundational, actively-maintained Node security linter — 14 rules, 2.4M+ weekly downloads. On one fixture of 12 vulnerability classes it caught 21 issues and the domain plugins caught 46. Here's the 25-finding gap, why AI-generated code lives in it, and how to layer both.

AI coding assistants are incredible—until they introduce security holes. I ran an experiment asking Claude (Haiku 3.5, Sonnet 4.5, Opus 4.5, Opus 4.6) to generate 80 Node.js functions — 20 real-world prompts across 4 models — with zero security context using my Claude Pro subscription. 65-75% had vulnerabilities. Then I tested if static analysis could help the models fix their own mistakes.

One user-controlled COPY FROM path turns your database into a file reader for /etc/passwd, your .env, and SSH keys. Here is why it survives code review, why AI assistants reintroduce it, and the one ESLint rule that tiers and blocks it.

Control a connection's search_path and every unqualified query silently resolves to your schema. The obscure-but-lethal PostgreSQL attack, why SET can't be parameterized, the real fixes, and the CWE-426 ESLint rule that catches it.

No helmet, a CORS origin that reflects the caller, an unbounded req.body, a redirect that echoes user input — four Express apps with nothing wrong on screen. The install, the flat config, and the 14 CWE-mapped ESLint rules that catch the missing middleware in CI.

Missing @UseGuards, unvalidated @Body(), entities leaking passwordHash — NestJS security lives in decorators, and an absent decorator produces no diff. 6 CWE-mapped ESLint rules that catch all of it in CI: vulnerable code, why review missed it, the fix, and the real lint output.