IA et code
Sécurité du code généré par l’IA : les risques et comment le relire
Assurer la sécurité du code généré par l’IA, c’est traiter le code produit par les assistants et les agents de codage comme celui d’un contributeur que vous n’avez jamais rencontré : vérifiez chaque dépendance qu’il ajoute, analysez-le à la recherche de secrets et de failles d’injection, et faites-le relire par une personne avant sa fusion. Les risques propres à l’IA sont les paquets obsolètes, malveillants ou tout simplement inexistants.
Offre Free, sans carte bancaire.
Quels sont les risques de sécurité du code généré par l’IA ?
Les assistants et agents de codage écrivent du code en prédisant ce qui vient généralement ensuite, à partir de code existant. C’est ce qui les rend rapides, et c’est aussi pourquoi ils reproduisent ce qui était courant dans ce code, y compris d’anciennes versions de bibliothèques, des API dépréciées et de mauvaises habitudes de sécurité. Un modèle ne sait pas quelle version d’un paquet a été corrigée le mois dernier, sauf s’il le vérifie, et un agent capable d’exécuter des commandes peut installer ce qu’il suggère avant que quiconque ait lu la modification.
Aucun de ces risques n’est nouveau en soi. Ce qui change, c’est le volume et la vitesse : plus de code, plus de nouvelles dépendances et moins de personnes pour lire chaque ligne. La réponse consiste à appliquer automatiquement les contrôles que vous appliqueriez à toute contribution extérieure, pour qu’ils ne passent pas à la trappe quand le diff est volumineux.
- Des versions de dépendances obsolètes ou connues pour être vulnérables, suggérées à partir des données d’entraînement.
- Des noms de paquets qui n’existent pas, ou qu’un attaquant a enregistrés parce que les modèles ont tendance à les inventer.
- Des paquets malveillants fraîchement publiés, y compris sous des noms qui imitent des bibliothèques populaires.
- Des secrets collés dans le code ou la configuration : clés d’API, jetons, chaînes de connexion.
- Des pratiques non sécurisées, comme des requêtes SQL ou des commandes shell construites par concaténation de chaînes, des vérifications de certificats désactivées ou une cryptographie faible.
- Des agents dotés de droits étendus qui installent des paquets, exécutent des scripts ou poussent des modifications sans relecture.
Qu’est-ce que le slopsquatting ?
Le « slopsquatting » consiste à enregistrer un paquet sous un nom que les modèles d’IA ont tendance à inventer, de sorte que quiconque installe ce nom inventé récupère le code de l’attaquant. Le mot associe « slop », terme d’argot anglais qui désigne les contenus de mauvaise qualité produits par des machines, et le typosquatting, où des attaquants enregistrent des variantes mal orthographiées de paquets populaires. La technique fonctionne parce que les registres publics comme npm et PyPI permettent à chacun de publier sous un nom que personne n’a encore réservé.
Une étude évaluée par les pairs, présentée à USENIX Security 2025, a testé 16 modèles de génération de code et produit 576 000 échantillons de code. Les auteurs indiquent que la part moyenne de paquets hallucinés atteignait au moins 5,2 % pour les modèles commerciaux et 21,7 % pour les modèles open source, et ils ont recensé 205 474 noms de paquets inventés uniques. Lorsque le même prompt était répété dix fois, un nom inventé revenait plus d’une fois dans 58 % des cas, et c’est ce qui rend ces noms suffisamment prévisibles pour être enregistrés.
Le projet OpenSSF Malicious Packages publie, au format OSV, des signalements de paquets malveillants découverts dans les registres open source, avec des identifiants qui commencent par MAL-. Confronter vos dépendances à ces signalements permet de repérer les paquets déjà signalés. Cela ne permet pas de repérer un paquet enregistré hier que personne n’a encore analysé : ce contrôle complète donc la vérification de l’existence du paquet, de son éditeur et de son ancienneté. Cette vérification, au moment où un agent propose un paquet, figure dans la feuille de route de KROMSE.
Comment relire le code écrit par l’IA avant sa fusion
L’objectif est une routine qui s’exécute de la même façon, que la modification ait été écrite par une personne ou par un agent. L’essentiel peut tourner dans le pipeline qui exécute déjà vos tests ; la part humaine consiste à lire le diff avec le scepticisme que vous réserveriez à la pull request d’un inconnu. L’OpenSSF publie un guide d’instructions axées sur la sécurité pour les assistants de code, un bon point de départ pour les prompts eux-mêmes.
- Versionnez les fichiers de verrouillage (lockfiles) et installez à partir de ceux-ci en CI, pour que les versions relues soient celles qui sont livrées.
- Fixez des versions exactes pour les nouvelles dépendances et relisez chaque modification du lockfile, pas seulement celle du manifeste.
- Vérifiez que chaque nouveau paquet existe, qu’il s’agit bien de celui que vous vouliez, et que son éditeur et son historique sont vérifiables.
- Tenez une liste de paquets approuvés, ou installez via un proxy de registre interne qui bloque le reste.
- Lancez l’analyse du code source, la détection de secrets et le contrôle des dépendances à chaque modification, et bloquez la fusion en cas de nouveau constat critique.
- Exigez un relecteur nommément désigné pour les modifications écrites par l’IA, et ne laissez pas les agents fusionner ou déployer seuls.
Le code écrit par l’IA change-t-il vos obligations au titre du Cyber Resilience Act ?
Le règlement sur la cyberrésilience (Cyber Resilience Act, CRA) fait peser ses obligations sur le fabricant d’un produit comportant des éléments numériques. Son considérant 34 précise que les obligations en matière de gestion des vulnérabilités s’appliquent au produit dans son entièreté, y compris à tous les composants intégrés. L’article 13, paragraphe 5, exige une diligence raisonnable lors de l’intégration de composants obtenus auprès de tiers, y compris open source, et l’annexe I, partie II, demande aux fabricants de recenser et de documenter les composants, notamment au moyen d’une nomenclature des logiciels (SBOM), et de soumettre régulièrement le produit à des tests et examens de sécurité efficaces.
En pratique, une dépendance ajoutée par un agent est un composant tiers comme un autre, et c’est à vous de traiter la vulnérabilité qu’elle introduit pendant toute la période d’assistance. Les obligations de notification de l’article 14 s’appliquent depuis le 11 septembre 2026 ; la plupart des autres obligations s’appliquent à partir du 11 décembre 2027.
Ce que les contrôles automatisés détectent, et ce qui leur échappe
Les bases de données de vulnérabilités connaissent les vulnérabilités qui ont été signalées, et une base de paquets malveillants connaît les paquets que quelqu’un a analysés. L’analyse du code source repère des schémas à risque connus, comme une requête construite à partir d’une saisie utilisateur, mais pas une règle métier défaillante ni un contrôle d’autorisation manquant qui ressemble à du code ordinaire. Analyser le code actuel à la recherche de secrets ne permet pas de voir une clé commitée puis supprimée, car elle reste dans l’historique git.
C’est pourquoi une routine de revue combine plusieurs contrôles et la lecture de la modification par une personne. Quand un outil ne signale rien, notez ce qu’il ne pouvait pas voir, pour que « aucun constat » ne se lise pas comme « aucun risque ». Pour le code écrit par l’IA, les principaux angles morts sont les paquets trop récents pour figurer dans une base de données et les noms qui n’existaient pas avant qu’un modèle les suggère.
Disponible aujourd’hui dans KROMSE
KROMSE contrôle le code et les dépendances que produisent votre équipe et ses assistants IA ; il signale des constats et ne modifie pas le code.
- Confronte les lockfiles et les manifestes à OSV.dev avec OSV-Scanner, pour les projets npm, Yarn v1, pnpm, Poetry, uv, pip, modules Go, Cargo, Maven, Gradle, Composer, Bundler et .NET.
- Signale comme critiques les dépendances répertoriées dans la base OpenSSF Malicious Packages, avec leur suppression pour seul remède.
- Détecte avec Gitleaks les identifiants commités dans le code au commit analysé ; les valeurs des secrets sont masquées et jamais stockées. L’historique git n’est pas analysé.
- Analyse du code source pour 11 langages : C, C++, C#, Go, Java, JavaScript, TypeScript, Kotlin, Python, Scala et Swift.
- Une explication en langage clair de chaque constat, et un verdict IA par constat dans la limite du quota de votre offre.
Prochainement
Sur la feuille de route, pas encore disponible. Les dates sont des objectifs, pas des promesses ; cette page change le jour où une fonctionnalité est mise en service.
- À venir · T4 2026 (novembre)Plug-in pour agents de codage. Un plug-in pour les agents de codage IA vérifiera chaque paquet proposé par l’agent avant son intégration, y compris les paquets qui n’existent pas ou qui n’ont été publiés que quelques jours plus tôt.
- À venir · T4 2026 (novembre)Correctifs proposés par l’IA, approuvés par une personne. KROMSE proposera des correctifs pour les constats, rédigés avec l’IA et appliqués uniquement après l’approbation d’une personne de votre équipe.
- À venir · T1 2027Sécurité des agents et des modèles d’IA. KROMSE produira une nomenclature des composants d’IA (AI-BOM), examinera les outils et les permissions que vos agents peuvent utiliser, et détectera les fichiers de modèles non sûrs.
Questions fréquentes
Le code généré par l’IA est-il moins sûr que le code écrit par des humains ?
Cela dépend du modèle, du prompt et de la revue. Le code généré par l’IA a tendance à reproduire ce qui était courant dans le code existant, y compris des versions obsolètes et des pratiques non sécurisées, et il arrive en plus grande quantité. Relisez-le comme le code d’un contributeur que vous ne connaissez pas : mêmes tests, mêmes analyses et approbation humaine avant la fusion.
Qu’est-ce que le slopsquatting ?
Le slopsquatting consiste à enregistrer un paquet sous un nom que les modèles d’IA ont tendance à inventer, de sorte que quiconque installe ce nom inventé récupère le code de l’attaquant. C’est une variante du typosquatting. Pour s’en protéger : vérifier que chaque nouvelle dépendance existe et qu’il s’agit bien de celle prévue, fixer les versions dans un lockfile versionné, et confronter les paquets aux bases de paquets malveillants.
Comment empêcher un agent IA d’installer des paquets malveillants ?
Limitez ce que l’agent peut faire : aucune installation hors d’un bac à sable, des installations uniquement depuis une liste approuvée ou un proxy de registre interne, et aucune fusion sans relecture humaine. Confrontez en CI les nouvelles dépendances aux données de vulnérabilités et de paquets malveillants, et fixez les versions dans un lockfile versionné.
KROMSE peut-il me dire si un paquet suggéré par une IA n’existe pas ?
Pas aujourd’hui. KROMSE confronte les dépendances de vos lockfiles et de vos manifestes à OSV.dev, y compris aux signalements OpenSSF Malicious Packages : un paquet malveillant déjà signalé est donc marqué comme critique. La détection des noms de paquets inventés et des paquets publiés il y a quelques jours seulement figure dans la feuille de route, sous la forme d’un plug-in pour les agents de codage.
KROMSE corrige-t-il le code généré par l’IA ?
Non. KROMSE signale des constats, les explique en langage clair et peut fournir un verdict IA par constat dans la limite du quota de votre offre. Il ne modifie pas le code et n’ouvre pas de pull requests, et son application GitHub dispose d’un accès en lecture seule. Des correctifs proposés par l’IA et approuvés par une personne figurent dans la feuille de route.
Les secrets présents dans le code généré par l’IA apparaissent-ils dans une analyse KROMSE ?
KROMSE exécute Gitleaks sur le code au commit qu’il analyse et signale les identifiants commités, avec des valeurs de secrets masquées et jamais stockées. Il n’analyse pas l’historique git : une clé commitée puis supprimée n’est donc pas détectée. Effectuez la rotation de toute clé qui a été exposée, qu’elle soit encore dans le code ou non.
Guides associés
Sources
- Spracklen et al., « We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs », USENIX Security 2025
- Groupe de travail Best Practices de l’OpenSSF : Security-Focused Guide for AI Code Assistant Instructions
- Dépôt OpenSSF Malicious Packages
- OpenSSF : détecter les paquets malveillants avec l’API OSV
- Règlement (UE) 2024/2847 (règlement sur la cyberrésilience)