La faille de sécurité cachée de l’IA à l’origine de quatre attaques majeures de la chaîne d’approvisionnement

Les équipes rouges de sécurité de l’IA négligent les pipelines de versions et les systèmes de construction.

La sécurité des modèles d’IA a progressé rapidement, mais ce qui manque, c’est l’attention portée aux systèmes qui construisent et diffusent ces modèles. La plupart des organisations ont des équipes rouges qui testent la sécurité des modèles, à la recherche d’une mauvaise utilisation, d’une injection rapide ou d’une fuite de données. C’est une bonne chose, mais les adversaires se sont déplacés plus en amont. Ils ciblent les pipelines CI/CD, les dépendances des paquets et les flux de travail de publication, des endroits que peu d’équipes rouges examinent aujourd’hui.

Quatre incidents majeurs survenus en l’espace de 50 jours ont mis en évidence cet angle mort. OpenAI, Anthropic, Meta et TanStack ont tous souffert de failles dans leurs systèmes de construction ou de publication. Leurs équipes rouges ont passé tous les tests de sécurité, mais des attaquants se sont tout de même glissés dans des flux de travail fiables et ont injecté du code malveillant. Cela prouve qu’il ne suffit pas de sécuriser uniquement le modèle. L’ensemble de la chaîne, de la validation à la production, doit être testé et renforcé.

Les dirigeants doivent considérer ce risque comme un risque structurel. Si les attaquants compromettent les systèmes de validation de confiance, ils contrôlent la couche de distribution de l’IA. Cela signifie que même les logiciels vérifiés peuvent être malveillants. Les entreprises à la croissance la plus rapide fonctionnent aujourd’hui sur des pipelines entièrement automatisés. En l’absence de véritables tests de l’équipe rouge à ce niveau, la confiance devient une illusion fondée sur des hypothèses dépassées.

L’étape immédiate est claire : créer des équipes rouges axées sur le pipeline. Étendez la portée de la sécurité au-delà des modèles pour inclure les environnements de construction, les flux d’automatisation et les registres de dépendances. Il s’agit d’exécuter plus intelligemment et d’auditer là où les attaquants opèrent réellement.

Les assurances de provenance cryptographiques ne garantissent pas une intention de construction bénigne

Le ver TanStack Mini Shai-Hulud a prouvé quelque chose que l’industrie ne voulait pas entendre. Vous pouvez suivre toutes les règles, utiliser des attestations signées, et quand même publier du code compromis. Le ver a exploité une simple erreur de configuration dans les actions GitHub, a abusé de l’empoisonnement du cache et a extrait des jetons d’authentification directement de la mémoire du runner. Il a ensuite poussé 84 paquets npm malveillants, tous signés avec une provenance SLSA Build Level 3 valide. Toutes les listes de contrôle de sécurité indiquaient que ces paquets étaient sûrs. Ils ne l’étaient pas.

C’est là que trop de programmes de sécurité cessent de penser de manière critique. La provenance prouve l’origine du code. Vous pouvez authentifier une version malveillante aussi facilement qu’une version propre si un attaquant contrôle l’environnement de création. Pour les dirigeants, cela signifie que la conformité seule n’empêchera pas la prochaine violation. Les signatures sécurisées ne corrigent pas l’automatisation compromise.

La sécurité des entreprises doit évoluer vers une validation comportementale. L’objectif est de vérifier la source de construction et de surveiller activement sa logique d’exécution. Si quelque chose se comporte différemment de ce qui est attendu après l’empaquetage, c’est un problème qu’aucun certificat ne peut résoudre. C’est la couche que la plupart des organisations ignorent, et pourtant c’est là que les attaquants vivent depuis des mois.

Pour les dirigeants, la prochaine étape est pratique : exiger l’analyse comportementale dans votre processus de mise en production. Exigez de chaque pipeline qu’il confirme la provenance et le comportement en cours d’exécution. L’audit de l’intention de construction devrait devenir une norme, tout comme la vérification de l’origine du code. La provenance continuera d’être importante, mais elle ne représente que la moitié de la vérité.

