L’IA crée plus de goulots d’étranglement qu’elle n’en résout

Les ingénieurs en sécurité qui examinaient auparavant 100 lignes de code par heure doivent désormais gérer des volumes considérablement plus importants en raison de l'accélération de la production de code généré par l'IA. Parallèlement, les attaquants utilisent déjà des agents autonomes pour détecter rapidement les failles de sécurité dans les systèmes existants. Les risques se multiplient et les backlogs de sécurité s'allongent sans fin, mais nos capacités de défense restent limitées.

Ce défi n'est pas entièrement nouveau. Auparavant, les processus de sécurité reposant sur des interventions humaines pouvaient être facilement négligés lorsque les volumes de code étaient gérables. Désormais, la complexité de l'IA rend le travail des équipes de sécurité sensiblement plus difficile. Si nous ne traitons pas rapidement ces défis, il deviendra plus difficile de sécuriser le développement à l'échelle de l'IA.

Voici les deux points de défaillance à l'origine de ces goulots d'étranglement, et comment les éviter.

Déployer des outils d'IA sans renforcer les contrôles de sécurité

L'approche « shift left » vise à résoudre les goulots d'étranglement en matière de sécurité en transférant la responsabilité de la sécurité aux équipes de développement plus tôt dans le cycle de développement logiciel. Ajouter des tests de sécurité aux workflows de développement est une bonne idée en théorie, mais obliger les équipes à devoir gérer des contrôles de sécurité qui signalent souvent des faux positifs n'est pas optimal, car cela prolonge involontairement leur journée de travail de plusieurs heures. Les développeurs mettent alors au point des solutions de contournement parce qu'ils doivent livrer des fonctionnalités dans les délais impartis.

Dans l'approche « shift left », nous n'avons pas su prendre en compte l'ensemble du cycle de développement logiciel, ce qui a entraîné des effets indésirables. Aujourd'hui, de nombreuses organisations répètent les mêmes erreurs avec les assistants d’IA pour le code.

Ces assistants optimisent la génération de code, mais le processus de revue reste inchangé. La solution ne consiste pas à ajouter plus de personnes ou plus d'outils de manière isolée. Elle nécessite une vision holistique de l'ensemble de la chaîne de valeur.

Les organisations qui évitent ce piège cartographient leurs chaînes de valeur avant d'ajouter davantage d'outils d'IA. Elles documentent également les processus reposant sur des connaissances tacites et institutionnelles, qui compliquent la façon dont les équipes définissent et mesurent la valeur apportée par l'IA. Si l'IA rend un processus non documenté plus efficace, il est impossible de mesurer ou de prouver cette valeur.

Il s'agit d'un défi auquel les grandes organisations d'ingénierie ont déjà été confrontées, avant même l'essor du code généré par l'IA. Ericsson a utilisé une plateforme GitOps pour réduire le temps de déploiement et réaliser des économies significatives sur des projets à plusieurs millions de dollars. Grâce à cette transition, Ericsson peut désormais effectuer des mises à jour deux fois plus souvent tout en optimisant les coûts.

Les dirigeants doivent également mettre en œuvre des méthodologies de revue évolutives qui combinent l'IA avec une supervision humaine pratique, en établissant des frameworks de priorisation basés sur des risques mesurables. Par exemple, le code qui touche aux données clients sensibles ou des bases de données de production nécessite une revue beaucoup plus approfondie qu'une fonctionnalité qui permet de personnaliser le thème d'une application.

Appliquer des frameworks de sécurité traditionnels aux agents d'IA

Les frameworks de sécurité traditionnelle reposent sur l'hypothèse d'un comportement humain prévisible. Les agents d'IA ne suivent pas ces règles, ce qui entraîne une toute nouvelle catégorie de risques.

Cette complexité se multiplie lorsque des agents interagissent avec d'autres agents au-delà de l'organisation. Lorsque votre agent interne reçoit des instructions d'un agent tiers qui a lui-même reçu des instructions d'un autre système externe, votre modèle de sécurité doit tenir compte de requêtes potentiellement malveillantes que vous ne pouvez contrôler directement.

Ces problèmes peuvent être évités grâce à des contrôles de sécurité qui limitent les autorisations et surveillent le comportement des agents. Des approches émergentes, comme l'établissement d'identités composites pour les systèmes d'IA, peuvent attribuer la responsabilité des activités de l'IA à des équipes en suivant les actions des agents et ceux qui les ont autorisées.

Parallèlement, lorsque les équipes de sécurité maîtrisent la conception des systèmes, l'évaluation précise de l'impact d'une nouvelle implémentation d'IA sur les limites de sécurité existantes est facilitée. Aujourd'hui, de nombreux ingénieurs en sécurité ont du mal à expliquer comment fonctionne réellement le backend d'un LLM, mais comprendre comment un système d'IA est conçu est fondamental pour appréhender les risques de sécurité associés. Il n'est pas nécessaire d'avoir une expertise technique approfondie de chaque composant, mais il est important d’avoir une compréhension de base de la façon dont les éléments s'assemblent pour obtenir des résultats, comme les professionnels de la sécurité qui doivent comprendre le fonctionnement des applications web.

La voie à suivre

La plupart des organisations consacreront les deux prochaines années à développer des capacités d'IA sur des systèmes dont elles connaissent les diverses failles, car le développement logiciel ne peut pas attendre que tout soit corrigé. Cette approche est judicieuse, car il n'existe pas de solution propre pour chaque organisation afin de sécuriser le développement piloté par l'IA. La clé est de reconnaître les risques et de les gérer de manière stratégique tout en essayant de déterminer la bonne marche à suivre

Les équipes de sécurité ne peuvent pas non plus résoudre ces défaillances seules. Un rapport récent de DX montre que même si 91 % des équipes de développement utilisent désormais des outils d'IA et déclarent économiser 3 à 4 heures par semaine, les dysfonctionnements organisationnels (réunions, interruptions, lenteur des revues de code et temps d'attente CI) coûtent aux équipes plus de temps que l'IA n'en fait gagner. Les résultats en termes de qualité varient également selon les organisations : certaines constatent une amélioration des taux d'échec des modifications et des livraisons plus rapides, tandis que d'autres croulent sous une dette technique.

Ce qui différencie ces deux catégories d'organisations ne sont pas les outils d'IA eux-mêmes, mais les pratiques d'ingénierie et la culture sous-jacentes.

Les défaillances sont ancrées dans des problèmes en amont que l'IA expose désormais à grande échelle. Les revues de sécurité se situent à la fin de cette chaîne et héritent de chaque faiblesse.

Les équipes de sécurité doivent devenir des défenseurs des pratiques d'ingénierie et garantir un développement sécurisé piloté par l'IA avec des processus documentés, une culture de test solide et des principes de livraison continue qui intègrent la sécurité tout au long de la livraison logicielle.

Pour réussir, les organisations doivent résoudre ces problèmes dès maintenant, avant que le volume de code généré par l'IA ne rende cette tâche impossible.