Les attaques basées sur l'IA exigent une résilience des applications 

Ce que les RSSI et les responsables de la sécurité des applications devraient faire en tant qu'acteurs autonomes pour changer l'économie de l'exploitation 

L'IA ne crée pas une catégorie entièrement nouvelle de vulnérabilités applicatives. Elle rend les vulnérabilités connues plus faciles à détecter, à exploiter et à attaquer à grande échelle. La réponse en matière de sécurité doit donc évoluer au-delà des tests et correctifs périodiques vers une résilience applicative vérifiée en continu. 

Le chiffre qui devrait inquiéter tout RSSI 

En septembre 2026, Gambit Security a révélé une campagne active menée par un opérateur sinophone utilisant trois frameworks d'agents d'IA disponibles dans le commerce pour attaquer des sites de vente en ligne. En cinq jours, cet opérateur a lancé 105 attaques et compromis au moins 27 organisations à des degrés divers. Gambit a attribué plus de 600 000 enregistrements de cartes de paiement non expirées à deux victimes et a confirmé la présence de dispositifs de fraude à la carte bancaire sur plusieurs sites web. 

Le chiffre clé n'est pas seulement le volume de données volées, mais aussi leur coût. Les propres données de l'attaquant indiquent un coût moyen de 25.46 $ pour 101 analyses complètes, chaque cible ayant coûté entre 3.13 $ et 79.31 $. Cela bouleverse l'économie des attaques applicatives. Les sondages persistants, l'exploitation et l'adaptation ne nécessitent plus une équipe importante ni un budget conséquent. 

Les agents ont fait bien plus que simplement exécuter un scanner de vulnérabilités. Ils ont poursuivi des objectifs précis, modifié leurs tactiques et combiné les failles de sécurité. Un exemple documenté illustre la progression d'une injection SQL vers le contournement de l'authentification multifacteurs, l'accès administrateur, le téléchargement de fichiers arbitraires, l'exécution de code à distance, l'élévation de privilèges, l'extraction de clés secrètes cloud et l'accès à des bases de données de paiement. D'autres agents ont modifié du code JavaScript légitime, corrompu du contenu diffusé via un CDN et mis en place une persistance permettant de restaurer un skimmer malveillant après le redéploiement de l'application saine. 

Qu'est-ce qui a réellement changé ? 

Aucune de ces techniques n'est inédite. Injection SQL, divulgation de secrets, permissions excessives, etc.safe Le téléchargement de fichiers et la modification de code malveillant font partie du travail des défenseurs depuis des années. Ce qui a changé, c'est le mode opératoire des attaquants. 

• La vitesse: Les agents autonomes peuvent passer de la découverte à l'exploitation en quelques heures, réduisant ainsi le temps disponible pour enquêter et corriger la situation. 

• Échelle: Un même opérateur peut diriger des agents contre des dizaines, voire des centaines d'organisations simultanément. 

• Persistance: Les agents peuvent poursuivre l'analyse pendant des heures, en essayant des approches alternatives qu'un scanner conventionnel ou un attaquant opportuniste pourrait abandonner. 

• Adaptabilité: Les flux de travail automatisés peuvent interpréter les résultats, sélectionner la technique suivante et combiner les faiblesses en un chemin d'attaque différent d'une cible à l'autre. 

• Économie: Avec des dépenses de quelques dizaines de dollars par cible, même des organisations auparavant peu attrayantes peuvent être attaquées de manière rentable. 

Les programmes de sécurité conçus autour d'attaques menées au rythme humain, d'évaluations périodiques et de délais de correction se chiffrant en semaines sont désormais confrontés à un adversaire qui agit en continu et à la vitesse d'une machine. La détection et la correction des vulnérabilités demeurent essentielles, mais ne peuvent constituer l'unique ligne de défense. 

L'utilisation d'applications comme porte d'entrée vers des systèmes critiques n'est pas une simple hypothèse. Des campagnes menées sous la marque ShinyHunters ont eu recours au phishing vocal pour inciter des employés à autoriser des applications malveillantes connectées au sein d'environnements SaaS d'entreprise. Une fois approuvées, ces applications obtenaient des permissions OAuth permettant aux attaquants d'interroger et d'exfiltrer des données d'entreprise et, dans certains cas, d'accéder à d'autres services cloud connectés. Une application qui ne semblait pas essentielle à l'activité devenait ainsi une voie d'accès authentifiée à des données sensibles du système. 