La compromission d’informations d’identification dans les écosystèmes de dépendance partagés peut entraîner des violations intersectorielles.

L’attaque LiteLLM a montré à quel point les écosystèmes partagés sont devenus fragiles. TeamPCP, un groupe de menace, a réutilisé des informations d’identification volées lors d’une précédente intrusion dans un scanner de vulnérabilités pour accéder à l’index public des paquets de Python, PyPI. Ils ont téléchargé deux versions empoisonnées de LiteLLM, une passerelle proxy open-source largement utilisée pour les grands modèles de langage. Ces paquets malveillants ont existé pendant moins de quarante minutes, mais ils ont été téléchargés près de 47 000 fois au cours de cette brève période.

Il n’en fallait pas plus pour déclencher une réaction en chaîne dans le secteur de l’IA. Mercor, un fournisseur de données de 10 milliards de dollars pour Meta, OpenAI et Anthropic, a intégré à son insu la dépendance compromise. Résultat : 4 téraoctets de données d’entraînement et de références propriétaires de Meta ont été exfiltrés. Le coût a été immédiat. Meta a gelé son partenariat avec Mercor et, en l’espace d’une semaine, des recours collectifs ont suivi.

Ce que cela signifie pour les dirigeants est simple. Chaque dépendance dans votre chaîne d’approvisionnement en logiciels représente un point de compromission potentiel. Les audits traditionnels qui s’arrêtent aux contrôles de première partie ne détecteront pas ces attaques. L’hygiène des certificats de dépendance doit maintenant devenir une priorité au niveau du conseil d’administration, avec la responsabilité de chaque fournisseur qui touche votre code ou vos données.

Les entreprises devraient exiger une authentification multifactorielle ou par clé matérielle pour chaque responsable, imposer des périodes de refroidissement avant la mise en service de nouvelles versions de paquets et programmer des audits trimestriels de l’arbre de dépendance. Il s’agit là de nécessités opérationnelles si vous dépendez d’une infrastructure à code source ouvert. La faille de LiteLLM n’a duré que quelques minutes, mais ses conséquences se sont étendues à trois des plus grands laboratoires d’intelligence artificielle au monde.

Des erreurs répétées dans la mise en circulation des emballages mettent en évidence les lacunes des systèmes de distribution automatisés en matière de contrôle humain.

L’incident Claude Code d’Anthropic a révélé comment la surveillance humaine a été dégradée par l’automatisation. En mars 2026, la version 2.1.88 a été poussée vers npm avec une carte source de 59,8 Mo contenant 513 000 lignes de TypeScript non obscurci. Ces fichiers exposaient une logique sensible, des couches d’orchestration d’agents, des drapeaux de fonctionnalités et des invites internes du système. Il ne s’agissait pas d’une attaque. Il s’agissait d’une erreur d’empaquetage causée par une ligne manquante dans .npmignore. Pourtant, l’effet était le même : du code propriétaire exposé au public pendant des heures.

L’automatisation va vite, souvent trop vite pour que les erreurs soient détectées en l’absence de contrôle humain. Anthropic avait mis en place des mesures de protection, mais n’avait pas mis en place de barrière manuelle entre l’artefact de construction et l’étape finale de publication. Il s’agit du deuxième incident de ce type en 13 mois, ce qui prouve que la leçon n’a pas été assimilée. Pour les dirigeants, la leçon à retenir est que l’automatisation peut rationaliser les flux de travail, mais que l’automatisation non contrôlée introduit des modes de défaillance silencieux avec un coût stratégique élevé.

