Sommaire (4 sections)
Posez la question à votre prestataire, ou à vous-même : « combien de vulnérabilités critiques connues tournent dans votre infrastructure, là, maintenant ? ». Pendant longtemps, notre réponse honnête était : on ne sait pas exactement. Une centaine d'images de conteneurs en production, des dizaines de projets amont qui publient des correctifs chaque semaine, et aucun processus pour croiser les deux. Voici comment nous avons fermé ce trou : avec Trivy, un scanner open source, et surtout avec l'architecture autour, qui compte plus que l'outil.
Scanner ce qui tourne, pas seulement ce qu'on construit #
Le réflexe habituel place le scan de vulnérabilités dans la CI : chaque build est vérifié avant déploiement. Nécessaire, mais structurellement insuffisant, pour une raison simple : les CVE sont publiées après vos déploiements. Une image saine au build du 1er mars peut porter une critique dévoilée le 15. Si votre seul scan vit dans la CI, une application qu'on ne rebuilde pas reste aveugle indéfiniment. D'où le principe inverse : scanner périodiquement ce qui tourne réellement : la liste des images vivantes, collectée sur les hôtes eux-mêmes, pas la liste théorique des dépôts.
L'architecture, de la collecte au rapport #
- Collecte : chaque semaine, un inventaire interroge la trentaine d'hôtes du parc et relève les images effectivement en cours d'exécution : l'inventaire constaté, pas le déclaré.
- Scan : Trivy analyse les ~93 à 97 images uniques du moment. Comptez ~20 minutes avec trois scans en parallèle, parfaitement acceptable pour un rythme hebdomadaire.
- Tri : liste d'exclusions documentée (le faux positif connu, la CVE sans correctif disponible, le composant non exposé) : chaque exclusion avec sa justification écrite, sinon la liste devient un tapis sous lequel tout glisse.
- Restitution : le nombre de critiques s'affiche dans l'objet du mail hebdomadaire, pas en page 12 d'un rapport. Une semaine à zéro se lit en une seconde ; une critique nouvelle saute aux yeux.
- Résilience : un échec du scan n'annule pas le reste du rapport (l'erreur est notée, la chaîne continue), et la chaîne de veille est elle-même surveillée par un heartbeat : le lundi où le rapport n'arrive pas est précisément celui où il faut s'inquiéter.
Le rapport qui ne signale pas ses propres limites se lit comme une couverture complète. La section « périmètre et limites » n'est pas de la modestie : c'est ce qui rend le reste crédible.
Trier le bruit : la vraie compétence #
Le premier scan d'un parc réel est une douche froide : des centaines d'entrées, dont l'écrasante majorité ne mérite pas une action immédiate. La valeur n'est pas dans le scanner : elle est dans le tri. Notre grille : une vulnérabilité mérite une action rapide si elle cumule critique + correctif disponible + composant réellement exposé. Le reste alimente le cycle normal de mise à jour. Car c'est la vraie conclusion opérationnelle : la remédiation des CVE, dans 95 % des cas, c'est simplement mettre à jour : le scan ne remplace pas une hygiène de versions, il la priorise. Les deux veilles (fraîcheur des versions, vulnérabilités) sont les deux faces du même processus.
Le bonus qui change les conversations : le rapport PDF #
Au-delà du mail hebdomadaire, la chaîne génère un rapport d'audit PDF d'une trentaine de pages : synthèse, inventaire, durcissement des accès, exposition réseau, vulnérabilités par image, dérive des versions, et la fameuse section « périmètre et limites ». Deux finesses de la sonde de durcissement méritent d'être volées : lire la configuration SSH effective (sshd -T) et non le fichier principal (un drop-in peut rouvrir ce que le fichier ferme), et croiser « authentification par mot de passe activée » avec « des comptes ont réellement un mot de passe », sans quoi on classe en critique des hôtes où l'attaque est impossible. Ce PDF sert autant à piloter qu'à répondre : questionnaires sécurité des clients, assureurs, appels d'offres.
Cette veille est un maillon de la chaîne que nous opérons en infogérance, avec le patching qui va derrière et les sauvegardes pour le pire. Si la question du premier paragraphe vous a mis mal à l'aise, c'est le bon point de départ.
