Pourquoi l’IA augmente les coûts de remédiation en cybersécurité

La cybersécurité par IA crée un nouveau défi de remédiation pour les entreprises

Les outils de cybersécurité alimentée par l’IA peuvent multiplier par huit le nombre d’alertes de vulnérabilité. Pour les grandes entreprises, cela crée un problème : les équipes de sécurité peuvent découvrir des faiblesses bien plus vite que leurs organisations ne peuvent les examiner et les corriger. La technologie peut fonctionner exactement comme prévu pendant que l’entreprise accumule davantage de constats de sécurité non résolus que ses équipes actuelles ne peuvent en traiter.

La pression augmente parce que les attaquants utilisent eux aussi l’IA pour aller plus vite. L’analyse de Bain estime que le temps nécessaire pour une cyberattaque typique est passé d’environ quatre semaines à près de 18 heures. Les entreprises font donc face à deux évolutions simultanées : les attaques s’accélèrent, tandis que des défenses plus performantes révèlent des faiblesses qui nécessitent un travail d’ingénierie.

Les organisations les plus avancées réagissent déjà avec des budgets de remédiation plus importants, des changements dans les effectifs de sécurité et une implication accrue des développeurs. La remédiation consiste à corriger une vulnérabilité ou à réduire le risque qu’elle crée. À mesure que l’IA augmente le volume des constats, ce travail dépend davantage de la capacité d’ingénierie, de l’architecture technologique et des relations avec les fournisseurs.

Bain, qui fournit des services de conseil et d’accompagnement en cybersécurité et a donc un intérêt commercial dans l’investissement des entreprises en sécurité, soutient que les entreprises doivent changer leur manière de gérer ces responsabilités. Son analyse pointe vers une évolution plus large des dépenses de cybersécurité, avec une plus grande importance accordée aux ressources et aux décisions nécessaires pour éliminer les faiblesses découvertes.

L’IA détecte les vulnérabilités plus vite que les entreprises ne peuvent les corriger

Selon Bain, les grandes entreprises qui déploient une IA de pointe pour renforcer leurs défenses de cybersécurité ont vu le volume des alertes de vulnérabilité augmenter jusqu’à huit fois. Chaque constat peut nécessiter une validation, une évaluation, une attribution à une équipe responsable et une action corrective. Lorsque la détection va plus vite que ces activités, les constats non résolus s’accumulent.

Une hausse du nombre d’alertes peut refléter une meilleure visibilité sur des faiblesses déjà existantes. Les équipes de sécurité prennent connaissance de vulnérabilités que les outils précédents n’avaient pas détectées, ce qui leur donne davantage d’occasions de prévenir les attaques. Mais ces informations ne deviennent utiles que lorsque les organisations peuvent identifier les constats les plus dangereux et les traiter avant que les attaquants ne les exploitent.

Le temps disponible pour réagir se réduit à mesure que l’IA transforme la cybersécurité offensive. Des attaquants disposant de compétences limitées en programmation peuvent désormais mener des opérations avec un niveau de sophistication auparavant associé à des capacités étatiques. Les attaquants expérimentés peuvent compresser en quelques heures des campagnes qui prenaient autrefois des semaines, tandis que l’automatisation permet aux opérations de fraude de fonctionner 24 heures sur 24.

L’IA rend également plus efficaces des méthodes d’attaque déjà établies. Les campagnes de phishing peuvent générer à grande échelle des messages hautement personnalisés, y compris des messages utilisant des codes QR pour diriger les victimes vers des destinations malveillantes. Le clonage vocal et l’usurpation vidéo en temps réel créent d’autres moyens de tromper les employés et de compromettre les processus métier. Des incidents très médiatisés impliquant des tests de modèles d’IA de pointe ont en outre démontré la pression exercée sur des défenses qui reposent sur des temps de réponse humains.

Au-delà de ces attaques, des agents IA de plus en plus autonomes introduisent une autre catégorie de risque. Ces systèmes logiciels peuvent poursuivre des objectifs et entreprendre des actions avec une implication humaine limitée, créant des possibilités de comportements inappropriés même lorsque les objectifs qui leur sont assignés sont légitimes. Les processus de sécurité traditionnels peuvent avoir du mal à anticiper chaque action qu’un agent pourrait entreprendre ou les conséquences qui en découlent.

