Attrapez l'injection SQL avant qu'elle n'atteigne main.
Le SQL concaténé est la brèche la plus ancienne du métier — et l'IA l'écrit plus vite que quiconque ne peut la relire. SlopGrade lit chaque PR sur votre propre runner et bloque la requête qui construit du SQL à partir de l'entrée utilisateur, avant le merge.
L'entrée utilisateur, concaténée dans une requête.
L'id de la requête est collé dans la chaîne SQL. Un id forgé comme 1 OR 1=1 vide la table ; une sous-requête exfiltre une autre table. Les requêtes paramétrées corrigent ça — le gate garantit que la version non paramétrée ne merge jamais.
Ce que l'IA a livré
Ce qui quitte votre runner
Chemin, ligne, classe. Le contenu du fichier ne sort jamais. Auditez-le avec --print-payload.
Détecte → adapte → vérifie. Rien d'autre ne sort.
Dans votre runner, sur le diff
Le client open source parcourt la pull request et signale le motif en local — dataflow intra-fonction, aucun code ne quitte la machine.
Verdict serveur + gate
L'empreinte structurelle est classée côté serveur. Un hit dur bloque le check sur un repo privé payant ; les repos publics sont gatés gratuitement ; le paywall échoue en mode ouvert.
Posté inline, correctif vérifié en local
Le constat est posté sur sa ligne exacte. Quand un correctif existe, il est généré ET vérifié dans votre runner — proposé seulement une fois qu'un re-scan prouve la disparition.
Qu'est-ce qui compte comme injection SQL ici ?
Toute requête construite en concaténant ou interpolant une entrée non fiable dans la chaîne SQL, en JS/TS, Python, Go ou .NET — à travers les drivers courants et les échappatoires raw-query des ORM. Les requêtes paramétrées/préparées passent.
Va-t-il signaler les requêtes paramétrées sûres ?
Non — calibré à 0 faux positif sur 5 000+ repos réels. Les placeholders ($1, ?, :name) et les query builders qui paramètrent sont reconnus comme sûrs. Démarrez en advisory pour vérifier, puis passez en bloquant.