Bloquez le fetch qui atteint votre endpoint de métadonnées.
Une requête côté serveur vers une URL fournie par l'utilisateur peut pivoter vers 169.254.169.254 et voler des identifiants cloud. L'IA l'écrit dès qu'une fonctionnalité « récupère une URL donnée par l'utilisateur ». SlopGrade la bloque en CI avant le merge.
Une URL contrôlée par l'utilisateur, fetchée côté serveur.
Rien ne valide l'hôte, donc un attaquant le pointe vers le service de métadonnées cloud ou un panneau d'admin interne. Une allowlist de la destination corrige ça — le gate bloque le fetch non-allowlisté.
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.
Et si l'URL est partiellement validée ?
Une allowlist de destination (schéma + hôte) est reconnue comme sûre. Un simple contrôle de protocole (startsWith https) ne l'est pas — il autorise encore les hôtes internes. Le gate est calibré sur cette distinction.
Quels langages ?
JavaScript/TypeScript et Python pour la classe complète ; Go et .NET couvrent les motifs fetch/client-HTTP cœur.