Des attaques plus rapides et l’extension des charges de travail liées à l’IA rendent un scan défensif efficace de plus en plus important. Pourtant, une détection plus large crée aussi davantage de travail pour les personnes chargées de corriger les vulnérabilités. Les entreprises ont besoin d’un moyen de distinguer les constats qui exigent une action immédiate de ceux qui peuvent attendre.

Un scan complet exige une priorisation fondée sur le risque

Une réponse possible à la surcharge d’alertes consisterait à scanner moins de systèmes. Cela réduirait le nombre de constats que les équipes doivent traiter, mais laisserait aussi d’importantes faiblesses non découvertes. Selon les conclusions mises en avant par Bain, plus de la moitié des vulnérabilités d’une organisation existent en dehors de ses applications critiques.

Concentrer les scans sur les applications les plus précieuses pourrait donc laisser de côté une majorité de vulnérabilités. Les attaquants peuvent exploiter des faiblesses dans l’infrastructure de support et les systèmes connectés, même lorsque ces systèmes sont considérés comme moins importants pour l’activité. Les entreprises ont besoin d’une couverture sur les plateformes legacy, les interfaces de programmation d’applications (API), les systèmes d’authentification, l’infrastructure et les dépendances logicielles.

Les connexions entre ces systèmes rendent une visibilité large particulièrement importante. Une faiblesse dans un système d’authentification peut exposer plusieurs services, tandis qu’une API vulnérable peut donner accès à des informations sensibles ou à des fonctions au sein d’une application critique. Une infrastructure plus ancienne peut aussi rester connectée à des applications modernes longtemps après que sa finalité métier d’origine a changé.

À mesure que les applications et les dépendances évoluent, le scan doit se poursuivre dans l’ensemble de l’environnement. Une couverture plus large produit des constats que les analystes sécurité doivent valider, évaluer et attribuer aux propriétaires des systèmes. L’IA peut accélérer la détection, mais les décisions qui suivent exigent toujours une expertise en sécurité et une connaissance des systèmes concernés.

Les organisations les plus avancées traitent cette charge de travail en évaluant les vulnérabilités selon quatre critères liés :

Ces critères aident les équipes de sécurité à décider quelles corrections réduiront l’exposition la plus importante. Une vulnérabilité présentant une gravité théorique élevée peut être moins urgente si les attaquants ne peuvent pas atteindre de manière réaliste le composant concerné. Une autre faiblesse peut exiger une attention immédiate parce qu’elle est facile à exploiter et donne accès à plusieurs services importants.

Les dépendances systémiques peuvent rendre des composants apparemment mineurs particulièrement critiques. Un composant logiciel partagé peut prendre en charge plusieurs applications, de sorte que sa compromission pourrait perturber plusieurs processus métier. Le périmètre d’impact décrit l’étendue de ces dommages potentiels, aidant les équipes à comprendre comment une attaque pourrait affecter des systèmes au-delà du composant vulnérable.

La priorisation change aussi la manière dont les organisations interprètent leur backlog de vulnérabilités, c’est-à-dire l’ensemble des constats en attente de remédiation. Compter les alertes non résolues mesure la charge de travail, mais ce nombre à lui seul ne peut pas montrer le niveau d’exposition porté par l’entreprise. Des milliers de constats à faible impact peuvent exiger une réponse différente d’un groupe plus restreint de vulnérabilités que les attaquants peuvent facilement exploiter dans une infrastructure critique.

Le scan large et la priorisation fondée sur le risque fonctionnent ensemble. Le scan établit où se trouvent les faiblesses, tandis que la priorisation détermine lesquelles doivent recevoir en premier des ressources de remédiation limitées. Une fois ces décisions prises, l’organisation a encore besoin de personnes disposant de l’autorité technique et du temps nécessaire pour effectuer les corrections.

La charge de travail de remédiation modifie les effectifs de sécurité et les priorités d’ingénierie