Les entreprises ont besoin de contrôles humains obligatoires avant toute publication externe d’une version critique. Une simple étape de vérification du contenu des artefacts, de la taille des fichiers attendus et des irrégularités de la somme de contrôle peut prévenir les atteintes à la réputation et les dommages financiers. Les dirigeants devraient également investir dans des dispositifs de sécurité automatisés qui interrompent la finalisation de la construction lorsque des artefacts inattendus apparaissent. Il s’agit d’un coût opérationnel minime pour éviter l’exposition publique d’une propriété intellectuelle de plusieurs millions de dollars.

Une vérification insuffisante des entrées dans les outils de construction peut entraîner de graves vulnérabilités par injection de commandes.

La faille dans le Codex d’OpenAI a mis en évidence une chose : la négligence dans le traitement des paramètres d’entrée peut compromettre des environnements de développement entiers. Le chercheur Tyler Jespersen de BeyondTrust Phantom Labs a découvert que Codex transmettait les noms de branches GitHub directement dans les commandes shell sans vérification. Cela permettait aux attaquants d’injecter des commandes shell et d’extraire des jetons OAuth du conteneur Codex. Le problème ne réside pas dans le modèle d’IA, mais dans la logique qui relie les outils utilisés pour le construire et le gérer.

Cette vulnérabilité a affecté plusieurs produits, le site web ChatGPT, Codex CLI, Codex SDK, et même des extensions IDE. OpenAI l’a classée comme un problème critique P1 et l’a corrigée avant février 2026. Néanmoins, l’incident a mis en évidence un risque négligé dans les environnements de développement intégrés : une automatisation non sécurisée combinée à un traitement des entrées insuffisamment contrôlé.

Les dirigeants doivent comprendre que la validation des entrées n’est pas seulement une nécessité technique ; c’est une garantie pour l’entreprise. Chaque interface qui traite des données externes doit valider ces entrées avant leur exécution. Ces contrôles empêchent les compromissions au niveau du conteneur qui peuvent exposer des informations d’identification sensibles et une logique propriétaire. Les tests de l’équipe rouge devraient s’étendre au-delà du modèle à chaque script de support, point de terminaison API et interaction système dans le processus de mise en production.

Les dirigeants doivent promouvoir des normes de codage rigoureuses qui s’appliquent à toutes les couches d’automatisation. Les configurations à moindre privilège, les durées de vie strictes des jetons OAuth et l’assainissement complet des entrées devraient être des normes, et non des options. Il ne s’agit pas d’une question de sophistication des outils, mais d’une question de rigueur culturelle dans le développement et les opérations.

Le lancement d’initiatives avancées en matière de cybersécurité ne compense pas les risques liés au retard des mises à jour opérationnelles.

Lorsque OpenAI a lancé son initiative de sécurité Daybreak le 10 mai 2026, alimentée par GPT-5.5-Cyber et soutenue par des partenaires tels que Cisco, CrowdStrike, Akamai, Cloudflare et Zscaler, l’entreprise l’a présentée comme une étape importante dans la défense pilotée par l’IA. Un jour plus tard, OpenAI a confirmé une brèche affectant son propre pipeline CI/CD. Deux appareils d’employés ont été compromis et la rotation des certificats a dû être forcée sur tous les clients macOS.

Le problème n’était pas l’absence de contrôles de sécurité, ceux-ci étaient en cours de déploiement. La faille est simplement arrivée en premier. Cela souligne un point que tous les dirigeants devraient prendre en considération : la sophistication de vos systèmes de sécurité importe peu si leur mise en œuvre est en retard par rapport aux menaces du monde réel. Les résultats en matière de cybersécurité dépendent de la rapidité avec laquelle les configurations critiques sont appliquées à chaque point de terminaison et à chaque système.

