La sécurité de l’IA par l’obscurité est morte, et les défenseurs font face à un problème plus difficile

La sécurité de l’IA par l’obscurité s’est effondrée en 2026, alors que des agents trouvaient des failles négligées, accéléraient le développement d’exploits et atteignaient des systèmes protégés principalement par leur complexité spécialisée.

Les preuves immédiates couvrent des composants Windows oubliés, des bibliothèques open source largement examinées et des contrôleurs industriels assurant des services essentiels. Ces systèmes diffèrent techniquement, mais ils partageaient une défense discrète. Les attaquants avaient besoin d’une expertise rare, d’une patience considérable ou d’un intérêt économique suffisant pour les étudier.

La découverte de vulnérabilités par l’IA modifie ce calcul. Les modèles peuvent interpréter du code inconnu, expliquer des protocoles propriétaires, générer des bancs de test et automatiser la reconnaissance répétitive. Le résultat n’est pas un nouveau principe de sécurité. C’est la suppression des frictions qui permettaient aux organisations de différer l’application des anciens.

Cela crée un renversement difficile pour les défenseurs. Identifier les faiblesses devient moins coûteux et plus rapide, tandis que valider les correctifs, coordonner les divulgations, tester les systèmes opérationnels et modifier des pratiques de développement défaillantes restent des processus obstinément humains.

La question n’est plus de savoir si les faiblesses cachées finiront par émerger. Elle est de savoir si les défenseurs peuvent corriger les conditions qui les produisent avant que la découverte automatisée ne transforme chaque système négligé en cible rentable.

La sécurité de l’IA par l’obscurité a perdu son avantage économique

L’IA n’a pas réfuté la sécurité par l’obscurité. Elle a supprimé la pénurie de main-d’œuvre qui permettait aux organisations de prétendre que l’obscurité fonctionnait.

La sécurité par l’obscurité décrit une hypothèse de conception ou d’exploitation qui dépend du fait que l’architecture, les interfaces ou les faiblesses restent difficiles à découvrir. Elle n’a jamais été considérée comme un contrôle principal fiable. Pourtant, l’obscurité offrait encore une protection pratique lorsqu’étudier un système inconnu exigeait des spécialistes rares et des semaines de travail concentré.

Cette protection fonctionnait comme une barrière économique. Un composant vulnérable pouvait rester intact parce que les attaquants pouvaient gagner davantage en ciblant des logiciels familiers. Un protocole propriétaire pouvait décourager les intervenants externes parce que sa documentation était limitée. Un ancien sous-système pouvait échapper à l’examen parce que peu de chercheurs se souvenaient de son existence.

L’analyse de sécurité originale publiée le 13 septembre montre comment cet équilibre a changé. Les fournisseurs et chercheurs indépendants utilisent désormais des agents d’IA pour examiner des logiciels obscurs, anciens et déjà très étudiés. Les attaquants utilisent des capacités similaires pour analyser les correctifs et développer des exploits.

Brett Leatherman, directeur adjoint de la division cyber du FBI, a décrit des modèles découvrant des vulnérabilités importantes dans des composants open source que des communautés avaient examinés pendant une décennie. Certaines de ces bibliothèques fonctionneraient dans une part substantielle de l’infrastructure web.

Cela ne signifie pas que l’IA comprend indépendamment chaque système ou produit systématiquement un exploit fonctionnel. Cela signifie que les enquêteurs peuvent pénétrer un territoire inconnu sans partir de zéro. Un modèle peut résumer du code, traduire de la documentation, identifier des frontières de confiance probables et générer des scripts pour tester des hypothèses.

Les systèmes d’IA agentique étendent cette assistance à une séquence de tâches. Un agent peut inspecter des fichiers, exécuter des outils, examiner les résultats, réviser son approche et continuer jusqu’à atteindre un objectif défini. Les opérateurs humains fixent toujours les objectifs et fournissent l’infrastructure, mais la machine absorbe une grande partie du travail répétitif.

C’est pourquoi la découverte de vulnérabilités par l’IA met sous pression les logiciels fermés comme ouverts. Le code public facilite l’analyse directe, mais les logiciels fermés exposent toujours des binaires, des firmwares, des comportements réseau, de la documentation, des correctifs et des artefacts de configuration. Les modèles peuvent corréler ces fragments à une vitesse qui transforme l’économie de l’ingénierie inverse.