Ce travail supplémentaire affecte déjà les budgets de cybersécurité. Bain indique que les grandes entreprises qui font progresser leurs capacités de sécurité activées par l’IA ont généralement augmenté leurs dépenses de remédiation de pourcentages à deux chiffres. Ces hausses reflètent les efforts humains et techniques nécessaires pour transformer des volumes plus importants de constats en corrections effectivement réalisées.

Cette hausse des dépenses découle du travail à accomplir. Les équipes de sécurité doivent examiner les constats, identifier les propriétaires des systèmes, coordonner les changements et confirmer que les vulnérabilités ont été résolues. Les organisations qui adoptent des capacités de scan plus performantes doivent donc budgéter le travail généré par une meilleure détection, en plus de la technologie elle-même.

Selon Bain, certaines grandes entreprises ont réagi en réaffectant jusqu’à 20 % à 25 % de leur personnel de cybersécurité d’autres responsabilités vers la remédiation des vulnérabilités identifiées par des scans alimentés par l’IA. Elles ont fait appel à des partenaires externes pour maintenir les opérations de sécurité courantes. Cela permet aux spécialistes internes de se concentrer sur les nouveaux constats pendant que les activités établies de surveillance et de défense se poursuivent.

Déplacer jusqu’à un quart de la main-d’œuvre cybersécurité change le fonctionnement du département. Les employés de la sécurité prennent déjà en charge la réponse aux incidents, la surveillance, la gouvernance et d’autres responsabilités défensives. Les réaffecter crée un déficit de capacité dans ces activités, de sorte que le soutien externe devient une partie du coût de l’extension de la remédiation.

D’autres organisations augmentent leurs effectifs dédiés. Bain décrit une grande entreprise qui a triplé la taille de son équipe de remédiation pour gérer le travail supplémentaire. Une équipe plus importante peut examiner davantage de constats, coordonner les corrections et gérer des cas complexes, mais son efficacité dépend toujours de la capacité des personnes qui contrôlent les systèmes concernés à mettre en œuvre les changements.

Pour les vulnérabilités applicatives, cette responsabilité incombe souvent aux développeurs logiciels. Les ingénieurs infrastructure peuvent devoir mettre à jour des configurations, tandis que les équipes DevOps, chargées de relier le développement logiciel au déploiement et aux opérations, doivent aider à tester et à mettre en production les changements. Ces équipes ont aussi des engagements liés aux nouvelles fonctionnalités, à la fiabilité des services et à la maintenance courante.

La capacité de remédiation dépend donc des plannings d’ingénierie. Une équipe de sécurité peut identifier une vulnérabilité critique et établir son urgence, mais la faiblesse peut rester non résolue si les ingénieurs responsables ne peuvent pas dégager le temps nécessaire pour la corriger. Ajouter des analystes sécurité aura un effet limité lorsque la contrainte se situe dans les équipes de développement ou d’infrastructure.

Certaines grandes entreprises font de la réduction des vulnérabilités une responsabilité d’ingénierie plus explicite. Dans une organisation citée par Bain, son chief information security officer (CISO) a décrit une application plus stricte d’une directive interne existante exigeant des développeurs qu’ils consacrent environ 30 % de leur temps à une gestion proactive des vulnérabilités. Cette directive réserve de la capacité d’ingénierie à l’identification et à la correction des faiblesses avant qu’elles ne deviennent des incidents urgents.

Cette allocation est propre à l’organisation, et le bon équilibre dépend des exigences technologiques et opérationnelles de chaque entreprise. La décision plus large consiste à traiter la gestion des vulnérabilités comme un travail d’ingénierie planifié. Les développeurs disposent de temps pour maintenir la sécurité des systèmes qu’ils construisent, tandis que les managers de l’ingénierie doivent tenir compte de la remédiation lorsqu’ils attribuent d’autres tâches.

L’implication des développeurs est particulièrement importante lorsque les vulnérabilités proviennent de la conception des applications ou des dépendances logicielles. Les spécialistes de la sécurité peuvent établir le risque, mais les développeurs comprennent souvent quelles corrections sont techniquement faisables et comment elles affectent les fonctionnalités existantes. Leur participation permet de traiter les faiblesses dans le cadre des processus réguliers de développement et de maintenance.