Les analystes de l’industrie ont remarqué les incohérences dans la réponse d’OpenAI.@EnTr0pY_88 a souligné que la rotation des certificats de signature indiquait une compromission plus profonde de l’infrastructure de confiance.@OpenMatter_ et @The_Calda ont tous deux souligné que les déclarations d' »impact limité » ne correspondaient pas à l’étendue de la rotation des certificats et des défaillances du contrôle de la provenance. Leurs commentaires ont mis en évidence un problème plus large, à savoir que la vitesse des processus et la cadence de déploiement de l’organisation étaient en décalage par rapport à la chronologie des menaces.

Les dirigeants doivent veiller à ce que leurs entreprises évitent cet échec. Le lancement d’un nouveau programme de cybersécurité est positif, mais il doit coïncider avec un déploiement continu et une synchronisation opérationnelle efficace. Des audits internes réguliers et une validation en temps quasi réel garantissent que les contrôles sont non seulement conçus mais aussi appliqués dans tous les environnements. Les initiatives en matière de cybersécurité qui ne sont pas immédiatement exploitables ne font que créer un faux sentiment de protection.

Les cadres de sécurité existants ne traitent que partiellement les vulnérabilités de la surface de diffusion, ce qui laisse des lacunes critiques.

La matrice prescriptive de VentureBeat met en évidence un problème que de nombreuses grandes organisations ont ignoré : les cadres de sécurité actuels ne couvrent pas toutes les surfaces du processus de diffusion de l’IA. Les normes telles que NIST SSDF et SLSA fournissent des conseils sur la protection de l’intégrité du code et la vérification de l’identité des contributeurs, mais elles sont insuffisantes dans des domaines clés tels que les limites de confiance des opérateurs d’IC et la provenance des informations d’identification des mainteneurs. Ces omissions laissent des voies ouvertes à la compromission à l’intérieur des systèmes automatisés de construction et de publication.

La matrice identifie sept catégories de surfaces de diffusion qui ne sont pas examinées dans la plupart des audits des fournisseurs d’IA. Les lacunes incluent des scripts de cycle de vie non restreints, des flux de travail de publication non contrôlés et l’absence d’un examen humain obligatoire entre la construction et la publication. Ces points faibles sont exactement là où opèrent des équipes comme TeamPCP et des vers qui se propagent d’eux-mêmes comme Mini Shai-Hulud. Les dirigeants qui pensent que les cadres de certification équivalent à une protection totale se trompent sur la portée de ces outils. Les cadres réduisent les risques, mais ils n’éliminent pas les surfaces non traitées.

Pour les décideurs, cela implique un changement de langage dans l’évaluation des partenaires. Les questionnaires des fournisseurs doivent inclure l’alignement des politiques non seulement sur le modèle de sécurité, mais aussi sur des audits complets de la sécurité des pipelines. Là où le NIST SSDF et le SLSA s’arrêtent, les entreprises doivent définir des normes internes qui comblent le vide opérationnel. Attendre que les régulateurs ou les organismes de normalisation publient de nouveaux cadres n’empêchera pas la prochaine compromission de la chaîne d’approvisionnement.

Pour combler cette lacune, les organisations doivent immédiatement comparer chaque surface de publication aux cadres de contrôle existants et identifier les zones de responsabilité manquantes. Attribuez la propriété, testez les capacités de détection et validez l’application. Cette approche garantit que chaque processus, manuel ou automatisé, bénéficie d’une couverture et d’une surveillance explicites avant le prochain cycle d’audit.

Un changement stratégique visant à inclure le red teaming axé sur le pipeline est essentiel pour une sécurité robuste de l’IA.

L’élargissement des opérations de l’équipe rouge aux pipelines de construction et de publication est désormais une nécessité stratégique. Le plan d’action des directeurs de la sécurité préconise trois actions immédiates de la part des dirigeants : premièrement, ajouter la portée de l’équipe rouge sur les pipelines de mise en production à chaque questionnaire des fournisseurs d’IA ; deuxièmement, tester les pipelines d’IC internes à l’aide d’outils tels que StepSecurity et Snyk ; troisièmement, informer le conseil d’administration sur les lacunes en matière de provenance et sur les exigences en matière d’analyse comportementale. Ces étapes établissent une responsabilité claire et garantissent que les dirigeants conservent une visibilité directe sur la sécurité opérationnelle.

