L’innovation ne réduit pas les exigences de sécurité : elle les renforce

Les technologies et les services externes entrent dans les entreprises plus vite que les moyens de vérifier ce qu’ils exposent réellement. Michael Zanetta et Florent Truphème, de la société suisse Bugscale, expliquent comment la sécurité offensive évolue face à la multiplication des dépendances, à l’essor de l’intelligence artificielle et aux risques que celle-ci introduit.

Spécialisée en sécurité offensive, Bugscale attaque les systèmes de ses clients pour en révéler les faiblesses avant qu’elles ne soient exploitées. Son approche associe revue de code et tests dynamiques afin de mettre au jour les vulnérabilités et les scénarios de compromission possibles. Indépendante de tout éditeur, elle ne revend aucune solution et recommande des mesures en fonction des risques constatés.

Michael Zanetta
CEO – chercheur en sécurité

Florent Truphème
COO – ingénieur sécurité

Michael Zanetta, Florent Truphème, qu’est-ce qui a changé dans l’exposition des entreprises ces dernières années ?

Les systèmes d’information deviennent plus performants, mais plus complexes. Une application ne repose plus seulement sur le code interne : elle s’appuie sur des composants open source, des services cloud, des fournisseurs, des API et, désormais, des solutions d’intelligence artificielle. Cette évolution multiplie les dépendances et élargit la surface d’attaque. La difficulté majeure est d’identifier les vecteurs de compromission propres à chaque composant et de repérer le moment où l’exposition change.

Face à cette complexité, quelles approches de test privilégiez-vous ?

Cela dépend de ce que l’on cherche à savoir. Pour évaluer la sécurité intrinsèque d’une application, nous privilégions une approche dite « white box », avec accès au code et aux informations d’architecture. À budget égal, elle concentre l’effort sur les scénarios de risque plutôt que sur la redécouverte d’informations que le client possède déjà. Une approche « black box » répond à un autre objectif : mesurer ce qu’un attaquant sans connaissance préalable peut découvrir et exploiter dans un temps donné. Tester la détection et la réaction à une intrusion répond à un troisième objectif : mettre principalement les équipes de défense à l’épreuve.

Nous collaborons aussi directement avec les équipes de développement tout au long de l’évaluation. Cette proximité améliore notre compréhension de l’architecture et des processus métiers, et nos tests gagnent ainsi en précision. Par ailleurs, discuter des techniques d’attaque et des faiblesses observées dans leur propre environnement rend la sensibilisation des développeurs plus tangible.

Pourquoi la chaîne d’approvisionnement logicielle (supply chain) est-elle devenue un sujet central ?

Sécuriser son propre code ne suffit plus. Il faut aussi protéger les environnements de développement, les chaînes d’intégration et de déploiement, les dépendances, les registres de composants et les services tiers : une entreprise dépend aujourd’hui d’un vaste écosystème. C’est précisément cette réalité qu’exploitent les attaques visant la supply chain. Une PME qui met un service en ligne s’appuie souvent sur les mêmes composants et services tiers qu’un grand groupe : elle peut donc hériter des mêmes faiblesses, sans disposer des mêmes moyens pour les identifier et les corriger.

Plus les systèmes deviennent complexes, plus les fondamentaux deviennent indispensables. Maîtriser les dépendances, protéger les comptes et les secrets de développement, limiter les privilèges et sécuriser les processus de livraison permettent déjà de prévenir de nombreuses attaques ou d’en réduire l’impact. C’est dans cet esprit que nous avons publié un guide open source sur la supply chain. Il traduit ces principes en mesures concrètes, classées par niveau de maturité : par exemple, différer de quelques jours l’adoption d’une nouvelle version lorsqu’il ne s’agit pas d’un correctif de sécurité, afin de laisser le temps à une éventuelle compromission d’être détectée.

Comment l’IA transforme-t-elle les activités de sécurité offensive ?

Ce qui change, c’est l’échelle de ce que l’on peut explorer, pas ce qu’il faut démontrer. L’IA peut analyser de grands volumes d’informations, explorer davantage de scénarios et automatiser certaines tâches. Elle peut ainsi améliorer la couverture d’une évaluation et laisser davantage de temps aux experts pour comprendre l’architecture, raisonner comme un attaquant et enchaîner plusieurs faiblesses jusqu’à un impact réel.

