Aller au contenu principal
Mend publie un cadre de gouvernance de la sécurité IA : inventaire des ressources, classification des risques, sécurité de la chaîne d'approvisionnement et modèle de maturité
SécuritéMarkTechPost3sem

Mend publie un cadre de gouvernance de la sécurité IA : inventaire des ressources, classification des risques, sécurité de la chaîne d'approvisionnement et modèle de maturité

Résumé IASource uniqueImpact UE
Source originale ↗·

Mend, spécialiste de la sécurité applicative, a publié un guide pratique intitulé "AI Security Governance: A Practical Framework for Security and Development Teams", destiné aux équipes de sécurité et de développement confrontées à l'essor incontrôlé des outils d'IA en entreprise. Le document part d'un constat précis : dans la quasi-totalité des organisations, les développeurs adoptent des outils comme GitHub Copilot ou des API tierces (OpenAI, Google Gemini) avant même que les équipes sécurité n'en aient connaissance. Le framework propose une réponse structurée en quatre piliers : inventaire des actifs IA, système de classification par niveau de risque, contrôle d'accès et traçabilité de la chaîne d'approvisionnement des modèles. Le coeur du dispositif repose sur un système de score allant de 5 à 15 points, évalué sur cinq dimensions : sensibilité des données, autorité décisionnelle, accès aux systèmes, exposition externe et origine dans la chaîne d'approvisionnement. Selon ce score, chaque déploiement IA est classé en Tier 1 (risque faible, revue standard), Tier 2 (risque modéré, audits comportementaux trimestriels) ou Tier 3 (risque élevé, évaluation complète, surveillance continue et plan de réponse aux incidents obligatoire).

Ce cadre répond à un problème structurel croissant : le "shadow AI", c'est-à-dire les outils d'IA utilisés en production sans validation de la sécurité. Mend insiste sur le fait que la découverte de ces outils doit être non punitive, afin que les développeurs les déclarent sans crainte. Le framework souligne également que le niveau de risque d'un modèle peut changer radicalement sans modification de son code : connecter un modèle précédemment isolé à une base de données de production en écriture suffit à le faire passer du Tier 1 au Tier 3. Pour les sorties de modèles, le guide impose un filtrage actif des données réglementées (numéros de sécurité sociale, cartes bancaires, clés API) et exige que le code généré par IA soit traité comme une entrée non fiable, soumis aux mêmes analyses SAST, SCA et détection de secrets que le code écrit par des humains.

Le troisième volet majeur concerne la chaîne d'approvisionnement des modèles. Mend introduit le concept d'AI Bill of Materials (AI-BOM), extension du SBOM traditionnel appliqué aux artefacts de modèles, aux jeux de données d'entraînement, aux entrées de fine-tuning et à l'infrastructure d'inférence. L'idée centrale est qu'intégrer un modèle tiers revient à hériter de la posture de sécurité de ceux qui l'ont entraîné. Ce framework s'inscrit dans un mouvement plus large de régulation de l'IA en entreprise, porté à la fois par des exigences réglementaires émergentes (EU AI Act, directives NIST) et par la multiplication des incidents liés à des modèles mal configurés ou mal cloisonnés. Mend positionne ce guide comme un point de départ accessible, non comme un programme de maturité avancée, ce qui le rend particulièrement pertinent pour les organisations qui débutent leur gouvernance IA.

Impact France/UE

Le cadre s'aligne explicitement sur les exigences de l'EU AI Act en matière de classification des risques IA et de documentation (AI-BOM), offrant aux entreprises européennes une méthodologie concrète pour structurer leur conformité réglementaire.

Vu une erreur factuelle dans cet article ? Signalez-la. Toutes les corrections valides sont publiées sur /corrections.

À lire aussi

Mend.io publie un cadre de gouvernance de la sécurité IA couvrant inventaire des actifs, niveaux de risque et chaîne d'approvisionnement
1MarkTechPost 

Mend.io publie un cadre de gouvernance de la sécurité IA couvrant inventaire des actifs, niveaux de risque et chaîne d'approvisionnement