Le déficit de résilience des applications 

Ensemble, ces campagnes démontrent que la surface d'attaque des applications ne se limite pas aux vulnérabilités logicielles individuelles. Elle englobe le code applicatif, le comportement à l'exécution, les identités, les intégrations, les permissions et les relations de confiance. Face à des attaques toujours plus rapides, moins coûteuses et adaptables, les organisations doivent vérifier en permanence que chacune de ces couches est capable de résister aux abus, de les détecter et de les contenir. 

Le Digital.ai L'approche de la résilience de l'IA part de ce constat. Il ne s'agit plus seulement de savoir si une application a réussi un test de sécurité avant sa mise en production, mais plutôt si elle peut continuer à protéger son code, sa logique, ses données et ses fonctions critiques lorsqu'elle est déployée dans un environnement non fiable et soumise à une analyse adaptative et continue. 

Pour les applications mobiles, OWASP MASVS-RESILIENCE offre une base techniquement fiable. Ce référentiel se concentre sur la résistance à la falsification, la rétro-ingénierie, l'analyse statique et l'analyse dynamique. L'IA ne rend pas ces objectifs obsolètes ; elle rehausse simplement le niveau d'exigence requis pour les atteindre. Les contrôles qui ralentissaient un analyste humain peuvent ne pas résister à un système automatisé capable de générer des scripts, de varier les techniques, d'interpréter les échecs et de poursuivre les essais. 

Que doivent faire les RSSI et les responsables de la sécurité des applications maintenant 

La réponse doit être pragmatique et progressive. Le plan à 30, 60 et 90 jours présenté ci-après vise à réduire l'exposition immédiate tout en créant un programme de résilience reproductible. 

Les 30 premiers jours permettent d'établir l'exposition et de valider les contrôles 

Identifier critique pour la sécurité applications et les vecteurs d'attaque. Cela doit inclure toute application, API, service, intégration, administration outil ou tiers composant avec un accès direct ou indirect aux données clients centressystèmes backend, données clients, identités privilégiées, déploiement pipelines ou plans de contrôle des nuages. 

Identifiez les applications prioritaires destinées aux clients et leurs vecteurs d'attaque. Commencez par les applications mobiles, web et de bureau accessibles aux clients, partenaires ou employés, en priorisant celles qui traitent des données sensibles ou qui offrent un accès direct ou indirect aux services backend, aux identités privilégiées ou aux plateformes de contrôle cloud. Suivez les API, les intégrations et les composants tiers présents sur ces vecteurs. Ensuite, suivez les chemins qu'ils empruntent pour accéder aux systèmes sensibles. Commencez par l'application.plicatioles services qui traitent les données client ou se connectent, directement ou indirectement, aux services backend, aux identités privilégiées, aux pipelines de déploiement ou cloud conavions de contrôle. Inclure les API et l'intégration.s, administrateuroutils et composants tiers tout au long de ce chemin 

Ne limitez pas l'inventaire aux applications générant directement des revenus, traitant des données sensibles ou considérées comme critiques. Une application apparemment sans grande valeur devient critique pour la sécurité lorsque ses autorisations, identifiants, connectivité ou confiance transitive permettent d'accéder indirectement à des systèmes à plus forte valeur ajoutée. 

Cartographiez la confiance transitive, les permissions héritées et les vecteurs potentiels de déplacement latéral. Pour chaque application, déterminez les données auxquelles un attaquant pourrait accéder après avoir obtenu l'exécution de code à distance (RCE) ou un accès administrateur. Dès lors, considérez toutes les données sensibles accessibles comme exposées. Désignez un responsable et assurez-vous que la surveillance permette de détecter toute modification non autorisée de code, de configuration ou de permissions. 

Testez sous 60 jours à la vitesse d'un attaquant et renforcez l'intégrité 

