Technologies

L'IA dégrade la sécurité du code et divulgue trop de secrets d'identification

L'IA dégrade la sécurité du code et divulgue trop de secrets d'identification
Le code généré avec l’IA se révèle moins sécurisé que celui produit par les seuls développeurs. Un phénomène risquant d’entraîner un cercle vicieux, les LLM étant entraînés avec ce code de moins bonne qualité. (Photo : Nubelson Fernandes/Unsplash)

Les dépôts de code, issus d'un développement assisté par l'IA, sont 40% plus susceptibles de contenir des clés d'API, des mots de passe ou des jetons. Et il ne s'agit là qu'un des nombreux problèmes auxquels sont confrontés les RSSI avec le code généré par l'IA.

PublicitéLes assistants de codage à base d'IA font partie des premières réussites de la GenAI en entreprises. De plus en plus adoptés, les copilotes de programmation font des incursions dans les processus de développement, améliorant la productivité des développeurs et aidant à mettre en place rapidement des projets rudimentaires.

Mais ils posent également un problème de sécurité, et le volume anticipé de code qu'ils produiront bientôt s'apparente à un cauchemar en devenir pour les responsables de la sécurité, selon les experts. À la discussion habituelle sur les hallucinations inhérentes à la GenAI s'ajoute la probabilité accrue d'exposer des secrets tels que les clés API, mots de passe et jetons dans le code généré par l'IA.

Selon une étude récente de GitGuardian, société spécialisée dans la détection automatisée des vulnérabilités dans les codes sources, les référentiels GitHub, issus d'un développement avec un copilote, sont plus susceptibles d'exposer des secrets que les dépôts standard. 6,4% des dépôts échantillonnés contiennent des clés API, des mots de passe ou des jetons risquant d'être volés, contre 4,6% en moyenne.

Selon les analystes de GitGuardian, cela se traduit par un taux d'incidents de type fuite de secrets supérieur de 40%. Les mêmes analystes avertissent que l'utilisation d'assistants de codage peut pousser les développeurs à donner la priorité à la productivité plutôt qu'à la qualité et à la sécurité du code, et ajoutent que le code généré par les grands modèles de langage (LLM) peut être intrinsèquement moins sûr que les logiciels écrits de manière conventionnelle.

Les failles sous-jacentes au développement avec l'IA

Les experts en sécurité s'accordent à dire que l'utilisation d'assistants de codage IA aboutit à du code moins sécurisé. David Benas, consultant principal associé chez l'éditeur de solutions de sécurité applicative Black Duck, explique que ces problèmes de sécurité sont une conséquence naturelle de l'entraînement des modèles d'IA sur du code généré par l'homme.

« Le plus tôt tout le monde se sentira à l'aise avec le fait de traiter ses LLM générateurs de code comme s'il s'agissait de stagiaires ou d'ingénieurs juniors poussant du code, le mieux ce sera, soupire David Benas. Les modèles sous-jacents aux LLM seront intrinsèquement aussi défectueux que la somme du corpus de code humain, avec une portion supplémentaire de défauts en raison de la tendance de ces outils à halluciner, à raconter des mensonges, à mal comprendre les requêtes, à traiter des requêtes défectueuses, etc. »

Si les assistants tels que GitHub Copilot augmentent la vitesse des développeurs, ils introduisent également de nouveaux risques de sécurité, abonde John Smith, directeur de la technologie pour la zone EMEA chez l'éditeur spécialiste de la sécurité applicative Veracode. « Ces outils manquent souvent de conscience contextuelle des pratiques de sécurité et, sans une supervision appropriée, peuvent générer du code non sécurisé et des vulnérabilités persistantes, dit-il. Cela devient un problème systémique lorsque le code généré par les LLM se propage et crée des failles tout au long de la supply chain logicielle. » Selon une récente étude de Veracode, plus de 70 % de la dette critique de sécurité provient désormais de codes tiers.

PublicitéDes contrôles de sécurité négligés

Mark Cherp, chercheur en sécurité au sein du spécialiste de la gestion des identités CyberArk, souligne que les assistants de codage de l'IA n'adhèrent la plupart du temps pas aux bonnes pratiques de gestion des secrets, généralement présentes dans les systèmes traditionnels. « Par exemple, ils peuvent insérer des informations sensibles en texte clair dans le code source ou les fichiers de configuration, explique l'expert. En outre, comme de grandes portions de code sont générées pour des produits en phase de démarrage, les meilleures pratiques telles que l'utilisation de gestionnaires de secrets ou la mise en oeuvre de l'injection de mots de passe et de tokens en temps réel sont souvent négligées. »

Et Mark Cherp d'ajouter : « Il y a déjà eu des cas où des clés d'API ou des clés publiques d'entreprises telles qu'Anthropic ou OpenAI ont été laissées par inadvertance dans le code source ou téléchargées dans des projets Open Source, ce qui les rend facilement exploitables. Même dans les projets à code source fermé, si les secrets sont codés en dur ou stockés en texte clair dans des fichiers binaires ou des fichiers JavaScript locaux, le risque reste important, car ces secrets demeurent faciles à extraire. »

Établir des pratiques sécurisées pour et avec l'IA

Chris Wood, spécialiste sécurité applicative de la société de formation en cybersécurité Immersive Labs, qualifie l'avertissement de GitGuardian sur les dangers des assistants de codage à base d'IA de signal d'alarme. « Bien que l'IA présente un potentiel incroyable pour stimuler la productivité, il est crucial de se rappeler que la sécurité qu'offrent ces outils n'est jamais supérieure à celle de leurs données de formation et à la vigilance des développeurs », dit-il.

