Sommaire (5 sections)
Il y a une question qu'on pose systématiquement en audit, et qui met rarement moins de dix minutes à trouver une réponse : combien d'images de conteneurs tournent chez vous, exactement ? Pas « à peu près », pas « celles du docker-compose de prod ». Le nombre. Dans la plupart des parcs, personne ne le sait, parce que personne n'a jamais eu besoin de le savoir — jusqu'au jour où il faut répondre à « êtes-vous exposés à cette faille ? »
Nous nous sommes posé la question à nous-mêmes il y a quelques jours. La réponse nous a occupés une soirée, et elle valait le détour.
Le dispositif d'avant : juste, et pourtant faux #
Chaque hôte analysait ses propres images, localement, et remontait ses résultats. Sur le papier, c'est du bon sens : l'analyse se fait là où les images vivent, la charge est répartie, aucune donnée ne circule. Chaque machine rendait un verdict exact sur elle-même.
Le problème n'était pas la justesse de chaque mesure, mais ce qu'on en faisait. Vingt-cinq analyses locales produisent vingt-cinq chiffres. Elles ne produisent jamais le chiffre du parc. Impossible de répondre à « quelle version de cette base de données tourne encore quelque part ? » sans interroger vingt-cinq machines une par une, et sans être sûr de n'en avoir oublié aucune.
Recentraliser, et compter pour de bon #
Nous avons remplacé les analyses locales par une analyse unique, menée sur l'inventaire réel du parc de conteneurs. La différence de couverture est le premier enseignement : 111 images uniques, là où le dispositif précédent n'examinait que 25 bases locales. Ce ne sont pas 86 images qui étaient vulnérables et ignorées ; ce sont 86 images que personne ne regardait, dont l'immense majorité allait très bien. Mais on ne le savait pas.
Le deuxième enseignement concerne la priorisation. Toutes les vulnérabilités ne se valent pas, et le tri par gravité théorique est un mauvais guide : une faille « critique » sur un composant qu'aucun attaquant n'exploite dans la vraie vie passe avant une faille « moyenne » activement utilisée. Le bon filtre existe : le catalogue KEV de la CISA américaine, qui ne liste que les vulnérabilités dont l'exploitation est constatée sur le terrain.
Notre analyseur avait cessé d'exposer cette information dans une version récente. Nous sommes donc allés la chercher directement dans le catalogue officiel et l'avons recroisée nous-mêmes avec les résultats. C'est trois lignes de traitement, et ça transforme une liste de centaines d'entrées en une poignée de choses à faire cette semaine.
446, puis zéro #
Une fois l'inventaire juste et le tri utile, le travail de correction est devenu tractable. Le compteur du parc est passé de 446 vulnérabilités à 0 dans la soirée.
Ce chiffre demande une précision honnête, sans quoi il ne veut rien dire. Il ne signifie pas qu'on a corrigé 446 défauts de code un par un. Il signifie que 446 constats portaient sur des images de base périmées, et qu'une fois l'inventaire connu, les reconstruire toutes a soldé l'essentiel d'un coup. Le travail difficile n'était pas la correction. C'était de savoir quoi corriger.
On ne patche pas ce qu'on n'a pas inventorié. Et on n'inventorie pas en demandant à chaque machine de se décrire elle-même.
Le capteur et sa sortie #
Reste la question de la sortie : à qui, et à quel seuil ? C'est la partie qu'on voit le plus souvent bâclée, et celle qui décide si le dispositif sert à quelque chose.
Un capteur dont la sortie n'est pas réfléchie produit du bruit, et un bruit hebdomadaire qu'on finit par ignorer est pire qu'un silence : il donne le sentiment d'être surveillé sans l'être. Nous branchons donc la sortie après avoir vérifié que le signal est propre, et avec une règle simple : la synthèse ne part dans les canaux d'équipe que s'il y a réellement quelque chose à signaler. Un parc sain ne produit aucun message — c'est voulu, et c'est ce qui fait qu'on lit encore les messages quand il y en a.
Ce que ça change pour vous #
Si vous nous confiez votre hébergement ou votre infogérance, ce chantier a trois conséquences concrètes, et elles sont vérifiables :
- Nous pouvons répondre en une minute à « suis-je exposé à cette faille ? », parce que l'inventaire existe et qu'il est à jour — pas parce que quelqu'un se souvient de ce qui tourne où.
- La priorisation est fondée sur l'exploitation réelle, via le catalogue KEV, pas sur un score théorique. Vous ne payez pas du temps d'ingénierie pour des failles que personne n'exploite.
- Le chiffre est une mesure, pas une promesse. « Nous patchons régulièrement » n'engage personne. « 446 puis 0, à telle date, sur 111 images » se contrôle.
Et si vous gérez votre parc vous-même, la question à vous poser ce soir n'est pas « suis-je à jour ». C'est : est-ce que je sais ce que j'ai ? Tant que la réponse est non, tous les autres chiffres sont des opinions.