La société Mend.io, spécialisée en sécurité applicative, vient de publier un guide pratique intitulé "AI Security Governance: A Practical Framework for Security and Development Teams". Ce document s'adresse directement aux responsables AppSec, chefs d'équipes ingénierie et data scientists confrontés à une prolifération incontrôlée des outils d'IA au sein de leurs organisations. Le cadre propose quatre piliers concrets : un inventaire exhaustif des actifs IA, un système de classification des risques en trois niveaux, une gestion de la chaîne d'approvisionnement des modèles, et un modèle de maturité progressif. Le système de scoring attribue à chaque déploiement IA une note de 1 à 3 sur cinq dimensions, sensibilité des données, autorité décisionnelle, accès systèmes, exposition externe et origine dans la chaîne d'approvisionnement, pour un total entre 5 et 15. Un score de 5 à 7 place l'actif en Tier 1 (revue standard), 8 à 11 en Tier 2 (audits comportementaux trimestriels), et 12 à 15 en Tier 3, qui impose une évaluation complète, une supervision continue et un plan de réponse aux incidents opérationnel avant tout déploiement. Ce framework répond à un problème devenu critique dans presque toutes les grandes entreprises : les outils d'IA entrent en production bien avant que les équipes sécurité n'en soient informées. Un développeur installe GitHub Copilot, une équipe produit intègre discrètement un modèle tiers dans une branche de fonctionnalité, un analyste interroge un LLM externe pour ses rapports. Résultat : des modèles traitent des données sensibles et prennent des décisions réelles sans aucun contrôle formalisé. Mend insiste sur un point souvent négligé : le niveau de risque d'un modèle peut passer brutalement du Tier 1 au Tier 3 sans que son code change, simplement parce qu'on lui a accordé un accès en écriture à une base de données de production ou qu'on l'a exposé à des utilisateurs externes. Le guide exige aussi d'appliquer le principe du moindre privilège aux systèmes IA exactement comme aux utilisateurs humains : clés API à portée restreinte, accès en lecture seule par défaut, et filtrage des sorties pour les données régulées comme les numéros de sécurité sociale, les cartes bancaires ou les clés d'API. Le document s'inscrit dans une tendance plus large qui voit la sécurité logicielle traditionnelle s'adapter à l'ère des modèles de fondation. Mend étend notamment le concept de SBOM (Software Bill of Materials) en introduisant un "AI-BOM", qui documente non seulement les dépendances logicielles, mais aussi les datasets d'entraînement, les entrées de fine-tuning et l'infrastructure d'inférence. Face à des outils comme OpenAI, Google Gemini, Notion AI ou Codeium désormais omniprésents dans les workflows professionnels, l'enjeu est de normaliser une gouvernance qui reste encore absente dans la majorité des organisations. Le code généré par IA est traité comme une entrée non fiable, soumise aux mêmes analyses SAST, SCA et détection de secrets que le code humain, un changement de posture qui pourrait redéfinir les standards de l'industrie dans les prochains mois.

UECe cadre de gouvernance par niveaux de risque peut aider les entreprises européennes à structurer leur mise en conformité avec l'AI Act, qui impose une classification similaire des systèmes d'IA selon leur niveau de risque.

SécuritéOpinion
1 source
Quatre attaques sur la chaîne d'approvisionnement IA en 50 jours révèlent des failles dans les pipelines de déploiement
2VentureBeat AI 

Quatre attaques sur la chaîne d'approvisionnement IA en 50 jours révèlent des failles dans les pipelines de déploiement

En cinquante jours, quatre incidents de sécurité ont frappé les chaînes d'approvisionnement logicielle d'OpenAI, Anthropic et Meta, exposant un angle mort systémique dans l'écosystème IA. Le 11 mai 2026, un ver informatique baptisé Mini Shai-Hulud a publié 84 versions malveillantes de 42 packages npm de la bibliothèque TanStack en six minutes, en exploitant une mauvaise configuration de GitHub Actions, un empoisonnement du cache CI et l'extraction d'un token OIDC depuis la mémoire du runner. Ces packages portaient une provenance SLSA Build Level 3 valide car ils avaient été publiés depuis le dépôt officiel, via le bon workflow. Deux jours plus tard, OpenAI confirmait la compromission de deux appareils d'employés et l'exfiltration de secrets depuis ses dépôts internes, forçant la révocation de ses certificats macOS et une mise à jour obligatoire de tous les utilisateurs desktop avant le 12 juin 2026. En remontant à fin mars, on trouve deux autres incidents : un chercheur de BeyondTrust Phantom Labs, Tyler Jespersen, avait découvert que OpenAI Codex passait les noms de branches Git directement dans des commandes shell sans aucune validation, permettant l'injection de sous-commandes et le vol du token OAuth GitHub en clair. Simultanément, le groupe TeamPCP avait utilisé des identifiants volés au scanner de vulnérabilités Trivy d'Aqua Security pour publier deux versions empoisonnées du proxy LiteLLM sur PyPI, téléchargées près de 47 000 fois en quarante minutes avant quarantaine. Ce qui rend ces incidents particulièrement préoccupants, c'est leur portée transversale. L'attaque LiteLLM a atteint Mercor, une startup valorisée 10 milliards de dollars qui fournit des données d'entraînement à Meta, OpenAI et Anthropic : quatre téraoctets ont été exfiltrés, incluant des références à des méthodologies propriétaires de Meta. Le partenariat a été gelé immédiatement, une action collective a suivi dans les cinq jours. Aucune de ces attaques ne visait les modèles eux-mêmes, mais leurs dommages sont réels et mesurables. Le 31 mars, Anthropic avait de son côté exposé involontairement 513 000 lignes de TypeScript non obfusqué en livrant Claude Code version 2.1.88 avec un fichier source map de 59,8 Mo qui n'aurait jamais dû être inclus, révélant 44 feature flags internes, des prompts système et l'architecture d'orchestration multi-agents. Ces quatre incidents convergent vers un seul constat structurel : les pipelines de release, les hooks de dépendances, les runners CI et les gates de packaging ne sont couverts par aucun exercice de red team actuel dans l'industrie IA. Les évaluations AISI, les system cards et les audits de sécurité des modèles ignorent entièrement cette surface d'attaque. Quand un token OIDC légitimement émis suffit à publier 84 artefacts malveillants avec une provenance cryptographique valide, ou qu'une seule dépendance open source passe quarante minutes sur PyPI avec un effet blast radius cross-industriel, la robustesse du modèle sous-jacent devient hors-sujet. La pression monte pour que les fournisseurs IA intègrent des audits de sécurité de chaîne d'approvisionnement dans leurs questionnaires de conformité, au même titre que les évaluations de danger des modèles.

