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. On a private repo the file content stays on the runner by default; the deep scan (heisen-slop) is a paid opt-in. Audit it with --print-payload.
Detect → adapt → verify. By default, 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. By default, 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, re-checked on push
The finding is posted on its exact line. For the few classes with a safe deterministic rewrite (TLS verification off, debug on, yaml.load…), a fix is generated AND verified in your runner; otherwise you fix it and the next push re-checks.
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?
Placeholders ($1, ?, :name) and query builders that parameterize are recognized as safe. The gate blocks only what the pull request introduces; on 52,089 ordinary open-source pull requests it blocked 59 (0.11 %). Start in advisory to see for yourself, then switch to blocking.