Dustin Childs, qui dirige la Zero Day Initiative de Trend Micro, a évoqué des technologies oubliées traitées lors de la publication record des correctifs Microsoft de septembre. Les composants concernés comprenaient un client Telnet, Windows RNDIS, NFS Portmapper et Link Layer Topology Discovery.

Leur ancienneté importe parce qu’elle illustre l’ancien compromis. Les composants hérités pouvaient survivre sans attention experte constante lorsque peu de personnes avaient l’intérêt ou les connaissances nécessaires pour les examiner. L’IA donne aux chercheurs curieux et aux attaquants un guide peu coûteux vers précisément ces domaines négligés.

L’obscurité ajoute toujours des difficultés. Un protocole non documenté peut ralentir un agent, et un appareil propriétaire peut limiter les éléments de preuve disponibles. Toutefois, la difficulté n’est ni une autorisation, ni une isolation, ni une authentification, ni une sûreté mémoire. On ne peut pas lui faire confiance pour arrêter une enquête automatisée persistante.

La barrière s’est donc déplacée du savoir caché vers des contrôles vérifiables. Les systèmes ont besoin de solides frontières d’identité, d’une exposition minimale, de paramètres sécurisés par défaut, d’une segmentation testée et de conceptions qui restent sûres lorsque leur fonctionnement devient connu.

C’est le principe de sécurité établi connu sous le nom de principe de Kerckhoffs, appliqué au-delà de la cryptographie. Un système doit rester sécurisé même lorsqu’un adversaire comprend son fonctionnement, à l’exception de secrets correctement gérés tels que des clés cryptographiques.

L’IA rend ce principe urgent sur le plan opérationnel. La documentation n’a plus besoin d’être soigneusement publiée pour que le comportement d’un système devienne compréhensible. Suffisamment d’éléments dispersés peuvent désormais donner à un agent une carte exploitable.

Le premier point de pression concerne les logiciels oubliés

Les systèmes soumis à la plus forte pression ne sont pas toujours les plus récents ou les plus précieux. Ce sont ceux dont la sécurité dépendait du fait que personne ne les examinait de près.

La recherche traditionnelle de vulnérabilités comporte des étapes coûteuses. Les chercheurs doivent apprendre à connaître une base de code, reproduire son environnement d’exploitation, comprendre ses hypothèses et séparer les faiblesses significatives des anomalies inoffensives. Ces étapes exigent souvent plus de temps que la découverte du code suspect elle-même.

L’IA peut en compresser plusieurs. Elle peut écrire des bancs de test, suivre les flux de données, comparer des implémentations liées et expliquer des schémas de programmation inconnus. Elle peut aussi poursuivre l’analyse lorsque la tâche devient répétitive, ce qui importe parce que l’attention humaine est limitée.

Cela ne garantit pas des résultats utiles. Les modèles produisent des faux positifs, comprennent mal le contexte et fabriquent parfois des explications techniques. Néanmoins, une assistance peu coûteuse permet aux opérateurs de tester davantage de cibles et d’abandonner les pistes improductives sans consommer autant de temps de spécialistes.

Cette recherche élargie modifie les logiciels qui deviennent attrayants. Les responsables d’anciennes bibliothèques, de produits d’entreprise de niche, de firmwares d’appareils et de services internes peu documentés ne peuvent plus supposer que les attaquants se concentreront ailleurs. Leur avantage lié à l’obscurité se réduit.

La même pression s’applique aux vulnérabilités connues en attente de déploiement. Lorsqu’un fournisseur publie un correctif, les attaquants peuvent comparer les versions corrigées et non corrigées. Ce processus, appelé patch diffing, révèle quel code a changé et aide les enquêteurs à reconstituer la faiblesse sous-jacente.

L’IA accélère le patch diffing en interprétant la modification, en proposant des entrées de déclenchement et en générant du code de test. Les recherches d’Anthropic sur le développement rapide d’exploits ont examiné comment des modèles pouvaient analyser des vulnérabilités récemment divulguées et faciliter leur exploitation avant que chaque organisation n’ait installé le correctif.

