Sommes-nous prêts pour le code généré par l'IA ?

Ces derniers mois, nous nous sommes émerveillés de la qualité des visages générés par ordinateur, des images de chats, des vidéos, des essais et même de l'art. L'intelligence artificielle (IA) et l'apprentissage automatique (ML) se sont également discrètement glissés dans le développement de logiciels, avec des outils comme GitHub Copilot, Tabnine, Polycode, et d'autres prendre la prochaine étape logique consistant à mettre la fonctionnalité de saisie semi-automatique du code existant sur les stéroïdes AI. Contrairement aux images de chat, cependant, l'origine, la qualité et la sécurité du code d'application peuvent avoir des implications de grande envergure - et au moins pour la sécurité, la recherche montre que le risque est réel.

Avant recherche universitaire a déjà montré que GitHub Copilot génère souvent du code avec des failles de sécurité. Plus récemment, une analyse pratique de l'ingénieur en sécurité d'Invicti, Kadir Arslan, a montré que suggestions de code non sécurisé sont toujours la règle plutôt que l'exception avec Copilot. Arslan a découvert que les suggestions pour de nombreuses tâches courantes n'incluaient que les éléments nus absolus, empruntant souvent la voie la plus élémentaire et la moins sécurisée, et que les accepter sans modification pouvait entraîner des applications fonctionnelles mais vulnérables.

Un outil comme Copilot est (par conception) l'auto-complétion a augmenté d'un cran, formé sur du code open source pour suggérer des extraits qui pourraient être pertinents dans un contexte similaire. Cela rend la qualité et la sécurité des suggestions étroitement liées à la qualité et à la sécurité de l'ensemble de formation. Ainsi, les grandes questions ne concernent pas Copilot ou tout autre outil spécifique, mais le code logiciel généré par l'IA en général.

Il est raisonnable de supposer que Copilot n'est que la pointe de la lance et que des générateurs similaires deviendront monnaie courante dans les années à venir. Cela signifie que nous, l'industrie technologique, devons commencer à nous demander comment un tel code est généré, comment il est utilisé et qui assumera la responsabilité en cas de problème.

Syndrome de navigation par satellite

L'auto-complétion de code traditionnelle qui recherche les définitions de fonction pour compléter les noms de fonction et vous rappelle les arguments dont vous avez besoin est un gain de temps considérable. Étant donné que ces suggestions ne sont qu'un raccourci pour rechercher la documentation par vous-même, nous avons appris à faire implicitement confiance à tout ce que l'IDE suggère. Une fois qu'un outil alimenté par l'IA arrive, ses suggestions ne sont plus garanties d'être correctes - mais elles se sentent toujours amicales et dignes de confiance, elles sont donc plus susceptibles d'être acceptées.

Surtout pour les développeurs moins expérimentés, la commodité d'obtenir un bloc de code gratuit encourage un changement d'état d'esprit de "Ce code est-il assez proche de ce que j'écrirais" à "Comment puis-je modifier ce code pour qu'il fonctionne pour moi".

GitHub indique très clairement que les suggestions de Copilot doivent toujours être soigneusement analysées, examinées et testées, mais la nature humaine dicte que même un code de qualité inférieure sera parfois mis en production. C'est un peu comme conduire en regardant plus votre GPS que la route.

Problèmes de sécurité de la chaîne d'approvisionnement

La Crise de sécurité Log4j a placé la sécurité de la chaîne d'approvisionnement logicielle et, en particulier, la sécurité open source sous les feux de la rampe, avec un récent Note de la Maison Blanche sur le développement de logiciels sécurisés et un nouveau projet de loi sur l'amélioration de la sécurité open source. Avec ces initiatives et d'autres, avoir du code open source dans vos applications pourrait bientôt devoir être écrit dans une nomenclature logicielle (SBOM), ce qui n'est possible que si vous incluez sciemment une dépendance spécifique. Les outils d'analyse de la composition logicielle (SCA) s'appuient également sur ces connaissances pour détecter et signaler les composants open source obsolètes ou vulnérables.

Mais que se passe-t-il si votre application inclut du code généré par l'IA qui, en fin de compte, provient d'un ensemble de formation open source ? Théoriquement, si même une suggestion substantielle est identique au code existant et acceptée telle quelle, vous pourriez avoir du code open source dans votre logiciel mais pas dans votre SBOM. Cela pourrait entraîner des problèmes de conformité, sans parler du risque de responsabilité si le code s'avère non sécurisé et entraîne une violation - et SCA ne vous aidera pas, car il ne peut trouver que des dépendances vulnérables, pas des vulnérabilités dans votre propre code. .