Les RSSI et les responsables de la sécurité doivent commencer par formuler des stratégies globales de gestion des secrets. En outre, les entreprises devraient établir des politiques claires concernant l'utilisation d'assistants d'IA dans la programmation et fournir aux développeurs une formation spécifique sur le développement sécurisé avec l'IA. « Nous devons doter les développeurs des connaissances et des compétences nécessaires pour identifier et prévenir ces types de vulnérabilités, même lorsque l'IA accompagne la création du code, reprend Chris Wood. Cela inclut de solides bases concernant les principes de sécurisation des développements, la compréhension des schémas courants de fuite de secrets, ou encore la connaissance des bonnes pratiques de gestion et de stockage des informations d'identification sensibles. En donnant aux développeurs les connaissances nécessaires et en encourageant un état d'esprit axé sur la sécurité, nous pouvons exploiter les avantages de l'IA tout en atténuant les risques de vulnérabilités accrues [qu'elle introduit], telles que les fuites de secrets. »

Contre-mesures proactives

Plus le code issu de LLM sera généralisé, plus les développeurs lui feront confiance, ce qui aggravera encore le problème et créera un cercle vicieux, qu'il faut tenter de briser. « En l'absence de tests de sécurité appropriés, les codes générés par l'IA et non sécurisés deviendront les données d'entraînement des futurs LLM, souligne John Smith de Veracode. Fondamentalement, la façon dont les logiciels sont construits évolue rapidement. »

Le développement rapide de l'IA continuera à dépasser les contrôles de sécurité, à moins que les entreprises ne prennent des mesures proactives pour contenir le problème plutôt que de miser sur des correctifs a posteriori. « Les RSSI doivent agir rapidement pour intégrer des garde-fous, en automatisant les contrôles de sécurité et les examens manuels du code directement dans les processus des agents d'IA et des développeurs, conseille John Smith. L'audit des bibliothèques tierces permet de s'assurer que le code généré par l'IA n'introduit pas de vulnérabilités provenant de composants non vérifiés. »

L'intégration d'outils automatisés, tels que des scanners dans le pipeline CI/CD, suivie d'une révision humaine obligatoire du code par les développeurs, devrait être systématisée pour examiner les applications développées à l'aide d'assistants à base d'IA. « Tout le code généré par l'IA doit être surveillé et assaini en permanence, et un plan de réponse rapide aux incidents doit être mis en place pour traiter toute vulnérabilité qui serait découverte », tranche Mark Cherp de CyberArk.

Une gestion des secrets toujours approximative

Le problème de la gestion des clés d'API, des mots de passe et des jetons n'est pas nouveau dans la sécurité applicative. Mais les récentes innovations dans le développement de code alimenté par l'IA l'aggravent. L'étude State of Secrets Sprawl 2025 de GitGuardian pointe une augmentation de 25 % des fuites de secrets d'une année sur l'autre, avec 23,8 millions de nouveaux identifiants détectés sur des dépôts GitHub publics rien qu'en 2024. Les secrets codés en dur sont partout, mais surtout dans les angles morts de la sécurité comme les plateformes de collaboration (Slack et Jira) et les environnements de conteneurs où les contrôles de sécurité sont généralement plus faibles, selon GitGuardian.

Bien que la fonction Push Protection de GitHub aide les développeurs à détecter les schémas de divulgation connus, les secrets génériques - comme les mots de passe codés en dur, les identifiants de base de données et les jetons d'authentification personnalisés - représentent désormais plus de la moitié de toutes les fuites détectées. En effet, contrairement aux clés d'API ou aux jetons OAuth qui suivent des schémas reconnaissables, ces informations d'identification ne correspondent à aucun modèle standardisé, ce qui les rend presque impossibles à détecter avec les outils conventionnels, prévient GitGuardian.

GitGuardian met ainsi en avant la fuite de données du département du Trésor américain en 2024. Eric Fourrier, PDG de GitGuardian, y voit un avertissement : « une simple fuite de clé API de BeyondTrust a permis à des attaquants d'infiltrer les systèmes gouvernementaux. Il ne s'agissait pas d'une attaque sophistiquée, mais d'un simple cas d'identification exposée qui a permis de contourner des millions d'investissements en matière de sécurité. »

Les mesures correctives tardent à venir

L'étude montre également que 70 % des secrets divulgués restent actifs même deux ans après leur première exposition. Selon les experts en sécurité, les retards sont dus à la complexité des mesures correctives. « Les fuites de clés d'API, de mots de passe et de jetons sont souvent négligées parce que leur détection ne constitue qu'une partie de la solution ; une remédiation efficace est complexe et souvent différée », indique Mayur Upadhyaya, PDG du fournisseur d'outils de cybersécurité APIContext. « La dépendance à l'égard des clés statiques, souvent intégrées dans le code pour des raisons de commodité, continue d'être un point faible majeur ».

Et Mayur Upadhyaya d'ajouter : « Les meilleures pratiques telles que la rotation des clés, la mise en oeuvre de jetons à courte durée de vie et l'application de la règle du moindre privilège sont bien comprises mais difficiles à maintenir à l'échelle d'une organisation ». Selon lui, les entreprises devraient chercher à mettre en place des garde-fous plus solides, comme des outils d'analyse automatisés, une surveillance proactive du code et un meilleur accompagnement des développeurs.

Partager cet article

Commentaire

Avatar
Envoyer
Ecrire un commentaire...

INFORMATION

Vous devez être connecté à votre compte CIO pour poster un commentaire.

Cliquez ici pour vous connecter
Pas encore inscrit ? s'inscrire

    Publicité

    Abonnez-vous à la newsletter CIO

    Recevez notre newsletter tous les lundis et jeudis