Les développeurs utilisent un assistant de code IA qui suggère un paquet absent de votre liste approuvée. Quel est le risque et que faites-vous ?

Ce scénario vérifie si vous traitez la sortie d'une IA comme une entrée non fiable et la reliez aux contrôles de chaîne d'approvisionnement, plutôt que d'interdire simplement l'outil.

Le risque

L'OWASP classe la désinformation (LLM09:2025) parmi les principaux risques des LLM et inclut la génération de code dangereuse : les modèles peuvent suggérer des « bibliothèques de code non sécurisées ou inexistantes ». La page décrit des attaquants publiant des paquets malveillants sous des noms souvent hallucinés, que les développeurs peuvent installer sans le savoir. La surconfiance, « les utilisateurs accordent une confiance excessive au contenu généré sans en vérifier l'exactitude », aggrave le problème.

Ce que vous faites

D'abord, n'installez pas le nom inconnu : vérifiez que le paquet existe, qui le maintient, sa date de création et s'il correspond au besoin du code. Ensuite, structurez : faites passer les installations par un proxy de registre interne en liste blanche, épinglez les versions avec des lockfiles, lancez l'analyse de composition logicielle et exigez la revue des changements de dépendances en pull request.

Alignement avec les mesures OWASP

L'OWASP recommande la vérification croisée et la supervision humaine, la validation automatique des sorties clés, des pratiques de codage sécurisé et la formation des utilisateurs aux limites des LLM.

Pourquoi les distracteurs sont tentants

« Le modèle l'a validé » est exactement la défaillance de surconfiance. « Tester en production » et « tout interdire » sont les extrêmes.

Ce que veulent les recruteurs

Nommer l'hallucination de paquets, traiter la sortie comme non fiable et proposer des contrôles en couches et proportionnés.