Les équipes DevOps font face à un défi connexe lorsque les correctifs doivent atteindre la production. Un changement de code terminé peut encore nécessiter des tests, une planification du déploiement et une coordination avec d’autres services. Les organisations les plus avancées travaillent donc à accélérer le déploiement des correctifs critiques, en réduisant le délai entre l’identification d’une exposition urgente et la correction du système concerné.

Un déploiement plus rapide exige une responsabilité claire tout au long du processus. Les équipes de sécurité établissent l’urgence, les développeurs et les spécialistes de l’infrastructure préparent les corrections, et les équipes opérationnelles gèrent leur mise en production. Lorsque les responsabilités sont floues ou que la capacité d’ingénierie n’est pas disponible, les constats peuvent rester non résolus même après que les changements techniques requis sont compris.

L’automatisation peut alléger une partie de cette charge de travail. Les organisations les plus avancées commencent à automatiser les tâches de remédiation les plus simples tout en conservant une supervision humaine. Les corrections répétitives et bien comprises sont de bons candidats, car l’automatisation peut réduire l’effort manuel et libérer les spécialistes pour qu’ils se concentrent sur des vulnérabilités plus complexes.

Les changements automatisés nécessitent toujours des garde-fous, car les corrections peuvent affecter les applications et l’infrastructure de production. Un correctif techniquement valide peut introduire des problèmes de compatibilité ou perturber des services dépendants. Les organisations doivent donc déterminer quels changements peuvent être effectués automatiquement et lesquels exigent une revue humaine avant le déploiement.

Ces réponses traitent différentes limites de la capacité de remédiation. Les équipes dédiées augmentent le nombre de constats pouvant être traités, tandis que l’automatisation réduit le travail répétitif. L’implication des développeurs et des équipes DevOps permet des corrections dans les applications et l’infrastructure, et les partenaires externes aident à maintenir les opérations de sécurité courantes lorsque le personnel interne est réaffecté.

La contrainte suivante apparaît lorsqu’une organisation dispose de suffisamment de personnes pour effectuer une correction mais ne contrôle pas suffisamment la technologie concernée. Certains systèmes sont difficiles à modifier en toute sécurité, tandis que d’autres appartiennent à des fournisseurs. Ces faiblesses exigent des décisions différentes de celles liées aux effectifs et aux améliorations de processus utilisées pour gérer la remédiation courante.

Les technologies legacy et les fournisseurs externes créent des problèmes de remédiation plus difficiles

L’analyse de Bain identifie les plateformes legacy, l’infrastructure réseau et les fournisseurs de software-as-a-service (SaaS) parmi les expositions de sécurité liées à l’IA les plus concentrées et les plus difficiles à corriger. Ces domaines posent des défis parce que les organisations peuvent se heurter à des obstacles techniques ou dépendre d’entreprises externes pour effectuer les corrections.

L’analyse compare les catégories technologiques selon leur concentration de risque et la capacité des organisations à résoudre les faiblesses identifiées. Elle prend également en compte le nombre de CISO interrogés ayant sélectionné chaque catégorie comme leur exposition non résolue la plus significative.

La comparaison couvre six domaines :

Dans l’évaluation de Bain, les plateformes legacy, la couche réseau et les fournisseurs de logiciels externes combinent un risque concentré avec un contrôle limité sur la remédiation. Ils représentent également les groupes les plus importants de CISO les identifiant comme leur exposition non résolue la plus matérielle.

Les plateformes cloud-native modernes, conçues pour fonctionner à l’aide d’infrastructures et de services cloud, se situent à l’opposé de cette comparaison. Bain les place dans une position relativement favorable en matière de concentration du risque et de difficulté de remédiation, avec le plus petit groupe de CISO les sélectionnant comme leur exposition non résolue la plus significative. Le code interne et les dépendances open-source présentent des arbitrages différents en matière de contrôle direct, de compatibilité et de maintenance.