Cela réduit la fenêtre de correction, c’est-à-dire l’intervalle entre la disponibilité d’un correctif et sa réception effective par les utilisateurs. Cette fenêtre a toujours été dangereuse. L’analyse automatisée rend chaque heure qui s’y écoule plus précieuse pour les attaquants.

Une campagne récente impliquant un kit d’exploits fondé sur Chromium a démontré le risque opérationnel. Des groupes d’espionnage auraient utilisé des vulnérabilités après qu’un projet amont eut publié un correctif, mais avant que les versions stables en aval n’atteignent tous les utilisateurs. L’IA n’était pas nécessairement responsable de chaque partie de cette campagne, mais elle renforce la méthode qui rend ce calendrier efficace.

L’open source n’est pas voué à disparaître de manière unique dans ce modèle. L’examen public donne aux défenseurs accès au même code et permet une large collaboration. Le problème plus profond est l’exécution asymétrique. Les attaquants peuvent tester de nombreuses possibilités, tandis que les responsables doivent valider les signalements, éviter les régressions, coordonner les publications et accompagner les utilisateurs.

Les logiciels fermés font face à un problème similaire avec moins de visibilité publique. Un chercheur assisté par l’IA peut toujours examiner les binaires, les interfaces, le comportement des erreurs, les paquets de mise à jour, les applications mobiles et les firmwares d’appareils. Les fournisseurs ne peuvent pas supposer que l’absence de code source préserve durablement un mystère technique.

Les responsables font ainsi face à un problème croissant de traitement des signalements. Davantage de rapports générés par l’IA ne signifient pas automatiquement davantage de vulnérabilités confirmées. Certaines soumissions seront des doublons, des affirmations incomplètes ou des erreurs plausibles générées sans tests suffisants.

Ce flot peut mobiliser les mêmes experts nécessaires pour corriger les véritables faiblesses. Les petits projets open source sont particulièrement exposés, car un composant largement déployé peut ne compter que quelques responsables. La découverte automatisée peut évoluer indépendamment de leur capacité d’examen.

Les organisations doivent donc mesurer plus que le nombre de signalements. Parmi les indicateurs utiles figurent le temps nécessaire pour reproduire un problème, le temps nécessaire pour déterminer sa gravité, la part des découvertes en double, le temps de validation des correctifs et la récurrence par catégorie de vulnérabilité.

Ces mesures distinguent l’amélioration de la sécurité de la simple activité. Une équipe qui clôt des centaines de signalements à faible risque alors qu’une faille d’injection récurrente demeure dans son processus de développement court plus vite sans réduire son exposition future.

Les systèmes industriels perdent leur barrière de spécialistes

La technologie opérationnelle montre pourquoi l’effondrement de l’obscurité entraîne des conséquences qui dépassent la maintenance logicielle ordinaire.

La technologie opérationnelle, ou OT, contrôle des processus physiques tels que le traitement de l’eau, les lignes de production, la distribution de carburant et les équipements électriques. Les systèmes de contrôle industriel combinent souvent du matériel à longue durée de vie, des protocoles propriétaires, des logiciels d’ingénierie spécialisés et des exigences strictes de disponibilité.

Cet environnement a historiquement découragé de nombreux attaquants. Comprendre un automate programmable, ou PLC, exigeait une connaissance des processus industriels et des communications propres aux appareils. Tester une hypothèse pouvait aussi risquer d’interrompre des opérations physiques.

John Hultquist, analyste en chef du Google Threat Intelligence Group, a soutenu que les connaissances spécialisées fournissaient une grande partie de la protection pratique des systèmes industriels. L’IA facilite l’acquisition, l’organisation et l’application de ces connaissances.

Le risque est devenu concret en août, lorsque cinq agences américaines ont averti que des attaquants utilisaient des scripts assistés par l’IA contre des PLC Siemens S7 Series exposés à internet. Les environnements concernés comprenaient des installations d’eau, de fabrication, d’énergie, de chimie, d’agriculture et commerciales.

Selon l’alerte fédérale sur la menace, les opérateurs combinaient des bibliothèques publiques d’automatisation industrielle avec des assistants de codage IA. Leurs outils imitaient des logiciels de surveillance légitimes et interagissaient avec la mémoire des PLC, les données de configuration et la logique à relais.

La logique à relais est un langage de programmation graphique utilisé pour définir le comportement des contrôles industriels. Des modifications non autorisées peuvent affecter des équipements réels plutôt que de simplement modifier des informations affichées à l’écran.