UELes organisations européennes déployant des outils IA via des dépendances open source (LiteLLM, TanStack) sont directement exposées aux mêmes vecteurs d'attaque, et la pression monte pour que les questionnaires de conformité AI Act intègrent des audits de sécurité de chaîne d'approvisionnement au même titre que les évaluations de risque des modèles.

💬 Quatre attaques en cinquante jours, aucune ne visait les modèles. Pendant qu'on red-teamait les LLMs à coups d'évaluations AISI et de system cards, personne ne regardait les runners CI, les hooks de dépendances, les gates de packaging, et un token OIDC légitime a suffi à publier 84 artefacts malveillants avec une provenance cryptographique valide. La robustesse du modèle, c'est hors-sujet si la chaîne de livraison est trouée.

SécuritéOpinion
1 source
Les agents IA prennent en charge davantage de tâches : la gouvernance devient une priorité
3AI News 

Les agents IA prennent en charge davantage de tâches : la gouvernance devient une priorité

Les agents d'intelligence artificielle capables d'agir de manière autonome se répandent rapidement dans les entreprises, mais les mécanismes de contrôle peinent à suivre le rythme. Selon une étude de Deloitte, 23 % des organisations ont déjà déployé des agents IA, et ce chiffre devrait atteindre 74 % d'ici deux ans. Pourtant, seulement 21 % déclarent disposer de garde-fous solides pour superviser leur comportement. Contrairement aux systèmes classiques qui se contentent de générer du texte ou des prédictions à partir d'une requête humaine, ces agents peuvent décomposer un objectif en étapes, prendre des décisions et interagir avec d'autres systèmes pour accomplir des tâches de bout en bout, sans intervention humaine à chaque étape. Deloitte travaille activement à aider les organisations à encadrer ces systèmes, en développant des cadres de gouvernance et des approches de conseil adaptés à cette nouvelle génération d'IA. L'enjeu central est que l'autonomie accrue des agents IA crée des risques inédits : un système qui agit seul peut emprunter des chemins imprévus, exploiter des données d'une manière non souhaitée, ou dériver progressivement de sa mission initiale au fil de ses interactions. Ces dérives sont difficiles à détecter et encore plus difficiles à corriger après coup. Pour y répondre, Deloitte préconise d'intégrer la gouvernance dès la conception, pas après le déploiement. Cela implique de définir dès le départ ce que le système est autorisé à faire, quelles données il peut utiliser, et comment il doit se comporter face à des situations ambiguës. Une fois en production, la surveillance en temps réel devient indispensable : si un agent se comporte de manière inattendue, les équipes doivent pouvoir intervenir immédiatement, suspendre certaines actions ou modifier les permissions à la volée. Dans les secteurs réglementés, cette traçabilité est aussi une obligation légale : chaque action doit être journalisée, chaque décision documentée. Cette tendance s'inscrit dans un mouvement plus large de professionnalisation de l'IA en entreprise. Pendant des années, les organisations ont déployé des outils d'IA relativement passifs, où un humain restait toujours dans la boucle décisionnelle. Le passage aux agents autonomes modifie fondamentalement cette équation et soulève une question de responsabilité : quand un système prend une mauvaise décision, qui en est comptable ? Deloitte illustre ces enjeux avec des cas concrets, comme des agents qui supervisent les performances d'équipements industriels sur plusieurs sites, détectent des signaux de défaillance via des capteurs et déclenchent automatiquement des procédures de maintenance. Ces usages montrent que la gouvernance n'est plus un sujet théorique réservé aux juristes, mais une condition opérationnelle pour que l'IA autonome puisse être déployée à grande échelle sans faire peser de risques incontrôlés sur les organisations.