Ce changement doit être impulsé par la direction. Les équipes de sécurité ont déjà de lourdes charges de travail et, en l’absence de directives claires de la part de la direction, les tests de pipeline sont souvent relégués au second plan au profit d’efforts de contrôle réglementaires ou visibles par les clients. Les dirigeants doivent intégrer cette discipline dans tous les départements, développement, opérations et conformité, afin de s’aligner sur un seul objectif : sécuriser l’ensemble de la chaîne de livraison.

Les organisations qui suivent ces recommandations renforcent à la fois leur résilience et leur crédibilité. Les investisseurs, les clients et les partenaires prêtent attention non seulement à la technologie, mais aussi à la gouvernance et à la maturité des processus. La mise en place d’équipes rouges sur les pipelines CI/CD, le test de la portée de l’OIDC et l’audit des crochets de dépendance témoignent d’une maîtrise opérationnelle des risques. Ce sont des indicateurs mesurables de la viabilité à long terme.

Pour les décideurs, le pipeline red-teaming est le prochain facteur de différenciation concurrentielle dans le domaine de la sécurité de l’IA. Elle transforme la sensibilisation en tests continus et comble le fossé que les équipes rouges traditionnelles négligent. Les entreprises qui prennent de l’avance établiront de nouvelles références en matière de sécurité et définiront les normes que les autres devront suivre.

L’exposition systémique des informations d’identification des développeurs dans les écosystèmes d’outils d’IA pose des risques croissants.

Le ver Mini Shai-Hulud est allé au-delà de la simple infection. Il a activement recherché dans les systèmes des développeurs les informations d’identification utilisées par les outils d’intelligence artificielle et les environnements de développement. Les analyses de Datadog Security Labs et de StepSecurity ont confirmé que la charge utile recherchait des fichiers tels que ~/.claude.json et tentait d’extraire des informations de coffres-forts d’authentification tels que 1Password et Bitwarden. Il a également ciblé les comptes de service Kubernetes, les jetons cloud et les fichiers d’historique du shell, révélant une compréhension claire des flux de travail des développeurs et de l’endroit où les clés critiques sont stockées.

Ce comportement montre que les acteurs des menaces modernes s’alignent directement sur la façon dont les équipes d’IA travaillent. Les plateformes de développement contiennent désormais à la fois du code source et du matériel d’authentification, souvent stockés de manière non sécurisée pour des raisons de commodité. Le succès du ver illustre une faiblesse opérationnelle plus importante, à savoir le mélange d’informations d’identification personnelles et d’entreprise dans des contextes de développement uniques. Pour les dirigeants, cela signifie que la surface de menace ne se situe plus uniquement à l’intérieur du périmètre de l’entreprise ; elle s’étend à chaque poste de travail des développeurs.

Les entreprises doivent repenser leur gestion des informations d’identification des développeurs. Les secrets durs ne devraient jamais exister en clair sur les machines locales, et les gestionnaires de secrets doivent appliquer une segmentation stricte des informations d’identification de production et de développement. La mise hors service régulière des anciens jetons et l’introduction d’informations d’identification de courte durée doivent être imposées par une politique. Il s’agit de mesures de confinement simples qui réduisent considérablement le rayon d’action d’une compromission.

Ce vecteur de menace continuera à s’étendre à mesure que le développement de l’IA intègre davantage d’agents tiers et de connexions API. La sécurité au niveau du point final et du pipeline de construction doit évoluer pour gérer cette complexité. Les dirigeants responsables de la technologie et des opérations devraient donner la priorité au financement des capacités de détection qui peuvent identifier les comportements de collecte d’informations d’identification spécifiques à l’IA avant qu’ils ne se répandent dans les systèmes internes.

