Benchmark · edition 1

Score a patch.

Can an AI patch stop SQL injection without breaking valid inputs? Start with one of four test modules.

Browse the modules and published pilot results now. Live patch scoring is not yet available.

Pick a finding

Choose a SQL injection case.

Finding 01app/finding_b01.pyQuoted stringSingle parameter interpolated between quotes. The baseline case.11 attack cases · 11 benign inputsOpen →Finding 04app/finding_b04.pyNumeric contextNo quotes anywhere in the query, so a patch that escapes or strips quotes does nothing.11 attack cases · 11 benign inputsOpen →Finding 08app/finding_b08.pyORDER BY identifierA column name cannot be a bound parameter. The only correct defence is an allow-list.11 attack cases · 11 benign inputsOpen →Finding 13app/finding_b13.pySecond orderThe input is stored safely in one function and reaches the vulnerable query in another.11 attack cases · 11 benign inputsOpen →

Results by tool and version

The product

The benchmark uses seeded test modules. Verification for pull requests in your own repositories is in development.

The running count

Every fix shut the hole. Not every fix left the product working.

Runs we conducted · Pilot 001 blind run · recounted from the stored results at build time

10patches scored.

10 of 10shut the hole. Every held-out attack blocked, no fixer left it open.

7 of 10left the product working. The other 3 closed the hole and rejected a legitimate input.

Alert closed then verified, and the gap between · 9 of 10 to 7 of 10, 20 pp

Submitted · UNVERIFIED · separate from Assay pilot results

0patches scored.

noneshut the hole.

noneleft the product working.

Alert closed then verified, and the gap between · no cells

1 run(s) where the scanner raised no alert are counted in no rate. Every figure above is a recount of the stored records, not a stored number. Source: Pilot 001 blind run, stripped corpus, 2026-09-14, commit dbbbdf2.