Les pièges des licences et de l'attribution

Poursuivant dans cette voie, pour utiliser le code open source, vous devez vous conformer à ses conditions de licence. Selon la licence open source spécifique, vous devrez au moins fournir une attribution ou parfois publier votre propre code en open source. Certaines licences interdisent complètement l'utilisation commerciale. Quelle que soit la licence, vous devez savoir d'où vient le code et comment il est licencié.

Encore une fois, que se passe-t-il si vous avez du code généré par l'IA dans votre application qui se trouve être identique au code open source existant ? Si vous aviez un audit, découvririez-vous que vous utilisez du code sans l'attribution requise ? Ou peut-être avez-vous besoin d'ouvrir une partie de votre code commercial pour rester conforme ? Ce n'est peut-être pas encore un risque réaliste avec les outils actuels, mais c'est le genre de questions que nous devrions tous nous poser aujourd'hui, pas dans 10 ans. (Et pour être clair, GitHub Copilot dispose d'un filtre facultatif pour bloquer les suggestions qui correspondent au code existant afin de minimiser les risques de la chaîne d'approvisionnement.)

Implications de sécurité plus profondes

Pour en revenir à la sécurité, un modèle AI/ML n'est aussi bon (et aussi mauvais) que son ensemble de formation. Nous avons vu cela dans le passé - par exemple, en cas de algorithmes de reconnaissance faciale montrant des préjugés raciaux à cause des données sur lesquelles ils ont été formés. Donc, si nous avons des recherches montrant qu'un générateur de code produit fréquemment des suggestions sans considération pour la sécurité, nous pouvons en déduire que c'est à quoi ressemblait son ensemble d'apprentissage (c'est-à-dire le code accessible au public). Et que se passe-t-il si le code généré par l'IA non sécurisé est ensuite réinjecté dans cette base de code ? Les suggestions peuvent-elles être sécurisées ?

Les questions de sécurité ne s'arrêtent pas là. Si les générateurs de code basés sur l'IA gagnent en popularité et commencent à représenter une proportion significative de nouveau code, il est probable que quelqu'un essaiera de les attaquer. Il est déjà possible de tromper la reconnaissance d'image de l'IA en empoisonnant son ensemble d'apprentissage. Tôt ou tard, des acteurs malveillants essaieront de placer du code vulnérable unique dans des référentiels publics dans l'espoir qu'il apparaisse dans des suggestions et finisse par se retrouver dans une application de production, l'ouvrant à une attaque facile.

Et qu'en est-il de la monoculture ? Si plusieurs applications finissent par utiliser la même suggestion hautement vulnérable, quelle que soit son origine, nous pourrions être confrontés à des épidémies de vulnérabilité ou peut-être même à des vulnérabilités spécifiques à l'IA.

Garder un œil sur l'IA

Certains de ces scénarios peuvent sembler farfelus aujourd'hui, mais ce sont tous des sujets dont nous, dans l'industrie technologique, devons discuter. Encore une fois, GitHub Copilot est à l'honneur uniquement parce qu'il ouvre actuellement la voie, et GitHub fournit des avertissements clairs sur les mises en garde des suggestions générées par l'IA. Comme pour la saisie semi-automatique sur votre téléphone ou les suggestions d'itinéraires dans votre satnav, ce ne sont que des indices pour nous faciliter la vie, et c'est à nous de les prendre ou de les laisser.

Avec leur potentiel d'amélioration exponentielle de l'efficacité du développement, les générateurs de code basés sur l'IA sont susceptibles de devenir une partie permanente du monde du logiciel. En termes de sécurité des applications, cependant, il s'agit d'une autre source de code potentiellement vulnérable qui doit passer des tests de sécurité rigoureux avant d'être autorisé à entrer en production. Nous recherchons une toute nouvelle façon de glisser les vulnérabilités (et les dépendances potentiellement non contrôlées) directement dans votre code propriétaire, il est donc logique de traiter les bases de code augmentées par l'IA comme non fiables jusqu'à ce qu'elles soient testées - et cela signifie tout tester aussi souvent que vous peut.

Même des solutions de ML relativement transparentes comme Copilot soulèvent déjà des questions juridiques et éthiques, sans parler des problèmes de sécurité. Mais imaginez qu'un jour, un nouvel outil commence à générer du code qui fonctionne parfaitement et passe les tests de sécurité, à l'exception d'un petit détail : personne ne sait comment cela fonctionne. C'est alors qu'il est temps de paniquer.