SQL injection has topped the OWASP list for over a decade. Despite better frameworks and ORMs, it still causes some of the biggest breaches in production — because developers merge code that introduces it without realising, and static analysis misses context.
Why static scanners miss SQLi
Most SAST tools pattern-match on raw string concatenation into SQL. They miss injection when it happens through:
- ORM
raw()escape hatches (Django, Sequelize, TypeORM) - Stored procedures built from user input
- Second-order injection — data written safely, used unsafely later
- Query fragments assembled across function calls
A rule looking for f"SELECT * FROM {table}" catches the obvious case. A rule looking for the chain from controller input → service layer → repository layer → database call is another problem entirely.
What dynamic testing adds
Dynamic testing — sending actual SQL payloads to a running application — catches what static analysis can't. Tools like sqlmap have been doing this for years. The problem is they require:
- A running instance of the application
- Manual configuration of endpoints and parameters
- Someone to interpret and triage the output
This workflow doesn't fit into a PR review loop, and it's too slow and expensive for most startup security budgets.
The AI-native approach
Modern AI security tools attack this from two angles simultaneously:
At PR time: semantic diff analysis
When a developer opens a PR, an AI agent reads the diff in context — not just the changed lines, but the functions they call, the data flow from request to database, and historical findings in the same files. If a new parameter reaches a raw query without going through parameterization, it flags it with a working PoC, not just "potential SQL injection at line 42."
In production: active probing
Against running infrastructure, agents can crawl the application, identify form inputs and API endpoints, classify them by what they likely query, and run targeted payloads with escalating aggressiveness based on what they find. Error-based, boolean-based, time-based — a coordinated battery of injection techniques, with an AI layer deciding which approach fits which endpoint.
Setting up automated SQLi detection
With BattleTest, you get both layers out of the box:
PR review layer
Install the GitHub App, and every PR gets a security review that includes data flow analysis for injection vulnerabilities. The agent traces parameter handling from your HTTP layer to your database layer and flags bypasses of your ORM's safe query interface.
Live battletest layer
Add your staging or production domain as a target. The crawler maps your endpoints, and the security agent runs injection tests against each one — with your explicit approval for each permission level (passive recon → active probing → exploit chain).
What good output looks like
A useful SQLi finding is not "SQL injection detected." It includes:
- The specific endpoint or code path
- The parameter name
- A minimal working payload that demonstrates the injection
- The database response or timing anomaly that confirmed it
- Remediation: parameterized query example in your stack's ORM
That's the difference between a finding you act on immediately and a finding that sits in a backlog.
SQLi is a process failure, not a knowledge gap
Nobody ships SQL injection because they've never heard of it. They ship it because no one checks every change for it, every time. Move that check to where the code is — the PR, before merge — and the whole class of bug stops reaching production. Static rules catch the obvious string concatenation; the cases that actually breach companies hide in the data flow, and that's exactly what semantic review is built to follow.