Is owlwarden a replacement for eslint-plugin-security?

Not necessarily. owlwarden adds framework and route context plus an explicit confidence field. Keeping both is reasonable when their rule sets differ.

Why do lint security rules produce so many false positives?

Because they match syntax without knowing what a response, a cookie, or a request is in your framework. owlwarden asks the detected framework's profile instead.

owlwarden and ESLint security

owlwarden vs eslint-plugin-security

The tools cover different jobs. The table compares scope and default behavior so you can decide whether to run one or both.

See owlwarden rules Review the gaps

CapabilityESLint securityowlwarden

SetupAlready in lintOne command

Framework contextSyntaxProfiles

ConfidenceNoExplicit

Agent configNoYes

Scope and defaults differ. Run both when you need both sets of checks.

What the ESLint plugin provides

Zero marginal setup. It is an ESLint plugin, and you already run ESLint.
Editor integration for free. Squiggles where you type, with no second process.

What owlwarden adds

It knows what a response is. reply.send in Fastify, NextResponse.json in Next.js, ctx.body in Koa. A lint rule matching .stack fires on res.json({ stack: project.stack }) too.
Confidence is a field. possible findings are shown and do not fail CI on their own.
The fix is in the finding. Written for your framework, with the corrected code.
It reads your agent configuration. No lint rule does.

How precision is tested

Each rule has a vulnerable fixture, a clean twin that must stay silent, and on the agent surface a tempting fixture: a legitimate configuration that shares surface features with the vulnerable one, whose silence is the assertion. Rules and tested examples.

Other comparisons

All rules / Coverage, gaps included / Offline