Sécurité opérationnelle
Les CVE (Common Vulnerabilities and Exposures) sont des failles de sécurité publiques. Toutes ne sont pas dangereuses, toutes ne vous concernent pas — mais celles qui vous concernent vraiment méritent une réaction rapide. Voilà comment on s'y prend.
C'est quoi, au juste ?
Une CVE est une référence publique attribuée à une vulnérabilité, sous la forme CVE-AAAA-NNNNN. Elle indique qu'il existe une faille — pas qu'elle vous concerne, ni qu'elle est exploitable chez vous.
Ce qui compte vraiment : votre stack est-elle concernée ? Et si oui, êtes-vous exposé(e) au vecteur d'attaque ? Une faille distante via HTTP sur un service que vous n'exposez qu'en interne n'a pas la même priorité qu'une faille SSH sur un bastion public.
Le score CVSS
Le score CVSS (sur 10) est calculé à partir de la facilité d'exploitation et de l'impact. C'est un repère utile pour prioriser, pas une vérité absolue.
Exploitation à distance sans authentification, impact total. Patch immédiat.
Exploitation réaliste, impact significatif. Patch sous 24 à 72 h.
Pré-requis ou impact partiel. Patch dans le cycle mensuel.
Impact limité ou exploitation très théorique. Surveille, planifie.
Cycle de vie
Un chercheur ou un attaquant identifie une faille dans un composant logiciel (kernel Linux, OpenSSL, Apache, plugin WordPress, librairie npm…). Elle est signalée à l'éditeur, qui dispose d'un délai pour corriger.
La faille reçoit un identifiant unique (ex. CVE-2024-3094) et un score CVSS sur 10. Les détails techniques sont publiés sur le NVD (NIST), MITRE et les bulletins éditeur.
Une version corrective est publiée. Sur les distros Linux (Debian, Ubuntu, AlmaLinux…), elle remonte généralement dans les jours qui suivent — parfois en quelques heures pour les failles critiques.
Des proofs of concept (PoC) puis des exploits packagés (Metasploit, scanners automatisés) apparaissent. Le temps entre la publication CVE et l'exploitation de masse peut être de quelques heures.
C'est là que vous intervenez — ou que votre infogéreur intervient. Patcher, redémarrer le service, vérifier qu'aucune intrusion n'a eu lieu entre temps.
Trois cas qui ont fait du bruit
RCE non authentifié dans Log4j (Java). Quelques heures après publication, des botnets scannaient déjà internet entier.
Ce qu'on retient
Une dépendance transitive de votre stack peut vous exposer sans que vous le sachiez. D'où l'importance d'un inventaire à jour.
Backdoor injectée dans la librairie de compression xz, présente dans la majorité des distros Linux. Découverte par hasard par un dev Postgres.
Ce qu'on retient
La chaîne d'approvisionnement logicielle est un risque réel. Préférer les versions stables des distros, retarder les versions "bleeding edge".
RCE sur OpenSSH dans certaines conditions. Affectait des millions de serveurs exposés en SSH sur internet.
Ce qu'on retient
Ne pas exposer SSH directement quand possible (bastion, VPN). Limiter par IP. Mettre à jour rapidement.
Notre méthode
Liste précise des paquets, versions, dépendances présentes sur chaque serveur. Sans ça, impossible de savoir si une CVE vous concerne.
Flux NVD, bulletins Debian/AlmaLinux, USN Ubuntu, GitHub Security Advisories pour vos langages. Filtres sur ce qui vous touche réellement.
Le service est-il exposé publiquement ? Authentifié ? Derrière un WAF ? Une CVE 9.8 sur un binaire local est rarement aussi urgente qu'une 7.5 exposée en HTTP.
Test en pré-prod si possible, fenêtre de bascule, vérification post-patch. Pour les failles activement exploitées, on bascule directement avec un plan de rollback prêt.
Chaque patch est consigné : date, CVE traitée, version avant/après, redémarrage des services. Pratique pour les audits et la conformité.
Si la faille a pu être exploitée avant le patch (fenêtre publique avant action), on vérifie : logs d'accès, intégrité, comptes, connexions suspectes.
On regarde votre stack, on identifie les sources de vulnérabilités qui vous concernent vraiment, et on patche dans les bons délais. Forfait mensuel ou audit ponctuel.