Catch SQL injection before it reaches main.
String-concatenated SQL is the oldest breach in the book — and AI writes it faster than anyone can review it. SlopGrade reads each PR on your own runner and blocks the query that builds SQL from user input, before the merge.
User input, concatenated straight into a query.
The id from the request is glued into the SQL string. A crafted id like 1 OR 1=1 dumps the table; a subquery exfiltrates another table. Parameterized queries fix it — the gate makes sure the unparameterized one never merges.
What the AI shipped
What leaves your runner
Path, line, class. The file content never leaves. Audit it with --print-payload.
Detect → adapt → verify. Nothing else leaves.
In your runner, on the diff
The open-source client walks the pull request and flags the pattern locally — intra-function dataflow, no code leaves the machine.
Server verdict + gate
The structural fingerprint is classified server-side. A hard hit blocks the check on a paid private repo; public repos are gated free; the paywall fails open.
Posted inline, fix verified locally
The finding is posted on its exact line. Where a fix exists it is generated AND verified in your runner — only offered once a re-scan proves the issue is gone.
What counts as SQL injection here?
Any query built by concatenating or interpolating untrusted input into the SQL string, in JS/TS, Python, Go or .NET — across common drivers and ORMs' raw-query escape hatches. Parameterized/prepared queries pass.
Will it flag safe parameterized queries?
No — calibrated to 0 false positives on 5,000+ real repos. Placeholders ($1, ?, :name) and query builders that parameterize are recognized as safe. Start in advisory to see for yourself, then switch to blocking.