L’activité signalée a réduit l’expertise nécessaire pour travailler avec le protocole S7comm utilisé par ces contrôleurs. L’IA pourrait aider des opérateurs à générer ou modifier des scripts à partir d’informations publiques. Elle n’a pas rendu un contrôleur isolé accessible, ni contourné tous les contrôles de sécurité correctement configurés.

L’exposition restait la condition facilitatrice. Les attaquants auraient recherché des PLC connectés à Internet, exécutant des logiciels obsolètes ou protégés par des identifiants par défaut. Une segmentation insuffisante offrait alors aux scripts générés un chemin vers des fonctions critiques.

Cette distinction est importante. Qualifier ces incidents d’« attaques par IA » peut détourner les organisations de contrôles qu’elles savent déjà mettre en œuvre. Supprimer l’accès direct à Internet, modifier les identifiants par défaut, appliquer les correctifs aux appareils pris en charge et séparer les réseaux d’ingénierie restent essentiels.

La sécurité par l’obscurité face à l’IA échoue le plus visiblement lorsque les organisations confondent méconnaissance et isolation. Un protocole rare n’empêche pas l’accès. Une interface d’ingénierie propriétaire n’authentifie pas son utilisateur. Une commande non documentée n’arrête pas un modèle entraîné à comparer des exemples et à tester des réponses.

Dans le même temps, les défenseurs ne peuvent pas corriger les environnements industriels comme des ordinateurs portables grand public. Les usines peuvent planifier leur maintenance plusieurs mois à l’avance. Les fournisseurs peuvent devoir certifier les modifications. Les anciens contrôleurs peuvent fonctionner pendant des décennies, et leur remplacement peut exiger d’importants travaux physiques.

La disponibilité crée également un dilemme de test. Une action défensive défaillante peut interrompre la production ou endommager les équipements. Les attaquants ont moins de raisons d’éviter les perturbations, tandis que les opérateurs doivent valider chaque changement au regard des contraintes de sécurité et d’exploitation.

Cette asymétrie explique pourquoi une meilleure détection seule ne suffit pas. Les propriétaires ont besoin d’inventaires précis des actifs, d’un accès distant contrôlé, d’une surveillance réseau et de chemins de communication imposés. Ils doivent identifier tout trafic vers un PLC provenant d’un poste de travail non dédié à l’ingénierie et enquêter sur les écritures effectuées en dehors des fenêtres de changement approuvées.

Une diode de données, qui n’autorise la circulation de l’information que dans un seul sens, peut protéger les environnements où la télémétrie doit sortir mais où les commandes ne doivent jamais revenir. Une segmentation forte peut limiter l’effet d’un poste de travail compromis ou d’un script généré.

Il s’agit de contrôles architecturaux, plutôt que de tentatives visant à dissimuler le système. Ils partent du principe que les attaquants comprennent l’équipement tout en leur refusant une voie exploitable.

La leçon s’étend aux logiciels d’entreprise. Un système ne devrait pas rester sûr uniquement parce que son API interne n’est pas documentée ou parce que son panneau d’administration utilise une adresse imprévisible. L’IA transforme progressivement ces obstacles en courtes tâches de recherche.

La découverte de vulnérabilités par l’IA dépasse les capacités de correction

Le compromis central en matière de sécurité n’oppose plus la découverte à l’ignorance. Il oppose la découverte à la vitesse des machines à une correction contrainte par les humains.

Katie Moussouris, fondatrice et PDG de Luta Security, a identifié le triage, la priorisation et la correction comme les véritables goulets d’étranglement. Découvrir davantage de faiblesses a une valeur limitée si les organisations ne peuvent pas déterminer lesquelles comptent ou éliminer leurs causes.

C’est là que les récits optimistes sur la découverte de vulnérabilités par l’IA deviennent incomplets. Un modèle qui produit dix fois plus de résultats plausibles peut aggraver la sécurité lorsque la file d’examen manque de preuves fiables, de tests reproductibles et d’une attribution claire des responsabilités.

Les défenseurs doivent répondre à plusieurs questions pour chaque rapport. Le comportement est-il réel ? Un attaquant peut-il l’atteindre ? Quels privilèges sont nécessaires ? L’exploitation franchit-elle une frontière de confiance importante ? La correction proposée perturbera-t-elle le comportement attendu ?

