Open-source linter VibeGuard targets security flaws that recur in AI-generated code

What happened

A security engineer has published a first-person account of building a security linter aimed specifically at AI-generated code and running it against a real production codebase. According to the post on dev.to, David Seagal's tool, called VibeGuard, scanned 533 files in a codebase handed over for audit and returned three critical findings. He writes that all three were produced by AI coding assistants, that all of them had slipped past the organisation's existing security pipeline, and that each one was fixable with a single-line change.

The numbers are self-reported and have not been independently verified. The premise behind the tool, however, is one many security teams will recognise: assistants such as GitHub Copilot, Cursor, ChatGPT, Claude and Gemini were trained on public code containing insecure habits, and they reproduce those habits at speed inside production repositories.

The recurring flaw patterns

Seagal says the rules in VibeGuard come from cataloguing the specific mistakes AI tools make repeatedly, rather than from a generic rule set. Six patterns top his list:

• SQL injection through Python f-strings, where a query selecting a user by an interpolated id looks clean and works, but exposes the database to attackers.
• Hardcoded API keys and passwords, which the author attributes to training examples that placed secrets directly in source files.
• JWT decoding without an algorithms parameter, leaving token verification open to the well-known alg:none bypass.
• Command injection through subprocess calls with shell=True, which lets user-controlled input reach the operating system shell.
• MD5 used for password hashing, a scheme modern hardware can crack in seconds, still appearing in generated authentication code.
• Debug mode left enabled in production settings, which many assistants set by default and which can expose stack details to anyone who triggers an error.

How the tool works

The distinguishing feature, according to the author, is remediation: every finding ships with the actual replacement code rather than a description or a documentation link, so a developer can paste the fix directly. The project is MIT-licensed, runs entirely locally with no cloud calls or telemetry, needs no configuration, and covers Python, JavaScript and TypeScript. It also assigns the scanned codebase a letter grade from A to F; Seagal reports his own project scored an F, with three critical findings in files he had believed were secure. The repository is hosted on GitHub under the author's account, and the project is soliciting contributions of rules for Go, Rust, Java and infrastructure-as-code.

Caveats

Some scepticism is warranted. The audit results, the claim that an existing pipeline missed the findings, and the tool's effectiveness all come from a single author promoting his own project. Several of the flagged patterns, including shell=True usage, weak hashing, hardcoded secrets and string-built SQL, also fall within the scope of established static analysis tools such as Bandit and Semgrep, so teams with mature pipelines may already catch them. What the project appears to add is curation targeted at the specific output of AI assistants, copy-paste-ready fixes, and a low-friction setup. None of that has been validated by third-party testing.

Why it matters

The anecdote is less about one linter than about a shift in how code gets written. If assistants now contribute a substantial share of the changes shipping to production, the insecure patterns they absorbed during training become a systemic, repeatable risk rather than a one-off bug. The detail the author treats as most telling is that the vulnerabilities passed through an existing security setup unnoticed, a reminder that tooling configured for human-written code may not be tuned for the failure modes of generated code. For teams adopting coding assistants, the practical takeaway is straightforward: treat generated code like any other untrusted contribution, put an automated security check between the model and deployment, and prefer tools that lower the cost of acting on findings. Whether VibeGuard itself becomes that layer, or whether established SAST vendors absorb the same lesson, remains an open question.