En seulement quelques mois, nous avons été témoins de plusieurs événements technologiques liés à l'intelligence artificielle qui méritent le qualificatif galvaudé de « sans précédent » : une attaque très complexe de la chaîne d'approvisionnement par TeamPCP, la fuite des sources de Claude Code d'Anthropic PBC et les débuts de Claude Mythos d'Anthropic, un outil dit si puissant que son utilisation a été immédiatement limitée à certaines entreprises.
En tant que professionnels de la sécurité, nous envisageons un avenir dans lequel les attaques liées à l’IA se produiront très rapidement sous tous les angles, et les défenses liées à l’IA ne sont tout simplement pas prêtes. C'est la chaîne d'approvisionnement logicielle qui constitue la véritable source de revenus pour un attaquant.
Convergence dangereuse
Les récentes attaques TeamPCP mettent en évidence une convergence dangereuse entre les menaces traditionnelles de la chaîne d’approvisionnement logicielle et l’écosystème de l’IA en expansion rapide. Les attaquants, faisant preuve d'une sophistication offensive considérable, ont réussi à compromettre des outils de sécurité et d'intégration continue/de développement continu largement fiables, notamment le scanner de sécurité open source Trivy et la plateforme de sécurité des applications Checkmarx. ils ont ciblé LiteLLM, une bibliothèque Python open source et un serveur proxy qui fournit une interface unifiée pour appeler plus de 100 grands modèles de langage.
Les versions malveillantes de LiteLLM (1.82.7 et 1.82.8) étaient intégrées à un voleur d'informations d'identification et à un compte-gouttes en plusieurs étapes hautement obscurcis, conçus pour exécuter une attaque brutale avec un maximum de dégâts et d'impact. Le rayon d'action était particulièrement puissant, en raison de la nature des flux de développement courants, dans lesquels les développeurs, l'infrastructure cloud et les systèmes CI/CD partagent souvent l'accès à des informations d'identification sensibles. La compromission d'un outil unique, tel que LiteLLM, a permis aux attaquants de se déplacer latéralement à travers les clusters Kubernetes et d'exfiltrer les données vers des domaines contrôlés par les attaquants.
Les attaques contre la chaîne d’approvisionnement logicielle ne sont pas nouvelles ; l'incident de SolarWinds s'est produit il y a plus de cinq ans. Cependant, la faille TeamPCP réinvente entièrement le concept. C’est la première fois que nous assistons à une militarisation réussie de l’infrastructure de sécurité et de développement qui nécessite des privilèges d’accès élevés. Cela a non seulement permis aux attaquants d'accéder sans entrave aux secrets de production, mais également de lancer des attaques d'extorsion et de ransomware contre les entreprises compromises.
Le middleware comme infrastructure critique
La violation de TeamPCP est un exemple parfait de ce à quoi sont confrontés les responsables de la sécurité de l'information et les responsables de la sécurité dans le cadre de la nouvelle surface d'attaque de l'IA, et les organisations doivent traiter le « middleware » de l'IA comme une infrastructure critique lors de la planification de stratégies défensives. Les couches d'abstraction se trouvent directement dans le flux de données, traitant régulièrement des variables d'environnement hautement sensibles et des clés d'interface de programmation d'applications. Tout cadre de gouvernance de l’IA efficace devrait classer les middlewares d’IA parmi les composants à haut risque et appliquer une surveillance stricte aux secrets qu’ils utilisent et aux référentiels sensibles auxquels ils ont souvent un accès illimité.
Les politiques de gouvernance de l'IA devraient exiger que toute infrastructure prenant en charge les interactions LLM soit surveillée en permanence pour détecter les connexions sortantes non autorisées et l'exfiltration de données. Des flux de travail sécurisés pour les développeurs doivent également être appliqués contre les compromissions en cascade de la chaîne d'approvisionnement.
Nous devons également moderniser nos pratiques de gestion des risques pour garantir que les développeurs disposent de l’expertise nécessaire pour configurer, examiner et surveiller en toute sécurité les sorties et les modifications des outils. Par exemple, nous devrions corriger des processus tels que l'épinglage de dépendances pour empêcher l'exécution de mises à jour automatisées malveillantes, moderniser la gestion des secrets et appliquer le traitement du moindre privilège aux clés d'accès pour limiter l'exécution du pipeline à une liste d'actions approuvées par l'organisation.
Cette attaque met également en évidence à quel point il est crucial de donner la priorité à la visibilité et au contrôle des agents Model Context Protocol. Les dégâts causés par cette attaque ont été particulièrement dévastateurs, en grande partie parce que des plugins MCP non documentés ont été utilisés et ont pu être compromis à des fins néfastes. Nous ne pouvons tout simplement pas être aussi laxistes lors de la mise en œuvre d’une technologie dotée d’une telle puissance autonome et d’une telle connectivité interne.
Gestion des risques pour l'IA
La rapidité de cette attaque, qui a donné lieu à des milliers de compromissions potentielles en quelques heures seulement, prouve que la sécurité réactive n’est plus viable. En verrouillant les pipelines de dépendance et en régissant strictement les secrets qui alimentent les applications d’IA, nous pouvons réduire le rayon d’action de ces menaces sophistiquées sur la chaîne d’approvisionnement.
Les développeurs peuvent être habilités à partager la responsabilité de la sécurité de l’IA en :
- Perfectionnement continu et formation sur les dernières problématiques de sécurité de l'IA. Le développement de logiciels traditionnels est en passe de devenir une chose du passé, mais les compétences réelles requises pour qu'un développeur soit vraiment excellent resteront. Les responsables de la sécurité des entreprises doivent veiller à ce que leur formation soit continue et repose sur une base solide en matière de bonnes pratiques en matière de sécurité et de développement. Ces compétences pratiques, associées à une connaissance irremplaçable des objectifs commerciaux et à une pensée critique, sont les principaux ingrédients nécessaires à une révision de code réussie.
- Utiliser les outils de gouvernance de l’IA. Comment savoir quels développeurs ont commis quel code, y compris l'outil qu'ils ont utilisé pour le faire ? La nouvelle ère du codage de l’IA exige un plan de contrôle complet régissant les outils d’IA, les validations dans lesquelles ils sont impliqués et les compétences de sécurité de ceux qui créent et améliorent les fonctionnalités.
- Se conformer aux règles et directives de l'organisation. Le programme de sécurité de votre organisation est-il suffisamment à jour pour fournir des lignes directrices sur l'utilisation de l'IA ? Qu’en est-il des ensembles de règles spécifiques à l’IA pour les outils utilisés ? Ce sont des gains rapides qui peuvent au moins faire respecter les normes minimales de codage sécurisé.
Si vous attendez une législation pour guider la gouvernance de l'IA de votre organisation, il se peut qu'une violation assistée par l'IA vous trouve en premier. Ne vous laissez pas prendre au dépourvu.
Matias Madou est co-fondateur et directeur de la technologie de Secure Code Warrior Ltd. Il a écrit cet article pour SiliconANGLE.
