DEV Community

Cover image for I Built a Linter That Catches the Security Bugs AI Assistants Keep Writing
Rishu
Rishu

Posted on

I Built a Linter That Catches the Security Bugs AI Assistants Keep Writing

I've been writing code with AI assistants for a while now. Copilot, Claude, ChatGPT — I've used them all. And for the most part, they're genuinely impressive. They save time. They help me think through problems. They write boilerplate I'd rather not write myself.

But here's the thing nobody talks about enough: AI-generated code has a specific category of bugs that normal linters don't catch.

Not syntax errors. Not style violations. I'm talking about security vulnerabilities, false-confidence patterns, and subtle logic issues that look completely correct — until they're not.

I got burned enough times that I built something about it. It's called hallint, and it's a free, open-source static analysis tool designed specifically for AI-generated code. You can find it on GitHub: github.com/Asyncinnovator/hallint


The Problem With AI Code (That ESLint Won't Help You With)

Traditional linters were designed for human-written code. They're great at catching things humans commonly get wrong — unused variables, missing semicolons, incorrect type usage.

But AI assistants fail differently.

Here are the patterns I kept seeing over and over:

1. Hardcoded secrets

AI assistants will happily write const API_KEY = "sk-abc123..." in your source code. It passes every lint check. It works perfectly in dev. And then you push to GitHub and your key is live in a public repo.

2. SQL injection

// AI generates this and it looks totally fine
const user = await db.query(`SELECT * FROM users WHERE id = ${req.params.id}`)
Enter fullscreen mode Exit fullscreen mode

No ESLint rule will flag this. But it's a textbook SQL injection vector. Every time.

3. Missing auth on route handlers

AI is great at generating CRUD routes. It's not great at remembering to add authentication middleware. You end up with a perfectly structured Express router where half the routes are completely unprotected.

4. Permissive CORS

app.use(cors({ origin: '*' }))
Enter fullscreen mode Exit fullscreen mode

This is a one-liner fix for the CORS errors you see in development. AI assistants suggest it constantly. It's also a wildly bad idea in production.

5. innerHTML with unsanitized strings

element.innerHTML = userInput // XSS waiting to happen
Enter fullscreen mode Exit fullscreen mode

LLMs write this pattern a lot. It's the obvious, readable way to set content — and it's a cross-site scripting vulnerability.


What I Built

hallint is a TypeScript library and CLI tool that scans your codebase for these AI-specific failure patterns.

It uses three detection layers:

  • Regex pattern matching — fast first pass for known bad patterns
  • AST analysis — structural checks that understand code, not just text
  • LLM review (optional) — uses Ollama or another provider to do deeper semantic analysis The idea is simple: it's a linter that knows what AI gets wrong, not just what humans get wrong.

Getting started

No install needed — just run it with npx:

npx @asyncinnovator/hallint-cli ./src
Enter fullscreen mode Exit fullscreen mode

Or scan a specific glob pattern:

npx @asyncinnovator/hallint-cli "./src/**/*.ts"
Enter fullscreen mode Exit fullscreen mode

Only care about serious issues? Filter by severity:

npx @asyncinnovator/hallint-cli ./src --min-severity high
Enter fullscreen mode Exit fullscreen mode

It exits with code 1 on any critical or high finding, which makes it easy to use as a CI gate.

Use it as a library

If you want to integrate it into your own tooling:

npm install @asyncinnovator/hallint
Enter fullscreen mode Exit fullscreen mode
import { scan } from '@asyncinnovator/hallint'

const result = await scan({
  files: ['./src/**/*.ts'],
  rules: 'recommended',
  minSeverity: 'high',
})

result.findings.forEach(f => {
  console.log(`[${f.severity}] ${f.ruleId} ${f.filePath}:${f.line}`)
  console.log(`  ${f.message}`)
  console.log(`  fix: ${f.fix}`)
})
Enter fullscreen mode Exit fullscreen mode

You can also scan a string directly without touching the filesystem:

import { scanSource } from '@asyncinnovator/hallint'

const findings = scanSource(`const apiKey = "sk-abc123def456"`, 'example.ts')
Enter fullscreen mode Exit fullscreen mode

The Rules Shipping

Right now hallint ships with eight rules, all targeting the patterns I described above:

Rule Severity What it catches
hardcoded-secret critical API keys, tokens, passwords in source code
sql-injection critical User input interpolated into SQL queries
unsafe-eval critical eval() or new Function() with dynamic input
missing-auth-check high Route handlers with no auth middleware
xss-innerHTML high Unsanitized strings assigned to innerHTML
permissive-cors high cors({ origin: '*' }) in route handlers
async-no-catch medium async functions with no try/catch or .catch()
http-not-https medium Hardcoded http:// URLs in fetch or axios calls

How It's Different From Running a Regular Linter

ESLint with the right plugins will catch some of this. But there are a few important differences.

Existing linters weren't built with AI failure modes in mind. They weren't designed around the question "what does an AI assistant get wrong?" They were designed around the question "what do humans get wrong?" Those are different questions with different answers.

hallint is designed to be AI-aware. The rules target the specific intersection of "AI generates this confidently" and "this is actually a problem." The goal isn't to be comprehensive — it's to be precise about the failure modes that matter most for AI-generated code.

The LLM layer is something ESLint can't do. When you enable the optional LLM review, hallint can flag issues that don't match a known regex or AST pattern — things like "this auth flow looks structurally correct but has a logical flaw." That's a different category of analysis entirely.


A Real Example

Here's the kind of thing it catches. Say you take some AI-generated Express code:

import express from 'express'
import db from './db'

const app = express()

app.get('/users/:id', async (req, res) => {
  const user = await db.query(
    `SELECT * FROM users WHERE id = ${req.params.id}`
  )
  res.json(user)
})
Enter fullscreen mode Exit fullscreen mode

hallint flags it:

[critical] sql-injection: User input interpolated directly into SQL query.
  Use parameterized queries: db.query('SELECT * FROM users WHERE id = $1', [req.params.id])
  → src/routes/users.ts:6
Enter fullscreen mode Exit fullscreen mode

Clean, direct, tells you exactly what to fix.


Drop It Into CI in 5 Lines

One of the things I wanted from day one was a zero-friction GitHub Actions integration. hallint exits with code 1 on critical or high findings, so this just works:

- uses: actions/checkout@v4
- uses: actions/setup-node@v4
  with:
    node-version: 20
- run: npx @asyncinnovator/hallint-cli ./src --min-severity high
Enter fullscreen mode Exit fullscreen mode

You can also add it as a pre-commit hook via husky if you want to catch issues before they even get pushed.


It's Open Source — Contributions Welcome

The whole thing is MIT licensed and lives at github.com/Asyncinnovator/hallint. Issues and PRs are open.

I think this kind of tooling should exist in public, not behind a paywall. If AI-generated code has specific vulnerability patterns, the entire ecosystem benefits from shared, community-maintained detection rules.

The rule-writing surface is intentionally small — each rule is a single file (~30 lines) with a bad.ts / good.ts fixture. If you've seen an AI-specific pattern that hallint doesn't catch yet, the path from "I noticed this" to "I shipped a fix" is genuinely short. Issues labeled good first issue are pre-scoped and ready to pick up.


hallint is MIT licensed. Free to use in personal and commercial projects.

npm: @asyncinnovator/hallint · @asyncinnovator/hallint-cli

Top comments (0)