Mais il ne suffit pas de demander à une IA de « tester un environnement » pour obtenir un test d’intrusion. Une démonstration ponctuelle, même impressionnante, ne constitue pas une méthodologie. Un constat doit rester vérifiable et reproductible. L’intégration de l’IA exige donc un travail d’ingénierie : identifier les cas d’usage pertinents, définir les mécanismes de validation, mesurer les faux positifs comme les faux négatifs et encadrer l’autonomie.

Nous introduisons l’IA de manière progressive et contrôlée : nos missions impliquent des informations sensibles, ce qui impose un cadre permettant de maîtriser les flux de données et de protéger les infrastructures mobilisées. Toute utilisation dans une mission est soumise à l’accord explicite du client. Nous adaptons nos méthodes à ses règles et contraintes, et non l’inverse.

À quels risques s’expose concrètement une entreprise qui connecte l’IA à ses données ?

Les entreprises ne déploient plus seulement des assistants qui répondent à des questions : elles connectent des modèles à leurs données internes et à leurs applications métiers. Un assistant conversationnel peut ainsi consulter la documentation interne et déclencher une action dans un outil métier, sans pour autant être présenté comme un agent autonome. Un attaquant peut manipuler directement ses instructions, mais aussi dissimuler des consignes malveillantes dans un document ou une source externe que l’assistant sera amené à consulter. Nous observons fréquemment des intégrations dans lesquelles un tel détournement suffit à exposer des données auxquelles l’utilisateur ne devrait pas avoir accès ou à déclencher une action qu’il n’a jamais demandée.

La vulnérabilité ne réside pas nécessairement dans le modèle lui-même. Elle peut apparaître dans la manière dont l’application récupère les données, gère les autorisations ou pilote les outils. Les risques changent selon que le modèle répond seul, consulte des données ou agit via des outils. Leur évaluation exige donc une expertise et des méthodologies qui dépassent le cadre d’un test d’intrusion traditionnel.

Comment l’AI Red Teaming permet-il d’évaluer ces risques ?

Le terme est un peu trompeur : l’AI Red Teaming consiste à tester la sécurité des solutions d’intelligence artificielle elles-mêmes. Il ne s’agit pas d’utiliser l’IA pour réaliser un test d’intrusion, mais de confronter ces solutions à des scénarios d’attaque adaptés à leur architecture et à leurs usages. Une évaluation sérieuse va bien au-delà de quelques questions piégeuses posées à un modèle.

Dans la majorité de nos tests, les garde-fous autour du modèle constituent la principale mesure de sécurité en place et nous finissons régulièrement par les contourner. Lorsque ce contournement ouvre l’accès à des données ou à des actions sensibles, il révèle généralement des défauts de contrôle d’accès, de limitation des privilèges ou de cloisonnement des données dans les composants situés derrière. Ce sont des manquements aux principes de sécurité les plus classiques. Un garde-fou réduit le risque, mais il ne doit pas constituer la seule barrière.

C’est pourquoi ce travail exige de comprendre l’architecture complète et, au regard des processus métiers, ce qu’un détournement permettrait réellement de faire. Il demande une double compétence : maîtriser la sécurité applicative et les tests d’intrusion, mais aussi comprendre les mécanismes propres aux modèles, aux systèmes documentaires et aux outils connectés. Nous l’avons construite en partant de la sécurité applicative, avec des spécialistes du code et des architectures qui montent en compétence sur l’IA plutôt que des spécialistes de l’IA qui découvrent la sécurité. Une telle évaluation peut commencer dès la conception par une revue d’architecture, puis se poursuivre par des tests adversariaux avant la mise en service et après les évolutions significatives.

Comment les entreprises peuvent-elles déployer l’intelligence artificielle sans compromettre leur sécurité ?

L’enjeu est d’ajuster le niveau d’exigence aux usages et aux risques. Traiter la sécurité tôt évite des reprises coûteuses en fin de projet, et il est souvent plus simple de restreindre ce qu’une solution a le droit de faire que de la protéger contre tout. Quand l’accès aux données repose sur un seul filtre, sa défaillance suffit à tout ouvrir. Des protections complémentaires permettent au système de rester résilient lorsqu’une première barrière cède.

Une évaluation reste datée. Les modèles, les données et les intégrations évoluent vite : une solution jugée sûre il y a six mois ne l’est pas nécessairement aujourd’hui. La confiance ne se décrète pas. Elle se démontre.

Plus d‘informations sur
bugscale.ch