Les correctifs générés par l’IA semblent offrir une accélération équivalente. Un modèle peut inspecter du code vulnérable, suggérer une modification et générer des tests. Toutefois, les données actuelles montrent que la création de correctifs reste bien moins fiable que la détection de comportements suspects.

Une équipe de recherche de 1Password a évalué 6 080 correctifs générés pour six vulnérabilités récemment divulguées à l’aide de deux modèles de pointe. Seuls 26,0 % ont entièrement résolu la vulnérabilité sans modifier sensiblement le comportement de l’application.

20,1 % supplémentaires ont corrigé la vulnérabilité, mais ont modifié le fonctionnement de l’application. Plus grave encore, 53,9 % n’ont pas résolu la faiblesse, ont introduit une autre vulnérabilité, ou ont fait les deux, selon l’étude de validation des correctifs.

Ces résultats n’établissent pas un taux d’échec universel pour chaque modèle, langage ou vulnérabilité. Les chercheurs ont délibérément sélectionné des failles récentes et complexes nécessitant des réparations substantielles. Des défauts plus simples et des suites de tests plus robustes peuvent produire des résultats différents.

L’étude révèle néanmoins le déséquilibre central. Générer une modification de code convaincante est plus facile que prouver qu’elle préserve chaque propriété de sécurité et de fonctionnement importante.

Certaines corrections proposées bloquaient étroitement l’entrée connue de preuve de concept sans traiter la cause sous-jacente. Ce schéma peut produire un correctif qui réussit un test de base tout en restant vulnérable à des entrées alternatives.

Les correctifs générés par l’IA héritent également des faiblesses des environnements qui les évaluent. Une suite de tests incomplète ne peut pas confirmer un comportement qu’elle ne vérifie jamais. Un modèle peut optimiser son résultat pour réussir les tests visibles, même lorsque ces tests ne représentent qu’une fraction du contrat de sécurité.

Des recherches distinctes portant sur plus de 100 modèles et 80 tâches de programmation ont relevé un taux moyen de code sécurisé de 56 %. Ce résultat examinait le code généré plutôt que la correction de vulnérabilités, mais il renforce la nécessité d’une validation indépendante.

Les organisations devraient éviter d’interpréter ces chiffres comme la preuve que l’IA ne peut pas aider le travail défensif. Les modèles peuvent rédiger des modifications, générer des tests de régression, expliquer des fonctions peu familières et comparer des correctifs alternatifs. Ces usages peuvent réduire l’effort d’ingénierie lorsque les experts conservent l’autorité finale.

Le danger commence lorsque la vitesse devient la principale métrique de succès. Un correctif déployé rapidement mais sans validation adéquate peut conserver la faille initiale, en créer une nouvelle ou modifier silencieusement les règles d’accès.

L’automatisation défensive doit donc être ancrée dans l’exécution. Cela implique de compiler et d’exécuter les modifications proposées, de tester les propriétés de sécurité, de comparer les comportements et de rejeter les correctifs qui violent des invariants définis. Un invariant est une condition qui doit rester vraie dans toute implémentation acceptable.

L’examen humain reste nécessaire pour les systèmes à fort impact, car les tests ne capturent jamais l’ensemble du contexte opérationnel. Les ingénieurs doivent comprendre pourquoi la faiblesse existait, quelles hypothèses ont échoué et si du code connexe présente le même schéma.

C’est plus lent que de générer un correctif. C’est aussi le travail qui transforme un rapport de vulnérabilité en réduction durable du risque.

Davantage de résultats ne corrigeront pas des processus de sécurité défaillants

Les organisations qui répondent à l’IA par une file de correctifs plus longue resteront piégées, car le volume ne corrige pas le processus qui a produit les défauts.

Un programme de gestion des vulnérabilités peut sembler productif alors que le risque continue d’augmenter. Les équipes comptent les résultats critiques, les délais de clôture et le nombre total de correctifs, car ces chiffres sont faciles à recueillir. Ils révèlent une activité, mais pas toujours si le logiciel devient plus sûr.

Moussouris a averti que les organisations ne peuvent pas gagner en ajoutant indéfiniment des ressources à la découverte et à la correction individuelles. La réponse durable consiste à identifier les schémas et à modifier les systèmes qui créent des catégories récurrentes de vulnérabilités.

