Les résultats récents des insécurités et des attaques des écosystèmes d’IA montrent à quel point les MLSecops sont importants pour assurer des stratégies d’IA à partir de risques complexes et souvent très cachés.
La chaîne d’approvisionnement des logiciels AI se développe rapidement pour inclure non seulement des outils de développement open source, mais également des plates-formes collaboratives où les développeurs partagent des modèles, des agents, des invites et d’autres ressources personnalisés. Et avec cette expansion de l’utilisation des composants et des services tiers de l’IA, une menace de sécurité élargie – celle qui, à bien des égards, peut être plus complexe, obscurcie et pernicieuse que les problèmes traditionnels de la chaîne d’approvisionnement des logiciels.
Alors que les entreprises se précipitent pour expérimenter l’IA, souvent avec moins de surveillance que pour le développement de logiciels traditionnels, les attaquants réalisent rapidement ces nouvelles plateformes et actifs partageables qui ne relèvent de la surveillance typique de la sécurité peuvent être exploités pour compromettre les systèmes et les données.
Défauts et code malveillant dans les dépendances de l’IA sur la montée
La semaine dernière, les chercheurs de la société de sécurité d’application Billondslash ont averti que des centaines de serveurs de protocole de contexte de modèle (MCP) partagés publics ont des configurations en insécurité qui peuvent ouvrir des trous d’exécution de commande arbitraire sur des systèmes qui les déploitent. Les serveurs MCP relient les modèles de grandes langues (LLMS) aux services tiers, aux sources de données et aux outils pour fournir un contexte de raisonnement amélioré, ce qui en fait un outil indispensable pour construire des agents d’IA.
Plus tôt en juin, des chercheurs de l’AI Security Startup, Noma Security, ont mis en garde contre une fonctionnalité du centre rapide de Langchain qui pourrait être abusée par les attaquants pour distribuer des invites malveillantes qui volent des jetons d’API et des données sensibles. Le Langchain Invite Hub fait partie de Langsmith, une plate-forme pour construire, tester et surveiller les performances des applications basées sur l’IA.
Les utilisateurs de Langsmith peuvent partager des invites de système complexes entre elles dans un centre d’invite, et ceux-ci se comportent comme des agents d’IA. Une fonctionnalité lors du développement de telles invites consiste à spécifier un serveur proxy à travers lequel acheminer toutes les demandes d’API vers un fournisseur LLM.
« Cette vulnérabilité nouvellement identifiée a exploité les utilisateurs sans méfiance qui adoptent un agent contenant un serveur de proxy malveillant préconfiguré téléchargé sur` `Hub Invite » (qui est contre Langchain TOS) », ont écrit les chercheurs du Noma Security. « Une fois adopté, le proxy malveillant a discrètement intercepté toutes les communications des utilisateurs – y compris des données sensibles telles que les clés de l’API (y compris les clés API OpenAI), les invites utilisateur, les documents, les images et les entrées vocales – à l’insu de la victime. »
L’équipe de Langchain a depuis ajouté des avertissements aux agents contenant des configurations de proxy personnalisées, mais cette vulnérabilité met en évidence la façon dont les fonctionnalités bien intentionnées peuvent avoir de sérieuses répercussions de sécurité si les utilisateurs ne prêtent pas attention, en particulier sur les plateformes où ils copient et exécutent le code des autres sur leurs systèmes.
Le problème, comme l’a mentionné le renard de Sonatype, est que, avec l’IA, le risque s’étend au-delà du code exécutable traditionnel. Les développeurs pourraient plus facilement comprendre pourquoi la gestion des composants logiciels de référentiels tels que PYPI, NPM, NuGet et Maven Central sur leurs machines comportent des risques importants si ces composants ne sont pas vérifiés en premier par leurs équipes de sécurité. Mais ils pourraient ne pas penser que les mêmes risques s’appliquent lors du test d’une invite de système dans un modèle LLM ou même un modèle d’apprentissage automatique personnalisé (ML) partagé par d’autres.
Les attaquants comprennent parfaitement que la chaîne d’approvisionnement de l’IA est à la traîne du développement des logiciels traditionnels en surveillance et a commencé à en profiter. Plus tôt cette année, les chercheurs ont trouvé du code malveillant à l’intérieur des modèles d’IA hébergés sur un visage étreint, la plus grande plate-forme pour partager des actifs d’apprentissage automatique.
Ces attaques ont profité du format de cornichon sérialisé de Python. En raison de la popularité de Pytorch en tant que bibliothèque ML largement utilisée écrite en Python, Pickle est devenu un moyen courant de stocker et de distribuer des modèles ML. Peu d’outils de sécurité ont la capacité de scanner ces fichiers pour l’instant pour un code malveillant.
Plus récemment, les chercheurs ont trouvé une composante voyou sur le PYPI qui se faisait passer pour un SDK Alibaba AI et contenait un modèle empoisonné au format de cornichon avec un code caché malveillant à l’intérieur.
Les outils de sécurité rattrapent toujours les risques de la chaîne d’approvisionnement de l’IA
« La plupart des outils aujourd’hui ne sont pas entièrement équipés pour scanner des modèles d’IA ou des invites à un code malveillant, et les attaquants exploitent déjà cet écart », explique Fox de Sonatype. «Alors que certaines solutions précoces émergent, les organisations ne devraient pas attendre. Ils doivent étendre les politiques de sécurité existantes pour couvrir ces nouveaux composants maintenant – parce que le risque est réel et en croissance.»
Ken Huang, Caio de DistributedApps.ai et coprésident du groupe de travail sur la sécurité de la Sécurité Cloud Security Alliance (CSA), concordent: «Les équipes hiérarchisent souvent la vitesse et l’innovation sur une vérification rigoureuse, en particulier car le codage d’ambiance est plus facile à générer et à partager le code. la probabilité de compromis de la chaîne d’approvisionnement. »
Le codage des vibrations est la pratique de plus en plus courante de développer des applications entières à l’aide d’assistants de code alimentés par LLM, l’humain agissant en tant que surveillant donnant la contribution via des invites en langage naturel. Les chercheurs en sécurité ont averti que cette pratique peut entraîner un code avec des erreurs et des vulnérabilités difficiles à détecter.
La CSA, une association de l’industrie à but non lucratif qui promeut les pratiques d’assurance de la sécurité dans le cloud computing, a récemment publié un guide d’aménagement de l’IA Red CO-auteur par Huang avec plus de 50 contributeurs et examinateurs de l’industrie. L’un des chapitres s’attaque aux tests pour les attaques de chaîne d’approvisionnement et de dépendance des agents d’IA qui peuvent entraîner un accès non autorisé, des violations de données ou des défaillances du système.
Une approche MLSECOPS complète
Les recommandations de Huang comprennent:
- Vibe codage des risques d’atténuation: Reconnaissez que le codage d’ambiance peut introduire des dépendances en insécurité ou inutiles et appliquer un examen manuel du code et des bibliothèques générés par l’IA. Encouragez le scepticisme et la vérification de toutes les suggestions générées par l’IA, en particulier les noms de packages et les recommandations de cadre.
- MLBOM et AIBOM: L’établissement d’un apprentissage automatique ou d’une facture de matériel d’IA fournira aux entreprises des inventaires détaillés de tous les ensembles de données, modèles et dépendances de code, offrant une transparence et une traçabilité pour les actifs spécifiques à l’IA. Les cartes modèles et les cartes système aident à documenter l’utilisation, les limitations et les considérations éthiques prévues, mais ne traitez pas les risques techniques de la chaîne d’approvisionnement. MLBOM / AIBOM les complète en se concentrant sur la provenance et l’intégrité.
- Analyse et surveillance continues: Intégrez le modèle et les scanners de dépendance dans les pipelines CI / CD et surveillez les comportements anormaux après le déploiement.
- Zéro confiance et moindre privilège: Traitez tous les actifs de l’IA tiers comme non fiables par défaut, isolez et sandbox de nouveaux modèles et agents et restreignez les autorisations pour les agents de l’IA.
- Alignement politique: Assurez-vous que les plates-formes et les référentiels de l’IA sont couverts par les politiques de sécurité de la chaîne d’approvisionnement logiciels existantes, mis à jour pour répondre aux risques uniques de codage de l’IA et de l’ambiance.
