La norme « zéro CVE » est irréaliste et trompeuse.
L’idée d’atteindre zéro CVE (Common Vulnerabilities and Exposures) dans vos systèmes relève de la fiction. Ce n’est pas seulement difficile, c’est structurellement impossible à quelque échelle que ce soit. Et même si vous y parveniez pour un moment, vous investiriez des ressources dans le mauvais combat.
Le fait d’insister sur l’absence de CVE oblige souvent les équipes à précipiter les mises à jour ou à mettre à niveau les composants, simplement pour avoir l’esprit tranquille. Ce comportement brise plus de choses qu’il n’en corrige. Le nouveau code ne se contente pas de corriger les vulnérabilités, il en introduit de nouvelles, introduit des bogues, provoque des régressions et nécessite une reconfiguration. Ainsi, en recherchant le zéro CVE, les organisations échangent une forme de risque contre plusieurs autres.
La sécurité doit être stratégique. Prétendre que les logiciels sont exempts de vulnérabilités conduit à la complaisance. Le vrai risque est de penser que vous êtes en sécurité alors que ce n’est pas le cas. L’ennemi, ce ne sont pas les failles connues de votre base de code, ce sont les lacunes que vous ignorez et qui sont dissimulées par le statut « sécurisé » trompeur de votre tableau de bord.
La leçon à retenir pour les dirigeants est simple : ne gérez pas en fonction de paramètres qui semblent bons dans les feuilles de calcul, mais qui échouent dans le monde réel. Les logiciels comporteront toujours des risques. L’accent doit être mis sur la gestion de l’exposition, la minimisation des surfaces d’attaque et la résilience de vos systèmes.
En 2023, environ 30 000 CVE ont été enregistrés. En 2024, ce nombre est passé à près de 40 000. Cette croissance n’est pas due à la dégradation des logiciels, mais à l’augmentation du nombre de développeurs, d’outils (y compris l’IA) et de la surveillance. Ainsi, à mesure que la surface d’attaque s’étend, l’idée de « zéro » s’éloigne de plus en plus de la réalité. Ne restez pas bloqué dans la mauvaise bataille.
L’explosion du nombre de CVE signalés est due à des facteurs systémiques qui touchent l’ensemble du secteur.
L’augmentation du nombre de CVE n’est pas un signe d’effondrement du monde numérique. C’est le signe que les systèmes deviennent plus complexes et que l’environnement des rapports de sécurité évolue rapidement. Nous ne sommes pas confrontés à une augmentation des risques catastrophiques. Nous sommes confrontés à une explosion du volume, de la complexité et de la visibilité.
Qu’est-ce qui explique ce phénomène ? C’est simple : de plus en plus de code est écrit par de plus en plus de personnes. La génération de code à l’aide de l’IA accélère encore ce phénomène. Dans le même temps, la structure incitative autour de la découverte de vulnérabilités est inclinée. Les chercheurs en sécurité, les étudiants et même les fournisseurs sont encouragés, d’un point de vue économique, académique ou réputationnel, à trouver et à publier des faiblesses. Cela gonfle le nombre de vulnérabilités et fausse le signal.
Les sociétés d’analyse de la sécurité ajoutent du bruit. Elles se font concurrence sur la base de ce qu’elles peuvent détecter, et pas nécessairement sur la gravité du risque. Résultat : Les alertes CVE mettent souvent en évidence des failles non pertinentes ou inexploitables, car on a l’impression que « plus de détection » équivaut à « un meilleur produit ». En réalité, elles détournent les décideurs et les équipes de sécurité des menaces crédibles.
Cet environnement crée une sorte de boucle de rétroaction. Les outils d’intelligence artificielle facilitent la détection des failles mineures. Celles-ci sont enregistrées et comptabilisées. Les fournisseurs s’efforcent d’apporter des correctifs à ces drapeaux pour maintenir des tableaux de bord propres. Pendant ce temps, la véritable résilience du système est reléguée au second plan.
En tant que dirigeant, ce qui compte, c’est de se concentrer sur les vulnérabilités qui comptent vraiment, sur les systèmes qu’elles affectent et sur les dommages potentiels qu’elles peuvent causer. Le nombre de CVE n’est pas la menace. Le traiter comme si elle l’était fait perdre du temps et de l’argent, et ne vous rapproche pas de la sécurité.
Tous les CVE ne représentent pas des risques significatifs ; c’est le contexte qui détermine leur impact.
Tous les CVE ne sont pas des problèmes qui méritent d’être résolus. Traiter toutes les vulnérabilités sur un pied d’égalité n’est pas stratégique, c’est inefficace. L’ordre de priorité est primordial. Un problème de faible gravité enfoui dans un système verrouillé par des couches de contrôle d’accès ne présente pas le même risque qu’une faille exploitable à distance dans une application critique. Mais si votre processus de sécurité les traite de la même manière, vous affectez mal vos ressources.
L’état d’esprit figé selon lequel « chaque CVE doit être corrigé » crée un fardeau inutile. De nombreuses CVE ne peuvent même pas être exploitées dans des conditions normales. D’autres présentent un risque si faible que l’application d’un correctif introduit en fait plus de complexité que de les laisser en l’état. Le contexte est important. Vous devez comprendre la fonction du code associé à la CVE : s’agit-il d’une bibliothèque, d’un programme shell ou d’un service de longue durée tel qu’un démon ? Chaque code se comporte différemment et présente un profil de sécurité différent.
Les contrôles compensatoires peuvent réduire ou neutraliser le risque lié à un CVE. Il peut s’agir de la configuration du système, du contrôle d’accès, de l’isolation des processus ou des protections d’exécution. Une CVE qui semble urgente sur le papier peut devenir sans importance dans la pratique lorsque ces contrôles sont en place.
Si vous êtes en position de leadership, la clé est la suivante : exigez le contexte. N’acceptez pas les rapports de vulnérabilité qui ne sont pas liés à la fonction de l’entreprise, à l’utilisation opérationnelle et à l’exploitabilité. Ne laissez pas vos équipes perdre des cycles à corriger des problèmes parasites alors qu’elles pourraient renforcer des cibles réelles. La sécurité doit être basée sur l’exposition et les conséquences, et pas seulement sur le volume de détection.
Le suivi des CVE n’a pas permis d’éviter des vulnérabilités graves telles que l’incident log4j.
Log4j a prouvé ce que beaucoup soupçonnaient déjà, à savoir que les systèmes CVE bien connus ne détectent pas tout. CVE-2021-44228, le problème de Log4j, n’a été découvert qu’en 2021, alors que le code affecté était disponible depuis 2013. Près d’une décennie s’est écoulée, et aucun fournisseur, aucun scanner, aucun processus ne l’a détecté. Le problème était critique, répandu et facilement exploitable une fois exposé. Mais jusqu’à ce moment-là, tout le monde avait des tableaux de bord « conformes » et faisait confiance à ses outils d’analyse. C’est là le problème.
Une vulnérabilité cachée à la vue de tous peut faire plus de dégâts qu’une douzaine de CVE de faible gravité réunis. Log4j n’a pas été oublié parce qu’il était obscur, mais parce que les cultures basées sur l’analyse s’intéressent à ce qui est signalé et non à ce qui pourrait mal tourner. Le système CVE n’a pas échoué à étiqueter le bogue, il a échoué à le trouver.
Il s’agit de rappeler que « connu » n’est pas synonyme d' »exhaustif ». Vos systèmes contiennent des vulnérabilités qui ne figurent dans aucune base de données. Zéro CVE sur le papier ne signifie pas risque zéro, mais simplement que personne n’a encore trouvé la faille. La leçon à retenir est simple : ne confondez pas visibilité et sécurité.
Pour les dirigeants, il est risqué de faire confiance au processus plutôt qu’aux résultats. Les tableaux de bord indiquant que « tout va bien » reposent souvent sur des hypothèses que les vrais attaquants ne partagent pas. La cybersécurité ne consiste pas à trouver ce qui est facile, mais à se préparer à ce qui est possible. Le retard de Log4j a mis en évidence un angle mort que la complaisance a laissé se développer.
Cette vulnérabilité montre que l’attention doit toujours aller au-delà de ce qui est actuellement documenté. Le leadership stratégique implique de poser des questions plus difficiles : Que manquons-nous d’autre ? Qu’est-ce que nous ne signalons pas ? Dans quelle mesure sommes-nous réellement exposés et quelles sont les mesures d’atténuation existantes au cas où quelque chose de plus grave passerait à nouveau inaperçu ?
En bref, si votre programme de sécurité n’a pas détecté Log4j, il n’était pas non plus prêt pour ce qui va suivre.
La défense en profondeur est une stratégie de sécurité plus efficace que celle qui consiste à se concentrer uniquement sur la remédiation des CVE à l’aide de correctifs.
La chasse à chaque CVE sans stratégie défensive plus large ne sécurisera pas vos systèmes. Les risques ne disparaissent pas simplement parce que vous déployez un correctif. Si un attaquant parvient à passer, la question à laquelle vous devez répondre est la suivante : qu’est-ce qui est en place pour l’empêcher de faire des dégâts ?
La défense en profondeur apporte cette réponse. Il s’agit de superposer des protections à travers votre infrastructure, en veillant à ce qu’aucune défaillance ne conduise à une compromission totale du système. Cela inclut des binaires renforcés, l’application de règles d’exécution, des protections au niveau du noyau comme SELinux, et des architectures de système où les services sont segmentés, et non pas empilés inutilement dans un seul conteneur ou serveur. Ces contrôles réduisent l’impact d’une vulnérabilité, même si elle n’a pas encore été corrigée.
Nous avons déjà pu constater l’efficacité de ce système dans le monde réel. Lorsque CVE-2019-5736, une vulnérabilité de conteneur potentiellement compromettante pour le système, a fait surface, certains environnements ont été protégés simplement parce que SELinux a bloqué le chemin de l’exploit. Pas de cycle de correctifs urgent. Pas d’exercice d’évacuation. Protection, par conception.
Les dirigeants doivent comprendre la différence entre la correction des vulnérabilités et leur neutralisation. Les systèmes correctement configurés ne s’appuient pas uniquement sur les listes CVE. Ils garantissent que les politiques, l’architecture et les protections d’exécution empêchent réellement les mauvais résultats. Si un correctif n’est pas appliqué rapidement, le système n’est pas laissé ouvert pendant que vous attendez.
Le durcissement n’est pas facultatif si vous vous souciez de la continuité. Les plateformes que vous déployez sont importantes. N’exécutez pas plusieurs services non liés ensemble. N’activez pas SSH par défaut dans les conteneurs. Ne sautez pas les fonctions de sécurité au niveau du système d’exploitation parce qu’elles ajoutent de la complexité à l’installation. Le temps gagné au départ peut coûter plus cher plus tard.
Un système construit avec des défenses superposées est difficile à briser, même lorsque certaines parties sont vulnérables. C’est à cela que ressemble la résilience. C’est ce que les dirigeants devraient demander : des mesures de sécurité qui ne se contentent pas de réagir, mais qui résistent.
Les attaques basées sur l’identité, l’ingénierie sociale et l’infrastructure contournent l’approche traditionnelle de la gestion des vulnérabilités.
Vous pouvez avoir une hygiène parfaite en matière de correctifs et être victime d’une intrusion. Les attaquants ne s’attaquent pas toujours aux failles des logiciels. De plus en plus, ils s’attaquent à votre personnel, à vos contrôles d’accès et aux parties mal configurées de vos environnements qui se trouvent en dehors de vos services de production. Il s’agit notamment des systèmes de sauvegarde, des contrôleurs de domaine, des points de terminaison existants et même des logiciels dont la durée de vie est dépassée depuis longtemps.
Les attaques basées sur les informations d’identification sont extrêmement efficaces parce qu’elles contournent les vulnérabilités techniques et vont directement à l’accès de confiance. La faiblesse de l’authentification et la réutilisation des informations d’identification restent courantes dans les systèmes d’entreprise, même dans les versions « sécurisées ». Si les attaquants obtiennent un accès valide, ils n’exploitent pas de bogues, ils utilisent des fonctionnalités. Il n’y a pas de CVE pour cela.
L’ingénierie sociale va plus loin. Les attaquants manipulent les initiés ou incitent les utilisateurs à cliquer sur la mauvaise chose, à approuver l’accès ou à révéler des détails sensibles. Ces techniques peuvent saper même les systèmes les plus robustes sur le plan technique. Ce qu’elles exploitent, ce n’est pas le logiciel, c’est la connexion humaine avec celui-ci.
C’est pourquoi la gestion des identités et des accès (IAM) n’est pas seulement une fonction informatique, c’est une couche de sécurité fondamentale. La centralisation des systèmes d’identité, l’application de politiques d’accès strictes et l’élimination des maillons faibles tels que l’accès illimité au shell ou les API non sécurisées devraient être des priorités de base, et non des ajouts.
Ensuite, il y a l’infrastructure elle-même. Un stockage en réseau mal sécurisé, des services internes non gérés et des erreurs de configuration persistantes sont autant de points d’appui. Ces éléments passent souvent inaperçus dans les analyses de vulnérabilité parce qu’ils sont opérationnels et non basés sur le code. Mais les attaquants ne les ignorent pas.
En tant que dirigeant, vous voulez une assurance système soutenue par plus que des tableaux de bord CVE. Posez des questions sur la stratégie IAM. Demandez où se trouve encore l’accès non contrôlé. Assurez-vous que l’organisation investit dans la formation continue et la résistance au phishing. Prenez vos décisions en matière de sécurité en vous basant sur la manière dont un attaquant s’en prendrait réellement à votre entreprise, et non sur la manière dont un scanner interprète le code.
L’état d’esprit « zéro CVE » peut conduire à une certaine complaisance et à une mauvaise affectation des ressources en matière de sécurité.
L’objectif de « zéro CVE » est plus une question d’optique que de sécurité réelle. Il s’agit d’un chiffre net qui fait bonne figure dans un rapport ou sur un tableau de bord. Mais lorsque les dirigeants se concentrent sur cette mesure, le comportement des équipes s’en trouve modifié, et pas de la bonne manière. Elles commencent à optimiser l’apparence au lieu de la résilience.
Les équipes finissent par courir après les mises à jour pour garder une longueur d’avance sur les vulnérabilités scannées, même lorsque les CVE présentent un faible risque ou ne sont pas pertinents dans le contexte. Elles renoncent à la stabilité, à la fiabilité et à l’établissement de priorités dans le but d’effacer une liste. Et une fois que cette liste est vide, l’idée s’installe que les systèmes sont sûrs. Il en résulte une baisse de la vigilance, un retard dans l’investissement dans des contrôles plus approfondis et une complaisance dans les domaines à haut risque qui n’apparaissent pas du tout dans les analyses CVE.
La sécurité est une question d’exécution et de contexte, et non de liste de contrôle. Si votre stratégie s’appuie sur les outils des fournisseurs qui signalent « aucune vulnérabilité connue » pour revendiquer le succès, votre organisation se défend contre le passé. Les vulnérabilités les plus importantes sont souvent celles qui n’ont pas encore été découvertes ou signalées. La mention « zéro CVE » donne un faux sentiment de contrôle sur un paysage de menaces en constante évolution.
Les dirigeants doivent comprendre que les mesures de sécurité doivent refléter le comportement réel du risque, dynamique, imprévisible et souvent non signalé jusqu’à ce qu’il soit trop tard. La meilleure question à se poser est la suivante : quelle est la rapidité de réaction des équipes face à des événements inconnus ? Dans quelle mesure les systèmes sont-ils segmentés ? Qu’est-ce qui est en place pour empêcher les mouvements latéraux si quelque chose se brise ?
Il faut investir là où c’est important : dans la détection, la gouvernance des identités, le renforcement et la planification d’urgence, et non dans l’effacement artificiel des registres publics de vulnérabilités. Ce qui paraît bien aux yeux des auditeurs n’est pas toujours ce qui empêche les attaquants d’entrer.
Il est plus avantageux d’adopter une approche de planification de la sécurité fondée sur les risques que de se concentrer sur l’élimination des CVE.
Si la sécurité n’est pas liée au risque, ce n’est que du théâtre. L’objectif n’est pas de tout corriger, mais de protéger ce qui compte le plus. Cela signifie qu’il faut comprendre où l’exposition existe, quels sont les systèmes les plus critiques pour les opérations et comment un incident pourrait se dérouler si une vulnérabilité est exploitée.
La planification de la sécurité basée sur le risque place les modèles de menace et les priorités de l’entreprise au centre de la conception de la sécurité. Cela signifie que certaines vulnérabilités ne seront jamais corrigées, ce qui est acceptable si des contrôles compensatoires sont en place et si la menace ne justifie pas une interruption. À l’inverse, certains systèmes nécessitent une protection immédiate, même s’ils ne présentent aucun CVE, en raison du rôle qu’ils jouent dans votre infrastructure ou des données qu’ils stockent.
Un programme mature s’appuie sur des données provenant de sources multiples : analyses de vulnérabilité, tests de pénétration, informations sur les menaces réelles, examens architecturaux et signaux de risques d’initiés. Il ne se contente pas de suivre la conformité, il l’informe. Si vous vous en remettez à des mesures telles que le nombre de CVE, vous laissez les scanners définir les priorités, au lieu d’aligner l’exécution de la sécurité sur vos propres objectifs opérationnels.
Les dirigeants doivent promouvoir une culture de planification qui pose la question suivante : « Que se passe-t-il si le système est compromis ? et non pas « Combien de CVE sont répertoriés aujourd’hui ? ». Ce changement modifie considérablement les résultats en matière de sécurité. Il encourage des investissements équilibrés dans la gestion des identités, la segmentation du réseau, l’application des règles d’exécution et la capacité de réponse aux incidents. Ce sont les mesures qui tiennent la route lorsque des menaces imprévues émergent.
Le risque n’est pas abstrait. Il est opérationnel, mesurable et directement lié aux performances de l’entreprise. Si vous ne l’évaluez pas correctement, le reste n’a pas d’importance. La planification sécurisée commence là où le risque existe, et non là où il est le plus facile à mesurer. C’est la différence entre l’application réactive d’une politique et la protection proactive.
Réflexions finales
La sécurité n’est pas une ligne d’arrivée, et elle n’est certainement pas définie par l’absence de CVE dans un rapport. Si vous dirigez une équipe, un produit ou une organisation entière, la question que vous devez vous poser n’est pas « Sommes-nous vulnérables ? », mais « Sommes-nous prêts ? ». mais « Sommes-nous préparés ? »
Une analyse de vulnérabilité sans faille ne signifie pas que les attaquants ne peuvent pas entrer. Cela signifie simplement que personne n’a encore trouvé le moyen d’entrer. La véritable sécurité commence par la compréhension de l’exposition, l’atténuation de l’impact et la construction de systèmes qui résistent à la pression et ne se contentent pas de passer les contrôles.
L’objectif est la résilience opérationnelle. Cela signifie qu’il faut investir dans des défenses à plusieurs niveaux, éliminer les configurations faibles, resserrer l’accès et se préparer à l’inconnu. Ce n’est pas tape-à-l’œil, mais cela permet à vos systèmes de survivre lorsque les choses tournent mal.
Utilisez des mesures qui ont un sens, des mesures qui correspondent à des risques réels et non à des feuilles de calcul. Prenez des décisions basées sur les conséquences et non sur la conformité. La sécurité ne consiste pas à tout régler. Il s’agit de réparer ce qui est important avant que cela ne le soit. Assurez-vous que vos équipes sont alignées sur ce principe.