Supposons qu’un examen assisté par l’IA découvre des dizaines de failles d’injection. Corriger chaque occurrence est important, mais la plus grande opportunité se situe plus tôt dans le développement. Les équipes peuvent introduire des modèles plus sûrs, une gestion centralisée des entrées, des protections de framework et des tests qui empêchent le retour du même défaut.

C’est la différence entre traiter des résultats et améliorer un contrôle de sécurité. La première approche réduit l’exposition immédiate. La seconde modifie le rythme futur auquel cette exposition apparaît.

Les organisations devraient relier les données sur les vulnérabilités à la responsabilité du code, aux décisions d’architecture et aux normes de développement. Si un service produit à répétition des défaillances d’autorisation, la direction doit examiner son modèle d’accès plutôt que de célébrer une clôture plus rapide des tickets.

Le même raisonnement s’applique à l’infrastructure. Des résultats récurrents impliquant des interfaces administratives exposées signalent une défaillance de gestion des actifs ou de gouvernance réseau. Corriger un serveur sans corriger le modèle de déploiement laisse le mécanisme sous-jacent intact.

Une réponse mature à la sécurité par l’obscurité face à l’IA commence par un inventaire honnête. Les équipes doivent savoir quels composants sont déployés, qui les maintient, quelles interfaces sont accessibles et ce qui se passe lorsque le support prend fin.

Les nomenclatures logicielles peuvent aider à identifier les dépendances, mais un inventaire doit aller au-delà des noms de paquets. Les organisations ont également besoin des versions de firmware, des modèles d’appareils, des services cloud, des API internes, des autorisations héritées et des actifs de technologie opérationnelle.

Les systèmes de connaissance créent une autre forme de risque lié à l’obscurité. Les assistants IA peuvent faire ressortir des documents, messages, transcriptions et notes auxquels les employés étaient techniquement autorisés à accéder, mais qu’ils auraient rarement découverts manuellement.

Il ne s’agit pas nécessairement d’un contournement d’autorisation par l’IA. Cela peut révéler des autorisations qui ont toujours été trop étendues. L’IA réduit l’effort nécessaire pour trouver du contenu sensible dans le cadre de ces autorisations.

Les équipes qui adoptent la recherche d’entreprise ou des systèmes de récupération devraient examiner la propriété des contenus, la conservation, l’héritage des accès et les limites d’indexation avant un déploiement à grande échelle. Une base de connaissances IA bien conçue devrait préserver les autorisations de la source au lieu de considérer toutes les informations indexées comme également disponibles.

Cela exige également une journalisation rigoureuse. Les équipes de sécurité ont besoin de traces indiquant à quoi un agent a accédé, quels outils il a invoqués, quelles modifications il a proposées et qui a approuvé les actions conséquentes. Sans ces éléments, les workflows automatisés deviennent plus difficiles à examiner que les systèmes hérités qu’ils remplacent.

La réforme des processus devrait inclure des exigences strictes de soumission pour les rapports de vulnérabilités générés par l’IA. Les soumissions devraient identifier les versions affectées, décrire la frontière de confiance, fournir des étapes de reproduction et distinguer le comportement observé des spéculations générées par le modèle.

Les responsables de maintenance peuvent alors utiliser l’automatisation pour regrouper les doublons, vérifier les détails environnementaux et prioriser les résultats dont l’impact est démontré. L’objectif n’est pas de rejeter la recherche assistée par l’IA. Il est d’exiger des preuves évoluant à l’échelle du volume des affirmations.

Les équipes chargées des achats ont également un rôle à jouer. Les acheteurs devraient demander aux fournisseurs comment ils testent les correctifs générés par des agents, gèrent les composants hérités, traitent la divulgation coordonnée et mesurent les catégories de vulnérabilités récurrentes. Une promesse d’« utiliser l’IA pour la sécurité » offre peu de garanties sans ces précisions.

La vision sceptique reste importante. Les modèles actuels sont incohérents et les démonstrations impressionnantes utilisent souvent des environnements sélectionnés. Certains résultats de l’IA exigent d’importantes corrections humaines, tandis que l’exploitation entièrement autonome reste moins fréquente que le scripting et la reconnaissance assistés.