UELes entreprises européennes dans les secteurs réglementés (finance, santé, industrie) sont directement concernées par ces obligations de traçabilité et de journalisation des décisions d'agents IA, qui recoupent les exigences de l'AI Act pour les systèmes à haut risque.

SécuritéActu
1 source
4AI News 

Les charges de travail edge IA en hausse imposent un renforcement de la gouvernance en entreprise

Google a publié Gemma 4, une famille de modèles d'intelligence artificielle à poids ouverts conçue pour fonctionner directement sur des appareils locaux, sans passer par le cloud. Sous licence Apache 2.0, ce modèle peut être téléchargé librement et exécuté sur un simple ordinateur portable d'entreprise. Google l'a accompagné de l'AI Edge Gallery et de la bibliothèque LiteRT-LM, qui optimisent drastiquement les vitesses d'inférence locale et permettent des comportements agentiques complexes : un agent Gemma 4 peut enchaîner des milliers d'étapes logiques, exécuter du code et traiter des données sensibles entièrement hors ligne, sans déclencher la moindre alerte sur les pare-feux cloud de l'entreprise. C'est précisément là que réside le problème pour les responsables de la sécurité informatique. Les grandes organisations ont investi massivement dans des architectures de contrôle centrées sur le réseau : courtiers d'accès cloud sécurisés, passerelles d'entreprise surveillant tout le trafic sortant vers des LLM externes. Ce dispositif repose sur un postulat simple : si les données ne quittent pas le réseau, elles restent protégées. Gemma 4 anéantit cette logique. Un ingénieur peut désormais ingérer des données internes classifiées, les traiter via un agent local, et produire des résultats sans qu'un seul octet ne transite par les systèmes de supervision. Les banques, qui ont dépensé des millions pour journaliser précisément leurs usages d'IA générative afin de satisfaire les régulateurs, risquent de se retrouver en violation de plusieurs cadres de conformité simultanément si des stratégies de trading algorithmique ou des protocoles d'évaluation des risques sont traités par un agent non surveillé. Les établissements de santé font face au même enjeu : le règlement HIPAA et les lois européennes de protection des données exigent une traçabilité complète du traitement des données patients, traçabilité impossible lorsque le modèle opère entièrement hors ligne. Ce basculement s'inscrit dans une tension structurelle que les chercheurs en sécurité appellent le "piège de gouvernance". Face à la perte de visibilité, les équipes dirigeantes répondent souvent par davantage de bureaucratie : comités d'architecture, formulaires de déploiement, processus d'approbation rallongés. Ces obstacles freinent rarement un développeur sous pression de livraison ; ils poussent simplement les pratiques dans l'ombre, alimentant un écosystème d'informatique fantôme animé par des logiciels autonomes. La montée en puissance des modèles edge comme Gemma 4 marque une rupture fondamentale avec l'ère des API centralisées : gouverner l'IA locale nécessite désormais des approches radicalement différentes, ancrées dans l'appareil lui-même plutôt que dans le réseau, à un moment où peu d'organisations disposent encore des outils pour y parvenir.

UELe RGPD et les réglementations sectorielles européennes (santé, finance) sont directement menacés par l'absence de traçabilité des traitements réalisés par des agents IA locaux, exposant les entreprises européennes à des violations de conformité simultanées.

💬 Toute la sécurité réseau des grandes boîtes reposait sur un postulat simple : si ça ne sort pas du réseau, c'est protégé. Gemma 4 rend ce raisonnement caduc d'un coup, et les équipes de conformité RGPD dans les banques et les hôpitaux vont avoir du mal à expliquer ça aux régulateurs. Bon, sur le papier elles ont des politiques d'usage, mais une politique ça n'arrête pas un dev qui veut juste finir sa feature avant vendredi.

SécuritéOpinion
1 source

Recevez l'essentiel de l'IA chaque jour

Une sélection éditoriale quotidienne, sans bruit. Directement dans votre boîte mail.

Recevez l'essentiel de l'IA chaque jour