Veracode tire la sonnette d’alarme sur un secret de Polichinelle : les vulnérabilités dans les systèmes informatiques des administrations ne sont pas corrigées. Depuis des années. Littéralement.
Ah, les administrations. Toujours promptes à imprimer une attestation en triple exemplaire, mais quand il s’agit de mettre à jour un système exposé sur Internet depuis 2009… là, il faut trois comités, deux audits et une pleine lune.
Veracode, qui fait quand même un peu son boulot dans le domaine de la sécurité applicative, vient de publier un rapport qui sent bon le café froid et le ticket Jira jamais traité : la dette de sécurité accumulée par les administrations devient abyssale. Pas métaphorique, non. Réelle. Mesurable. Et franchement gênante.
🧾 La dette technique ? Non, c’est un héritage culturel
Appelez ça « dette technique », « passif numérique » ou « procrastination IT », peu importe. Le fond du problème, c’est que des milliers de vulnérabilités connues, identifiées, parfois même patchées par l’éditeur depuis belle lurette, traînent encore sur les serveurs des collectivités, ministères et institutions publiques. Certaines datent de l’époque où MySpace était encore cool. On parle de 5, 7, 10 ans de retard sur des correctifs.
Pourquoi ? Parce que c’est comme ça. C’est devenu une habitude. Un style de gestion. Une tradition, même. Il y a les jours fériés, les ponts de mai, et le serveur Oracle 9i exposé avec le mot de passe « admin ».
🧨 Une attaque ? C’est quand, pas si
C’est là que Veracode sort son mégaphone : « Il ne s’agit plus de savoir si une attaque va survenir, mais quand« . Spoiler : c’est déjà le cas, tous les jours. Ce qui est vraiment fascinant, c’est la capacité de certaines entités à ignorer des CVE critiques aussi tranquillement qu’un pigeon ignore les panneaux « ne pas nourrir les animaux ».
Le pire ? Ce ne sont pas des vulnérabilités obscures nichées dans des drivers ésotériques. Non, non. Ce sont des failles connues, publiées, parfois même avec des exploits publics sur GitHub. Et pourtant, elles sont encore là. Comme un vieux meuble qu’on n’ose plus jeter.
🧓 “On a toujours fait comme ça…”
Dans beaucoup d’administrations, la réaction à la découverte d’une vulnérabilité critique suit ce schéma bien rodé :
- « Ah bon ? On est vulnérable à ça ? »
- « C’est pas critique, on n’a pas eu d’attaque. »
- « On a prévu de migrer ce serveur… en 2027. »
Et hop, ticket fermé. Ou oublié. Ou transféré à l’agent qui part en retraite dans 3 mois.
On pourrait presque en rire si ce n’était pas aussi dangereux. Chaque jour, ces failles ouvrent des autoroutes aux attaquants, qui, eux, n’ont pas besoin de conseil d’administration pour agir. Un clic sur Shodan, un script Python de reconnaissance, et voilà : accès root sur une machine d’une mairie de province. Et ce, pendant des mois sans déclencher le moindre log d’alerte.
🔄 L’agilité ? Connaît pas
Dans un monde idéal, chaque vulnérabilité détectée déclencherait une remédiation rapide, testée, validée, documentée. Mais dans les faits, on est plutôt sur un process agile façon mammouth :
- Patch ? Oui, mais en recette d’abord.
- Recette ? Quand on aura le serveur de test.
- Serveur de test ? Il est chez Michel, il est en congé.
- Michel ? Il est passé sur un autre projet depuis 2022.
Résultat : des environnements figés, des applis héritées sans doc, des développeurs qui ne sont plus là, et une culture IT tournée vers la peur du changement.
🎯 Et si on arrêtait de repousser l’évidence ?
Ce que rappelle Veracode, derrière le sarcasme de la situation, c’est une vérité fondamentale : plus on attend, plus le risque grandit. Un système non patché aujourd’hui est un point d’entrée assuré demain. Et ça ne prend pas une APT chinoise ou un groupe ransomware russe pour faire le job. Un étudiant en cybersécurité, une IA script kiddie, ou un bot d’auto-scan suffit.
Ce n’est pas une question de moyens. C’est une question de priorité. De gouvernance. D’organisation. Et d’un petit peu de culot pour dire STOP à la dette technique.
🧽 La purge, ou le crash
Veracode propose évidemment des outils et méthodes pour améliorer la situation. Automatiser les scans. Corréler avec les bases CVE. Faire du DevSecOps. C’est très bien. Mais la vraie première étape ? C’est de reconnaître qu’on a un problème.
Ce n’est pas sexy. Ce n’est pas visible sur LinkedIn. Mais c’est la condition sine qua non pour ne pas finir dans les pages d’un rapport de la CNIL ou dans un communiqué de Lockbit.
🧩 En conclusion : les patchs, c’est comme les vaccins
On les oublie, on les néglige, et puis un jour, on chope un ransomware. Et là, c’est l’état d’urgence, les backups moisis, les données exfiltrées, la hotline de l’ANSSI, et les conférences de presse à base de “nous avons été victimes d’une cyberattaque d’une grande sophistication” (alors que c’était juste une CVE de 2016 non corrigée).
Administrations, il est temps de payer votre dette technique. Avant que quelqu’un d’autre ne le fasse pour vous. En crypto.