Ces différences comptent parce que la remédiation dépend de l’architecture et de la propriété de la technologie concernée. Une entreprise peut planifier des changements sur les logiciels qu’elle développe en interne, à condition que les ingénieurs disposent d’une capacité suffisante. Une infrastructure legacy peut être beaucoup plus difficile à modifier, tandis que les systèmes contrôlés par des fournisseurs exigent la coopération d’organisations extérieures à l’entreprise.

Les systèmes legacy transforment la dette technique en exposition de sécurité

Les plateformes legacy montrent comment l’architecture technologique peut limiter la remédiation. Les entreprises continuent souvent à exploiter des systèmes plus anciens parce que des applications et des processus métier importants en dépendent. L’application de correctifs devient difficile lorsque le logiciel est fragile, complexe ou connecté à des composants qui ne sont plus maintenus.

Lorsqu’une correction immédiate est impraticable, les organisations peuvent mettre en place des protections techniques temporaires pour réduire l’exposition. Ces mesures peuvent limiter la probabilité ou les conséquences d’une exploitation pendant que les équipes étudient des options à plus long terme. Mais un recours répété à des protections temporaires permet aux faiblesses sous-jacentes de persister.

Bain soutient donc que la dette technique accumulée doit être traitée comme une exposition active de cybersécurité. La dette technique désigne les coûts futurs de maintenance et de changement créés par des décisions technologiques antérieures, y compris la dépendance continue à des systèmes vieillissants. Lorsque ces systèmes deviennent difficiles à sécuriser, cette dette crée aussi des problèmes pour la remédiation des vulnérabilités.

Réduire cette exposition peut exiger de retirer ou de remplacer une technologie qui ne peut plus être corrigée de manière durable. De telles décisions impliquent souvent des investissements importants parce que les plateformes concernées soutiennent des opérations métier essentielles. Les équipes de sécurité peuvent identifier le risque, mais les dirigeants responsables des budgets technologiques et de la continuité d’activité doivent autoriser les changements nécessaires.

L’infrastructure réseau crée une autre forme d’exposition concentrée. Les composants réseau relient les applications, les utilisateurs et les services, de sorte que des faiblesses peuvent affecter plusieurs systèmes à la fois. Les corriger peut exiger des changements aux conséquences opérationnelles larges, rendant les tests et le déploiement plus complexes que pour la correction d’une application isolée.

Pour les plateformes legacy comme pour l’infrastructure réseau, la flexibilité technique influe sur la rapidité avec laquelle l’organisation peut réagir. Du personnel de remédiation supplémentaire peut examiner les faiblesses et préparer des changements, mais c’est l’architecture sous-jacente qui détermine dans quelle mesure ces changements peuvent être mis en œuvre en toute sécurité.

Les logiciels contrôlés par les fournisseurs exigent une supervision continue

Les fournisseurs externes créent une limite différente parce que l’entreprise peut avoir peu d’autorité directe sur la technologie vulnérable. Des plateformes SaaS critiques peuvent être profondément intégrées aux processus internes, aux systèmes d’identité et aux informations sensibles. Pourtant, le fournisseur contrôle une grande partie du logiciel et de l’infrastructure sous-jacents.

Lorsqu’une faiblesse provient de cet environnement, le client dépend du fournisseur pour enquêter et mettre en œuvre une correction. L’entreprise peut évaluer les conséquences et demander une action, mais sa capacité à éliminer la vulnérabilité peut dépendre des priorités et de la capacité technique du fournisseur.

L’IA rend cette relation plus difficile à gérer. Les fournisseurs peuvent publier quotidiennement des changements sur les modèles et les logiciels, alors que de nombreux processus de supervision des entreprises reposent encore sur des questionnaires et des évaluations périodiques. Une revue réalisée au début d’un contrat peut devenir obsolète à mesure qu’un fournisseur introduit de nouvelles fonctionnalités ou modifie le fonctionnement de ses systèmes.

De nouvelles capacités d’IA peuvent aussi modifier l’exposition de l’entreprise au cours d’une relation fournisseur existante. Un fournisseur peut changer la manière dont les informations sont traitées, introduire des connexions à des systèmes supplémentaires ou dépendre de nouveaux services externes. Ces changements peuvent affecter les exigences de sécurité même lorsque le produit et le contrat d’origine restent en place.