Toutefois, cette incohérence ne rétablit pas l’ancien fossé défensif. Un attaquant n’a pas besoin que chaque tentative fonctionne. Des essais parallèles peu coûteux peuvent rendre un faible taux de réussite opérationnellement utile, en particulier contre de nombreuses cibles similaires.

Les défenseurs doivent planifier en fonction de cette économie. Ils devraient supposer que le code, les binaires, les configurations et les correctifs accessibles feront l’objet d’un examen automatisé. Leur avantage doit provenir d’une conception plus sûre et d’une réponse vérifiée plus rapide, et non de l’espoir que cet examen échoue.

Trois signaux montreront si les défenseurs peuvent rattraper leur retard

La prochaine phase sera déterminée par la vérification des correctifs, l’exposition des infrastructures critiques et la capacité des organisations à prévenir les failles récurrentes plutôt qu’à les compter.

Le premier signal est la fiabilité mesurée des correctifs générés par l’IA. Les futures évaluations devraient tester des vulnérabilités récemment divulguées, préserver un comportement applicatif réaliste et publier des méthodes reproductibles. Une hausse du taux de correctifs complets réduirait l’écart actuel entre découverte et remédiation.

Le résultat important n’est pas de savoir si un correctif compile. Les chercheurs doivent vérifier s’il élimine la cause profonde, évite d’introduire de nouvelles faiblesses et préserve le comportement attendu. Des améliorations qui résistent à une évaluation indépendante renforceraient l’argument en faveur d’une automatisation défensive supervisée.

Si les taux d’échec restent proches de leur niveau actuel, cela appuierait une conclusion plus prudente. L’IA continuerait d’accroître le volume de découvertes, tandis que la validation par des experts demeurerait la ressource limitante.

Le deuxième signal concerne l’exposition des contrôleurs industriels et d’autres systèmes anciens. Les agences et opérateurs devraient suivre la diminution des PLC accessibles sur Internet, la disparition des identifiants par défaut et la détection par les organisations de trafic non autorisé lié aux protocoles industriels.

Une nouvelle vague d’attaques assistées par l’IA contre des contrôleurs exposés renforcerait le jugement central. Elle montrerait que les attaquants transforment à répétition des connaissances publiques en outils opérationnels contre des systèmes toujours protégés par une architecture faible.

Une réduction durable de l’exposition affaiblirait la prévision la plus alarmante. Elle ne rétablirait pas l’obscurité, mais démontrerait que l’isolation de base et la gestion des actifs peuvent priver les agents d’une voie d’attaque concrète.

Le troisième signal est la manière dont les organisations de sécurité mesurent les progrès. Une équipe qui se concentre uniquement sur le nombre de découvertes et le délai médian de clôture aura du mal à suivre la multiplication des rapports automatisés. Une équipe qui suit les catégories de défauts récurrentes, les actifs exposés, les causes profondes et les remédiations validées peut réduire la demande future.

Surveillez les éditeurs et les grands projets logiciels qui publient ces indicateurs plus approfondis. Des preuves montrant le déclin des défauts d’injection, d’autorisation, de sûreté mémoire ou de configuration suggéreraient que les changements de processus fonctionnent.

Si les totaux de divulgations continuent de battre des records tandis que les mêmes catégories de défauts réapparaissent, les défenseurs resteront sur ce que Moussouris a décrit comme un tapis roulant. Une découverte plus rapide révélera davantage de risques sans changer la mécanique qui les produit.

La réponse pratique commence dès maintenant. Recensez les systèmes oubliés, supprimez les expositions inutiles, testez les limites d’autorisation et exigez des preuves pour chaque affirmation de sécurité automatisée. Utilisez les agents pour assister les chercheurs et les ingénieurs, mais maintenez les réparations conséquentes derrière des tests reproductibles et une revue responsable.

La sécurité de l’IA par l’obscurité est déjà une position perdante, car cette ancienne défense reposait sur une curiosité rare et un travail spécialisé. Tous deux deviennent disponibles sous forme de services logiciels.

La tâche plus difficile consiste à bâtir des systèmes qui restent sûrs une fois leurs détails devenus compréhensibles. Quelle dépendance cachée, autorisation héritée ou contrôleur exposé votre organisation souhaiterait le moins voir examinés aujourd’hui par un agent IA ?