Why Traditional SAST Tools Can Miss Bugs in AI-Generated Code

Every time I show someone XploitScan, I get the same question: “Isn't this just Semgrep?”

It's a fair question. There are already a half-dozen well-funded SAST (Static Application Security Testing) tools out there — Semgrep, SonarQube, Snyk Code, Checkmarx, Veracode, GitHub CodeQL. Some of them are excellent. Most of them have been refined over a decade by serious security teams. So why build another one?

The short answer: those tools were built for a world where humans wrote the code, slowly, with code review. AI-generated code breaks every assumption that world was built on. The bugs are different. The volume is different. The audience is different. And on a typical Cursor-generated SaaS app, that mismatch shows up in the same specific ways.

Here's what they get wrong, with specific examples.

1. Their Default Rules Aren't Tuned for AI-Generated Code

Traditional SAST tools were built for enterprise security teams. The audience is a security engineer triaging findings before a pen test or compliance audit. That engineer wants to see everything that could possibly be a vulnerability, even if 95% of it turns out to be noise. Missing a real bug is career-ending. False positives are just Tuesday.

When we first ran this comparison (April 2026, 216 labeled issues), Semgrep 1.86.0 with its security-audit, OWASP, JavaScript, TypeScript and React rulesets scored 91% precision but caught only 40 (19% recall); XploitScan caught 214. Current head-to-head numbers on the larger corpus are on /benchmark. Because we wrote that corpus, it favors our own rules, so we also publish a held-out comparison on public, intentionally vulnerable projects we didn't write.

XploitScan tunes for precision: we aim to show only real, exploitable patterns, and we publish our false-positive rate, along with both benchmarks, at xploitscan.com/benchmark.

2. They Often Lack Rules for AI-Specific Bugs

Many SAST rule packs target the bugs that humans were making when they were written: SQL injection from string concatenation, XSS from raw template output, command injection from shell exec. Those bugs still exist, but AI assistants have their own recurring bugs that default rule packs often don't check for.

Some patterns I see in AI-generated projects that default rule packs often miss:

• Stripe webhook handlers without signature verification — the canonical “walked into the room and gave away $10,000” bug. AI tools generateconst event = req.bodyand call it a day.
• Clerk/Auth0/Supabase webhook handlers without signature verification — same pattern, but for auth events. Attackers can mint fake user records.
• Admin API routes without auth middleware — the AI builds the dashboard, builds the API, forgets the requireAdmin check. Anyone with the URL can hit them.
• CORS wildcards on credentialed endpoints — Access-Control-Allow-Origin: * with credentials: include. Browsers reject this on real requests, but it indicates a complete misunderstanding of CORS.
• Hardcoded API keys in committed .env.example files — the AI “helpfully” fills in the example with the user's real keys.
• SSRF via user-controlled fetch URLs — when the AI builds a “preview link” or “import from URL” feature, it almost never validates the target. (CodeQL's default suite does flag SSRF from user-controlled URLs.)

None of these are exotic. They're the bugs you'd find by reading the code for ten minutes if you knew what to look for. XploitScan's 223 rules are specifically tuned for patterns I've seen AI tools produce.

3. The Output Is Written for Security Engineers

Open a Snyk or Checkmarx report and you'll see findings titled things like “CWE-352: Cross-Site Request Forgery (CSRF)” with descriptions full of acronyms (CSP, CORS, MITM, RCE, HSTS). That's exactly what a security engineer wants — they already know what those mean and they need the formal classification for their audit report.

That is exactly the wrong shape for a non-technical founder who built their app with Cursor. They open the report, see CWE-352, don't know what CWE means, don't know what CSRF means, don't know what to do, and close the tab.

XploitScan writes every finding twice: a one-line plain-English summary of what an attacker can actually do (“Anyone with the URL can mark orders as paid without paying”), and a copy-paste fix snippet. The CWE/OWASP mapping is still there for compliance reports, but it's not the first thing the user sees.

4. They Can't Be Run by Non-Security People

Setting up Checkmarx or Veracode is a multi-day procurement and onboarding process. SonarQube self-hosted requires you to stand up a server, configure authentication, integrate with your build system. Even Semgrep — which is genuinely friendly compared to the others — asks you to install a CLI and choose a ruleset.

The audience for AI-generated code includes a lot of people who built their first app last weekend. They have never seen a CLI before. Asking them to install Semgrep and pick a rule pack is asking them to learn an entire discipline before they can ship a side project.

XploitScan has three flows on purpose: paste your code in the browser, drag a folder, or paste a public GitHub URL. No install. No config. No rule pack picking. The CLI exists for people who want it, but the default flow is “upload and read.”

5. Some of Them Charge Like Enterprise Software

Snyk has a free plan with 100 Snyk Code tests a month; its Team plan starts at $25/month. Checkmarx is enterprise pricing (contact sales; its AWS Marketplace listing sets a USD 30,000 one-year minimum). Veracode is similar. Semgrep's free edition covers up to 10 contributors, including its Pro rules; larger teams pay from $30 per contributor per month.

Enterprise pricing like that makes sense if you're a 50-engineer security team protecting a Fortune 500 codebase. It does not make sense for an indie hacker shipping a $9/month side project. The economics literally don't work — the security tool would cost more than the app makes.

XploitScan's free tier gives you 5 scans a day with the 30 most important rules. Indie is $9/month for 500 scans/month and all 223 rules — the tier actually built for the indie hacker shipping a side project. Pro is $19/month for unlimited scans, PDF reports from scan history, SBOM, Slack/Discord webhooks and a Trust Page. Same product, different audiences, different price points.

When You Should Still Use a Traditional SAST Tool

I'm not arguing the existing tools are bad. They're very good at what they were built for. Use them when:

• You have a security engineer or AppSec team triaging findings
• You need formal compliance audits (SOC 2, FedRAMP, PCI-DSS) with full audit trails
• You have a large hand-written legacy codebase with the bugs the existing tools were designed to find
• You need data-flow analysis across many files (Semgrep Pro and CodeQL are particularly good at this)
• Your codebase is in a language XploitScan doesn't deeply support yet

For a Cursor-built SaaS, an indie hacker side project, or a Y Combinator demo app shipping next week — XploitScan is the safety net. For a Fortune 500 monolith with a dedicated AppSec team — keep using Semgrep or CodeQL. They're not competitors; they're complements aimed at completely different audiences.

Try It on Your Own Code

If you've got a project shipped with Cursor, Bolt, Lovable, or Replit, the fastest way to see what I'm talking about is to just run a scan:

npx xploitscan@latest scan .

No install, no signup. With no account and no ANTHROPIC_API_KEY set, your source code never leaves your machine (it does look up your dependency names and versions on OSV.dev). If you find the same Stripe webhook bug I described above, the previous post walks through the fix.