Les relations de quatrième partie ajoutent une couche supplémentaire de dépendance. Une quatrième partie est un fournisseur utilisé par l’un des propres fournisseurs de l’entreprise. Ces entreprises peuvent fournir des technologies ou des services essentiels au produit sous contrat, créant une exposition de sécurité même en l’absence de relation contractuelle directe avec l’entreprise.

La gestion de ces dépendances exige une meilleure visibilité sur la manière dont les fournisseurs opèrent et modifient leurs systèmes. Les entreprises ont besoin d’une évaluation continue pour les fournisseurs étroitement intégrés aux opérations métier, appuyée par des exigences contractuelles qui rendent visibles les changements pertinents.

Bain recommande des mécanismes contractuels plus solides, notamment une notification rapide des violations de sécurité et des changements technologiques significatifs. Les accords peuvent aussi exiger une approbation préalable avant que les fournisseurs n’introduisent de nouveaux déploiements d’IA, lorsque cela est approprié, et prévoir des pénalités en cas de violations contractuelles.

Ces exigences font de la gouvernance des fournisseurs une responsabilité continue. Les équipes achats, technologie, sécurité et juridiques doivent se coordonner lorsqu’un fournisseur modifie ses systèmes pendant un contrat en cours. Elles ont également besoin d’informations suffisantes sur les relations de quatrième partie pour identifier l’origine possible d’expositions significatives.

Les agents IA ajoutent de nouvelles exigences à la gouvernance de la sécurité

Les problèmes de visibilité et de propriété observés dans les relations fournisseurs s’appliquent aussi aux agents IA opérant au sein des entreprises. Les agents sont des systèmes logiciels qui utilisent l’IA pour exécuter des tâches et entreprendre des actions avec des degrés variables d’indépendance. À mesure que les entreprises introduisent davantage d’agents et de charges de travail liées à l’IA, elles créent des autorisations supplémentaires, des connexions système et de nouvelles responsabilités de sécurité.

De nombreuses organisations ont déjà du mal à établir combien d’agents elles exploitent, qui en est responsable et quelles actions ces agents sont autorisés à effectuer. Certaines ne disposent pas non plus de moyens fiables pour désactiver un agent lorsque son comportement devient dangereux. Ces lacunes compliquent la surveillance et la réponse aux incidents, car les équipes de sécurité doivent savoir quels systèmes existent avant de pouvoir les contrôler de manière cohérente.

Le risque devient plus complexe lorsque les agents interagissent avec des applications, l’infrastructure et des services externes. Leurs autorisations déterminent les ressources auxquelles ils peuvent accéder, tandis que leur configuration influence les actions qu’ils peuvent entreprendre. Des contrôles faibles peuvent permettre à un agent de se comporter de manière inappropriée tout en poursuivant une tâche par ailleurs légitime.

La gestion de ces systèmes exige que les entreprises découvrent leurs charges de travail IA et leurs agents, renforcent leurs configurations et surveillent leur comportement. Les processus de sécurité doivent aussi prendre en charge la détection des menaces et la réponse aux incidents lorsqu’un agent crée ou rencontre un problème de sécurité.

Les contrôles de gouvernance, de gestion des risques et de conformité doivent tenir compte des actions que les agents sont autorisés à effectuer. Une responsabilité claire établit qui approuve les autorisations, examine les comportements et répond aux incidents. Des mécanismes d’arrêt fiables donnent aux organisations un moyen de stopper une activité dangereuse lorsque la surveillance et l’intervention normales sont insuffisantes.

Certaines entreprises ont retardé ces efforts en attendant que les fournisseurs proposent des solutions complètes. Bain préconise au contraire de combiner des contrôles développés en interne, des technologies achetées et des partenariats externes. Cette approche permet aux entreprises de traiter les faiblesses immédiates de gouvernance tout en adaptant leurs systèmes à mesure que les capacités de sécurité de l’IA se développent.

