Les agents de codage basés sur l'IA constituent désormais un risque pour la chaîne d'approvisionnement logicielle

Les développeurs de logiciels importent depuis longtemps du code qu’ils n’ont pas écrit eux-mêmes. Les bibliothèques open source, les référentiels de paquets et les frameworks tiers permettent aux équipes de créer des applications sans avoir à recréer chaque composant à partir de zéro, tandis que les programmes de sécurité ont progressivement mis au point des procédures pour analyser les dépendances et réagir lorsqu’un paquet largement utilisé contient une vulnérabilité. Les agents de codage basés sur l’IA ajoutent une dimension supplémentaire, car les logiciels sont désormais capables de découvrir, de sélectionner et d’intégrer des composants externes dans le cadre d’un processus de développement largement automatisé.

L'avantage en termes de productivité est facile à comprendre. Un agent chargé de créer une fonctionnalité peut examiner la base de code, écrire de nouvelles fonctions, exécuter des tests et installer toutes les dépendances qu'il juge nécessaires. Un développeur qui passait auparavant un après-midi à évaluer des bibliothèques peut ainsi obtenir un code fonctionnel en quelques minutes.

Cette rapidité modifie les limites de sécurité, car l’objectif de l’agent est généralement de garantir le bon fonctionnement du logiciel. À moins que les organisations ne définissent explicitement des contraintes de sécurité, le système peut choisir un paquet simplement parce que sa documentation correspond à la tâche à accomplir, sans vérifier si le responsable de la maintenance est toujours actif, si le paquet présente un historique suspect ou si une dépendance portant un nom similaire appartient à un attaquant.

La confusion autour des noms de paquets offre déjà aux attaquants un moyen d'exploiter les processus automatisés. Un système à la recherche d'une dépendance peut tomber sur un paquet malveillant dont le nom ressemble fortement à celui d'une bibliothèque légitime, interne ou publique, tandis qu'un agent d'IA interprétant les instructions issues de la documentation peut faire le mauvais choix avec une certitude considérable.

Le code généré peut lui-même reproduire des schémas non sécurisés. Les modèles apprennent à partir d’un vaste corpus de logiciels existants, qui comprend aussi bien des approches obsolètes que des pratiques modernes. Une fonction peut s’exécuter correctement tout en utilisant une authentification faible, un traitement des entrées non sécurisé ou une dépendance vulnérable, laissant ainsi l’équipe de développement avec un logiciel qui passe les tests de fonctionnalité courants mais échoue à un contrôle de sécurité.

Les développeurs humains peuvent commettre exactement les mêmes erreurs, même si l’automatisation en modifie la fréquence et l’ampleur. Lorsqu’un ingénieur écrit vingt lignes de code, un collègue peut raisonnablement les vérifier avant le déploiement. Lorsque des agents génèrent des milliers de lignes réparties sur plusieurs dépôts, la révision manuelle devient un goulot d’étranglement et les équipes commencent à s’appuyer davantage sur des contrôles automatisés.

Le pipeline de développement doit donc devenir le point de contrôle. L'analyse des dépendances, la détection des secrets, l'analyse statique et la vérification des licences peuvent s'exécuter automatiquement chaque fois qu'un développeur modifie le code, ce qui empêche la rapidité de la phase de codage de contourner les mesures de sécurité qui s'appliqueraient normalement avant la mise en production.

Les autorisations méritent une attention particulière, car les agents de codage ont de plus en plus besoin d'accéder à des référentiels, à des environnements de développement et à des outils de déploiement. Accorder à un agent des droits d'accès étendus sous prétexte qu'il doit accomplir des tâches rapidement peut permettre à un flux de travail compromis d'avoir une portée bien plus large que celle d'un assistant de codage classique qui se contente de suggérer du texte dans un éditeur.

Les organisations peuvent réduire ce risque en recourant à des identifiants à durée de validité limitée et à des autorisations spécifiques à chaque tâche. Un agent chargé de modifier un composant front-end a rarement besoin d'un accès permanent aux bases de données de production, tandis qu'un système effectuant des tests ne devrait pas obtenir automatiquement l'autorisation de déployer une application en production.

Les instructions externes créent une nouvelle surface d'attaque. Les agents de programmation s'appuient sur les descriptions de problèmes, la documentation, les pages Web et les fichiers du référentiel pour contextualiser leur action ; cela signifie qu'un texte malveillant peut tenter d'influencer leur comportement, tout comme l'injection de prompts peut manipuler d'autres agents IA. Un fichier de documentation compromis peut donc s'intégrer à la chaîne logistique du logiciel, même s'il ne contient pas en soi de logiciel malveillant exécutable.

La traçabilité prend de plus en plus d'importance, car les équipes ont besoin de savoir quel agent a modifié le code, quel modèle il a utilisé, quelles dépendances il a ajoutées et quels tests ont été exécutés avant la fusion. Les systèmes classiques de contrôle de version enregistrent les modifications apportées au code, tandis que le développement de l'IA nécessite des informations contextuelles supplémentaires sur la manière dont ces modifications ont été générées.

Le processus de révision doit également établir une distinction entre les tâches à faible risque et celles à haut risque. Un agent chargé de corriger la mise en forme ne nécessite pas le même niveau de supervision qu’un autre chargé de modifier la logique d’authentification ou de paiement, ce qui permet aux entreprises de conserver une grande partie des gains de productivité tout en réservant une révision humaine plus approfondie aux modifications susceptibles d’engendrer des risques importants.

Le code privé soulève une autre préoccupation, car les agents peuvent transmettre le contenu du référentiel à des modèles externes en fonction de leur architecture. Les entreprises ont besoin de savoir clairement quel code quitte leur environnement, comment les fournisseurs le conservent et si des informations confidentielles peuvent apparaître dans les systèmes de journalisation ou d'apprentissage.

Les équipes de développement logiciel s'orientent donc vers des politiques qui régissent les agents en tant qu'acteurs de l'environnement de développement, plutôt que de les considérer comme de simples outils avancés d'aide à la saisie. L'agent dispose d'une identité, de droits d'accès, d'actions et de résultats qui doivent s'inscrire dans le cadre des contrôles de sécurité existants de l'organisation.

Le codage par IA peut néanmoins réduire considérablement les délais de développement, car une grande partie du travail logiciel implique des tâches répétitives mise en œuvre qui permet aux machines bien gérer. Les équipes de sécurité n'ont pas besoin d'empêcher cette automatisation ; elles doivent s'assurer que la vitesse de génération du code ne dépasse pas la capacité de l'organisation à comprendre ce qui est intégré au produit.

La chaîne d'approvisionnement logicielle s'est élargie dès lors que les développeurs ont cessé d'écrire eux-mêmes chaque composant. Les agents de codage l'élargissent encore davantage, car la sélection et l'assemblage de ces composants peuvent désormais s'effectuer automatiquement, ce qui fait que les contrôles relatifs à la provenance, aux dépendances et aux autorisations font désormais partie du prix à payer pour des logiciels plus rapides.