Les mesures d’évaluation des modèles restent nécessaires mais insuffisantes en l’absence de défenses complètes des pipelines.

Les investissements en cours dans les évaluations de la sécurité des modèles et les cartes de système d’OpenAI, d’Anthropic et de Meta ont amélioré la transparence de la gouvernance de l’IA, mais ils n’ont pas permis de remédier aux vulnérabilités de l’infrastructure de construction au sens large. La dernière série d’incidents a prouvé que le risque ne s’arrête pas à la frontière du modèle. La compromission des pipelines, des registres et des dépendances permet aux adversaires de manipuler les résultats bien avant que le modèle ne soit déployé, en contournant tous les cadres d’évaluation existants.

Les dirigeants doivent interpréter ce changement avec prudence. La sécurité des modèles est une exigence fondamentale, mais la considérer comme la seule ligne de défense laisse l’infrastructure sans protection. Le ver TanStack et d’autres violations de la chaîne d’approvisionnement ont démontré que les attaquants préfèrent la couche la moins protégée, les systèmes d’automatisation qui alimentent et diffusent les modèles. Lorsque ces systèmes sont compromis, c’est toute la ligne de produits d’IA qui hérite du risque.

La solution consiste à combiner l’évaluation des modèles avec une sécurité active du pipeline. Toute organisation produisant ou consommant des logiciels d’IA doit vérifier à la fois l’exactitude du modèle et l’authenticité de la construction. Cela signifie qu’il faut mettre en place des contrôles comportementaux, des contrôles humains et des contrôles en temps réel au sein des pipelines de diffusion, en plus de publier des cartes de système pour gagner la confiance du public. Les cadres de sécurité et les programmes de gouvernance doivent évoluer pour traiter le modèle et l’infrastructure comme un environnement interdépendant.

Pour les dirigeants, la voie à suivre est pratique. Rééquilibrer les ressources de manière à ce que le budget et les talents soient répartis équitablement entre la sécurité des modèles et la sécurité des libérations. Ces domaines doivent progresser en parallèle. Un modèle solide construit sur un pipeline non protégé est un système qui attend d’être violé. Lorsque les deux sont sécurisés, les entreprises d’IA gagnent en résilience et en crédibilité durable sur un marché de plus en plus concurrentiel et dense en menaces.

En conclusion

Le message est simple. La prochaine frontière de la sécurité de l’IA ne concerne pas les modèles plus sûrs, mais la sécurisation de la façon dont ces modèles sont construits, emballés et expédiés. Toutes les brèches survenues au cours des derniers mois ont mis en évidence le même point faible : des pipelines de validation et des systèmes d’automatisation qui fonctionnent plus rapidement que leur gouvernance.

Pour les dirigeants, il ne s’agit pas d’une note de bas de page technique. Il s’agit d’une priorité stratégique. La posture de sécurité d’une entreprise d’IA dépend désormais autant de son infrastructure de construction que de ses algorithmes. L’automatisation de confiance est devenue une cible de grande valeur, et les attaquants savent déjà comment la manipuler.

Pour combler ce fossé, il faut faire preuve de leadership, et non multiplier les outils. Mandatez le red teaming version-pipeline. Tenez la sécurité et l’ingénierie responsables ensemble. Exigez une provenance transparente avec une vérification active. Financez le renforcement du pipeline comme vous le feriez pour l’optimisation des modèles. Le coût de la prévention est faible par rapport au coût d’une clé de signature compromise ou d’une fuite de données.

L’IA va continuer à se développer rapidement, et les entreprises qui seront à la pointe de cette évolution sont celles qui sont capables d’expédier leurs produits en toute sécurité et à grande vitesse. L’intégrité à chaque étape du processus de publication fait désormais partie de la continuité des activités, de la confiance dans la marque et du leadership sur le marché. L’avenir de l’IA sécurisée ne se construit pas après le déploiement, il se construit à chaque engagement.