La même flexibilité compte pour les systèmes legacy, l’infrastructure et les relations fournisseurs. Les équipes de sécurité ont besoin de visibilité sur les faiblesses, mais l’organisation doit aussi avoir l’autorité nécessaire pour modifier les systèmes, restreindre les agents et exiger des actions des fournisseurs. Lorsque les budgets sont limités, que les plateformes sont difficiles à modifier ou que le levier contractuel est faible, des vulnérabilités non résolues peuvent persister malgré des outils de détection de plus en plus performants.

Ces contraintes font entrer la remédiation en cybersécurité dans des décisions contrôlées par les dirigeants technologiques et la direction métier. Un département sécurité peut identifier l’exposition et recommander une action corrective, mais remplacer une infrastructure, allouer du temps d’ingénierie et renégocier des accords fournisseurs exigent une autorité plus large.

L’investissement en cybersécurité IA exige une responsabilité au niveau de la direction

Lorsque la remédiation dépend des plannings d’ingénierie, des investissements d’infrastructure et des décisions des fournisseurs, la responsabilité doit s’étendre aux dirigeants qui contrôlent ces ressources. Bain recommande de tenir les directeurs des systèmes d’information (DSI) et les chief technology officers (CTO) responsables de la dette de vulnérabilité accumulée aux côtés de la direction de la cybersécurité. La dette de vulnérabilité est l’ensemble des faiblesses non résolues qui continuent d’exposer une organisation à un risque de sécurité.

Cette approche change la manière dont la responsabilité est répartie. Les CISO identifient les risques, établissent les exigences de sécurité et communiquent les priorités. Les DSI, les CTO et les responsables de l’ingénierie doivent s’assurer que les équipes responsables des systèmes concernés disposent des ressources et de l’autorité nécessaires pour mettre en œuvre les corrections.

Pour une entreprise confrontée à un backlog de vulnérabilités critiques, la première question de management est de savoir pourquoi ces faiblesses restent non résolues. Certaines peuvent nécessiter du personnel de remédiation supplémentaire ou un déploiement plus rapide des correctifs. D’autres dépendent de travaux de développement, du remplacement d’infrastructure ou d’une intervention auprès d’un fournisseur externe.

La responsabilité de la direction consiste à prendre les décisions nécessaires pour lever ces obstacles. Un CISO peut établir qu’une plateforme legacy présente une exposition inacceptable, mais le DSI ou le CTO peut contrôler le budget et les ressources techniques nécessaires pour la remplacer. De même, les responsables de l’ingénierie déterminent si les développeurs peuvent consacrer suffisamment de temps à une remédiation urgente.

La supervision du conseil d’administration doit refléter ces responsabilités. Certaines organisations de premier plan ont déjà augmenté la fréquence des reportings de cybersécurité, et Bain recommande des rapports détaillés sur les vulnérabilités au moins une fois par mois, voire chaque semaine. Un accès direct du CISO au conseil peut aider à faire remonter aux personnes capables d’autoriser une action corrective les expositions graves non résolues et les contraintes de ressources.

Des reportings plus fréquents sont utiles lorsqu’ils relient les constats de sécurité aux décisions opérationnelles. Les conseils d’administration doivent comprendre quelles vulnérabilités significatives restent ouvertes, comment la remédiation progresse et si les correctifs critiques atteignent la production assez rapidement. Les rapports doivent aussi identifier les pénuries de ressources et les faiblesses qui exigent une intervention de la direction.

Ces mesures aident à distinguer une meilleure détection d’un véritable progrès dans la réduction de l’exposition. Une augmentation des vulnérabilités découvertes peut indiquer que la couverture de scan s’est élargie. En revanche, une concentration persistante de constats non résolus à haut risque peut signaler une capacité d’ingénierie insuffisante, des dépendances technologiques difficiles ou des retards dans les décisions de management.

Le reporting au conseil doit donc donner aux dirigeants suffisamment d’informations pour agir sur les causes de l’exposition non résolue. Lorsque la remédiation exige du personnel supplémentaire, des investissements d’infrastructure ou une intervention auprès d’un fournisseur, la décision pertinente doit être visible aux côtés du risque de sécurité qu’elle traite.