Intégrez les applications ayant des accès directs ou indirects aux systèmes critiques dans des tests de sécurité continus. Utilisez des exercices basés sur des scénarios qui enchaînent les vulnérabilités et poursuivent un objectif métier. Pour les applications déployées dans des environnements non fiables, validez les contrôles anti-falsification, d'intégrité de la plateforme, anti-analyse statique et anti-analyse dynamique par rapport aux techniques actuelles. Mesurez les délais de détection, de confinement et de correction vérifiée. 

Rendre la résilience opérationnelle dans les 90 jours 

Établissez un référentiel reproductible conforme aux exigences OWASP pertinentes. Suivez l'efficacité des contrôles dans le temps, et pas seulement leur présence. Intégrez la télémétrie de protection à la réponse aux incidents et mettez en pratique la restauration de l'application minimale viable et des services associés. 

Cinq questions à prendre en compte lors du prochain examen de sécurité 

1. Quelle application devons-nous évaluer et protéger en premier, en fonction de son accès direct ou indirect aux systèmes à forte valeur ajoutée, et quel est notre plan pour étendre cette protection à l'ensemble du parc applicatif ? 
2. Dans quel délai saurions-nous qu'un code d'application, un contrôle d'exécution ou une ressource livrée a été modifié ? 
3. Quelles protections ont été testées contre les flux de travail actuels assistés par l'IA plutôt que contre les seuls outils conventionnels ? 
4. Un attaquant peut-il extraire un secret, une règle métier ou un actif cryptographique d'une application distribuée et le réutiliser ailleurs ? 
5. Si un attaquant utilisant l'IA enchaînait plusieurs failles, nos protections applicatives pourraient-elles empêcher, retarder ou exposer les falsifications, les manipulations en cours d'exécution ou l'extraction d'actifs avant que l'application ne devienne une voie d'accès à des systèmes de plus grande valeur ? 

Mesurer l'efficacité plutôt que la mise en œuvre 

Une case à cocher peut confirmer l'existence d'un contrôle. Elle ne permet pas de savoir combien de temps ce contrôle reste actif, s'il détecte les manipulations ou si le contournement d'un mécanisme expose l'ensemble de l'application. Une évaluation de la résilience de l'IA doit donc mesurer les résultats observables : l'effort nécessaire pour comprendre le code protégé, modifier le comportement de l'application, intégrer des outils d'analyse, extraire les données sensibles et maintenir l'application opérationnelle après modification. 

C’est aussi pourquoi l’analyse comparative est essentielle. Tester un ensemble représentatif d’applications réelles selon une méthodologie cohérente permet de déterminer où les contrôles actuels restent efficaces et où les pratiques de référence du secteur sont dépassées par les attaquants. Répéter cette analyse comparative à mesure que les modèles et les outils évoluent transforme la résilience d’une simple affirmation ponctuelle en une preuve tangible. 

De la prise de conscience à l'action 

La leçon à tirer de cette campagne n'est pas que les entreprises de sécurité doivent se ruer sur chaque nouvel outil d'IA ou revoir leur stratégie de sécurité à la moindre information. Elle est que le rythme et les modalités d'exploitation des menaces ont profondément changé. Les organisations doivent s'attendre à davantage d'attaques, à une plus grande variété de menaces et à un délai plus court entre l'exposition et l'exploitation. 

Les RSSI et les responsables de la sécurité des applications ont désormais besoin de deux capacités complémentaires : des tests continus permettant de détecter les failles avant les attaquants, et la résilience des applications limitant les possibilités d’apprentissage, de modification ou d’exploitation par un attaquant lorsque la prévention s’avère insuffisante. Les organisations leaders seront celles qui pourront démontrer leur maîtrise de ces deux aspects, en apportant la preuve que leurs contrôles restent efficaces contre les outils actuellement utilisés par les attaquants. 

Références 

• Les agents d'IA autonomes de Gambit Security s'introduisent dans des centaines de sites de vente en ligne pour 25 dollars par cible. 

• Un pirate informatique sinophone, révélé par Quartz, a utilisé des agents d'IA pour infiltrer les systèmes de 100 entreprises. 

• Groupe de renseignement sur les menaces de Google : Le coût d’un appel, de l’hameçonnage vocal à l’extorsion de données 

• OWASP Mobile Application Security Norme de vérification