La gouvernance doit aussi suivre le rythme des évolutions de la technologie IA. Les logiciels des fournisseurs peuvent être mis à jour fréquemment, les agents peuvent recevoir des autorisations supplémentaires et de nouvelles vulnérabilités peuvent apparaître dans des systèmes connectés. Des processus de supervision reposant principalement sur des revues peu fréquentes peuvent avoir du mal à réagir avant que ces changements n’affectent la sécurité de l’entreprise.

L’évaluation continue des fournisseurs et le contrôle des changements contractuels deviennent par conséquent des responsabilités de la direction. Les organisations ont besoin d’une autorité claire pour évaluer les nouveaux déploiements d’IA par les fournisseurs, réagir aux changements significatifs pendant les contrats et faire remonter les préoccupations lorsque les fournisseurs ne respectent pas les exigences de sécurité convenues.

La planification des investissements doit tenir compte des mêmes réalités opérationnelles. Bain recommande de traiter la modernisation de la cybersécurité par l’IA comme un engagement pluriannuel qui équilibre les dépenses technologiques avec du personnel qualifié et des ressources opérationnelles. Les capacités de scan, l’automatisation, la participation de l’ingénierie et le soutien externe influencent tous la rapidité avec laquelle une entreprise peut résoudre les vulnérabilités qu’elle découvre.

Cet engagement crée aussi une décision de calendrier. Développer des processus de remédiation, réallouer de la capacité d’ingénierie, renforcer les accords fournisseurs et améliorer la gouvernance demandent un effort organisationnel. Bain avertit que chaque mois de préparation retardée donne aux concurrents un temps supplémentaire pour renforcer leurs défenses.

Les entreprises qui commencent ces changements plus tôt peuvent mettre en place les dispositifs de staffing, les processus d’ingénierie et les contrôles de management nécessaires pour utiliser efficacement des outils de sécurité IA plus performants. Pour les dirigeants, le défi d’investissement immédiat consiste à déterminer quelle charge de travail supplémentaire de remédiation l’organisation peut absorber, qui l’exécutera et quelles contraintes structurelles exigent des décisions financées avant la prochaine hausse de la découverte de vulnérabilités.

Réflexions finales

Les outils de cybersécurité alimentés par l’IA modifient l’économie de la sécurité des entreprises. Les organisations peuvent désormais identifier des vulnérabilités à un rythme qui dépasse souvent leur capacité à les corriger. Pour les dirigeants, le défi ne consiste plus simplement à améliorer la détection des menaces. Il s’agit de s’assurer que les investissements dans la sécurité IA se traduisent par des réductions mesurables de l’exposition.

Cela exige de traiter la remédiation comme une priorité métier et technologique plutôt que comme une responsabilité confinée aux équipes de sécurité. Les DSI et les CTO doivent prendre en compte la capacité d’ingénierie, les investissements d’infrastructure et les relations fournisseurs nécessaires pour résoudre les vulnérabilités. Les CISO doivent établir des priorités claires en fonction de l’exploitabilité, de l’impact métier et des conséquences du maintien de faiblesses non résolues.

Les implications financières vont au-delà des budgets de cybersécurité. Un scan plus complet peut accroître la demande en développeurs, spécialistes de l’infrastructure, partenaires externes et modernisation technologique. Les dirigeants doivent décider où des dépenses supplémentaires réduiront le plus grand risque et où les modèles opérationnels existants doivent évoluer.

Pour les conseils d’administration et la direction générale, la mesure la plus utile des progrès n’est pas le nombre de vulnérabilités découvertes par les outils d’IA, mais l’efficacité avec laquelle l’organisation réduit ses expositions les plus significatives. Cela signifie suivre les délais de remédiation, attribuer clairement les responsabilités et traiter les contraintes techniques et organisationnelles qui empêchent les corrections critiques.

À mesure que l’IA accélère à la fois les attaques et les capacités défensives, l’écart entre la découverte des vulnérabilités et leur remédiation deviendra un indicateur de plus en plus important de la préparation des entreprises en matière de sécurité. Les organisations qui alignent les capacités de détection sur les ressources d’ingénierie, la responsabilité de la direction et un investissement soutenu seront mieux placées pour transformer les dépenses en cybersécurité IA en une réduction significative du risque.