Gestion des vulnérabilités

Un rapport de scan est le point de départ d’une décision. Il identifie des faiblesses possibles sur des actifs particuliers ; un analyste vérifie ces constats, les replace dans leur contexte et suit le travail jusqu’à la vérification du résultat. Ce processus répétitif est la gestion des vulnérabilités.

Nomme précisément le problème

Une vulnérabilité est une faiblesse d’un logiciel, d’un matériel, de paramètres ou d’un processus. Une menace est une personne, un groupe ou un événement susceptible de causer un dommage. Un code ou une technique d’exploitation tire parti d’une faiblesse. Le risque combine la probabilité d’un dommage et son impact sur la confidentialité, l’intégrité ou la disponibilité. Une mise à jour manquante est une vulnérabilité ; les attaquants qui l’utilisent pour voler des données constituent la menace qui agit au moyen d’un code d’exploitation.

Les constats comprennent aussi les mots de passe par défaut, le stockage public, les paramètres de chiffrement obsolètes et les produits en fin de vie qui ne reçoivent plus de mises à jour de sécurité. Une vulnérabilité du jour zéro n’a pas encore de correctif, car le fournisseur n’a pas eu le temps de réagir. Une attaque du jour zéro exploite cette faille ; sa seule divulgation ne prouve pas que des attaques ont eu lieu. Tant qu’il n’existe pas de contrôle ni de correctif, les mesures d’atténuation et la détection aident à protéger les systèmes concernés.

Passe de la découverte à la clôture

1. Identifie les actifs : détermine ce qui existe et qui en est responsable.
2. Découvre les faiblesses : scanne les actifs et recueille d’autres signalements.
3. Analyse et valide : vérifie que chaque constat s’applique.
4. Hiérarchise : combine la gravité technique, les éléments relatifs à la menace et le contexte métier.
5. Traite : supprime la faiblesse, réduis le risque ou obtiens une acceptation formelle du risque.
6. Vérifie et rends compte : confirme le résultat, consigne les preuves de clôture et mesure le travail.

Supposons qu’un scanneur signale un service obsolète sur un portail destiné aux employés. L’analyste vérifie la version installée et l’avis du fournisseur. Le responsable du portail explique son rôle métier. Un développeur met à jour le service par le processus de gestion des changements. Un nouveau contrôle confirme la présence de la version corrigée et le fonctionnement du portail. Si de nouveaux serveurs réintroduisent constamment l’ancienne version, cet élément amène le programme à revoir son inventaire de déploiement et ses modèles.

Lis les identifiants

Les autorités de numérotation CVE attribuent des identifiants comme CVE-2014-0160, la faille Heartbleed dans OpenSSL. L’année fait partie de l’identifiant : elle ne donne pas une date fiable de découverte ou de correction. Les failles internes et les erreurs de configuration peuvent nécessiter une action sans identifiant CVE.

Attribue une tâche claire à chaque rôle

L’équipe de sécurité découvre, valide et hiérarchise les constats, puis en assure le suivi. Les administrateurs et les développeurs appliquent les changements ; les responsables d’actifs répondent des risques liés aux systèmes. Les instances chargées des changements approuvent les modifications en production, tandis que les responsables du risque habilités approuvent les dérogations. Une évaluation générale des vulnérabilités, un test d’intrusion autorisé qui démontre l’impact et des signalements valides issus de programmes de prime aux bogues alimentent tous ce même processus de traitement. Un scan sans constat ne décrit que les contrôles exécutés avec succès ; les actifs oubliés et les failles inconnues nécessitent toujours une attention.

Un inventaire indique au programme ce qu’il doit évaluer et donne leur sens aux taux de couverture. Inclus les serveurs, les ordinateurs portables, les équipements réseau, les applications, les ressources cloud ainsi que les domaines et certificats accessibles depuis Internet. Les logiciels et les bibliothèques comptent autant que les machines.

Consigne l’identité et l’importance métier

Chaque fiche doit contenir un identifiant stable, le nom d’hôte, les adresses, le responsable, l’équipe de support, l’emplacement ou le compte cloud, le système d’exploitation et les versions des logiciels, la fonction métier, la classification des données, la criticité, l’exposition et l’état dans le cycle de vie. Utilise un identifiant d’instance cloud ou d’agent pour suivre une machine lorsque ses adresses changent. Une adresse IP seule peut désigner un autre équipement après un changement de bail DHCP.

Attribue un niveau de criticité avec le responsable. Dans un exemple de classement, le niveau 1 couvre les services de paiement et les systèmes d’identité, le niveau 2 les services internes importants et le niveau 3 les laboratoires à faible impact. Le niveau décrit les dommages liés à une perte de confidentialité, d’intégrité ou de disponibilité. Un système difficile à corriger ne devient pas moins critique parce que sa correction est contraignante.

Rapproche plusieurs sources

Une base de données de gestion des configurations (CMDB) répertorie les actifs gérés, mais la découverte révèle souvent des ressources qui en sont absentes. Compare-la aux agents de terminaux, aux services d’annuaire, à DNS et DHCP, aux registres d’achat, aux observations passives du réseau et aux API cloud. Fais correspondre les fiches individuelles avant d’interpréter les différences entre les totaux. Examine tout actif présent dans une seule source : il peut être nouveau, retiré, en double ou inconnu du service informatique.

La découverte active envoie des sondes pour trouver les hôtes qui répondent. Sur un réseau autorisé, nmap -sn 10.20.0.0/24 effectue une découverte d’hôtes sur une plage contenant 256 adresses. L’identification par empreinte déduit des détails sur l’équipement ou le système d’exploitation à partir des réponses ; l’option -O de Nmap demande la détection du système d’exploitation. Considère une identité déduite comme un élément à confirmer. La découverte passive observe le trafic existant et aide à trouver des équipements fragiles sans les sonder, mais elle peut manquer les équipements silencieux.

Détermine l’écart réel

Une opération de découverte trouve 212 hôtes actifs. La CMDB contient 195 fiches, et le rapprochement hôte par hôte confirme que les 195 figurent parmi les hôtes découverts. Il y a donc 17 hôtes actifs non répertoriés. Attribue à chacun un responsable et une fiche, ou retire-le selon le processus approprié.

Le scan de vulnérabilités contrôle 180 de ces 212 hôtes actifs au cours de la même semaine :

Les 32 hôtes non contrôlés constituent une lacune de couverture. Si certains hôtes de la CMDB avaient été absents des résultats de découverte, la simple soustraction des totaux aurait masqué une partie de l’écart. Garde une période et une population cohérentes lorsque tu compares les taux de couverture.

Repère les ressources qui apparaissent et disparaissent

L’informatique fantôme désigne les technologies mises en place à l’insu du service informatique. Elles peuvent échapper aux processus habituels de correction et de scan. Les instances et conteneurs cloud peuvent n’exister que quelques minutes : un scan réseau mensuel peut donc manquer toute leur durée de vie. Alimente l’inventaire à partir des API du fournisseur et exige des étiquettes de ressources utiles, notamment le responsable, l’environnement et la classification des données. Évalue les images et les modèles utilisés pour les lancer.

Pour une application, une nomenclature logicielle (SBOM) répertorie ses composants et ses bibliothèques. Lorsqu’une faille de bibliothèque est divulguée, associe les versions de composants concernées aux applications qui les contiennent. Continue à mettre l’inventaire à jour au fur et à mesure que les ressources sont créées, déplacées et retirées ; une feuille de calcul établie une seule fois ne peut pas décrire longtemps un parc qui change.

Une politique utile indique aux équipes ce qui doit être fait, qui décide et quand le travail doit être terminé. Elle relie les constats de sécurité aux priorités métier de l’organisation. La direction l’approuve et le programme mesure son respect.

Distingue les notions de risque

Le risque inhérent est le risque avant les mesures de sécurité. Le risque résiduel subsiste après leur application. L’appétence pour le risque désigne la quantité et le type de risque que la direction est disposée à accepter pour atteindre ses objectifs. Les décisions relatives à une dérogation tiennent compte du risque restant, et pas seulement du score de gravité initial.

Un modèle qualitatif simple multiplie la probabilité et l’impact, chacun évalué de 1 à 5 :

Un service accessible depuis Internet présente une faille d’exécution de code à distance, avec une probabilité évaluée à 4 et un impact à 5, ce qui donne 20 sur 25. Une règle de pare-feu applicatif web testée abaisse la probabilité évaluée à 2, tandis que l’impact reste à 5, ce qui donne un risque résiduel de 10. Selon une politique fictive exigeant une remédiation sous 30 jours lorsque le risque résiduel dépasse 8, le service doit toujours être corrigé sous 30 jours. La mesure a réduit le risque sans atteindre le seuil d’acceptation de cette politique.

Ces notes organisent les jugements ; ce ne sont pas des probabilités mesurées. Consigne les motifs des notes de probabilité et d’impact pour qu’une personne qui les examine ultérieurement puisse comprendre la décision.

Rédige des règles mesurables

La politique définit le périmètre des actifs, la fréquence des scans, les responsabilités, les règles de gravité et de priorité, les délais de remédiation, les dérogations, l’escalade et les comptes rendus. Les normes précisent les exigences techniques et les procédures décrivent comment les équipes les appliquent. La gouvernance consiste à faire appliquer, mesurer et revoir ces règles.

Un calendrier SLO donné à titre d’exemple prévoit 15 jours pour les constats critiques, 30 pour les élevés, 90 pour les moyens et 180 pour les faibles. Précise le point de départ du délai. Les contrats et les exigences applicables peuvent fixer des délais plus stricts. Ajoute des règles d’exploitation et d’exposition afin qu’une faille connue pour être exploitée sur une passerelle puisse déclencher une intervention d’urgence au lieu d’attendre le délai habituel d’un constat de gravité élevée.

Prévois les travaux qui restent bloqués

Une correction peut interrompre un processus métier, perturber une dépendance ou nécessiter une certification du fournisseur. Les produits anciens peuvent ne pas avoir de correctif, tandis qu’un SLA ou un protocole d’accord peut limiter les moments où les changements ont lieu. La politique doit prévoir des fenêtres de maintenance supplémentaires, des mesures compensatoires vérifiées et des dérogations limitées dans le temps. Un délai non respecté est remonté au responsable de l’actif, puis à son supérieur et ensuite au comité des risques, selon la procédure d’escalade définie.

Relie la politique aux référentiels établis

La mesure 8.8 de l’annexe A d’ISO/IEC 27001:2022 traite de la gestion des vulnérabilités techniques. La mesure 7 des CIS Critical Security Controls v8.1 couvre la gestion continue des vulnérabilités ; les mesures 1 et 2 contribuent aux inventaires des actifs et des logiciels. L’exigence 11.3 de PCI DSS v4.0.1 traite des scans de vulnérabilités dans l’environnement des cartes de paiement, et NIST SP 800-40 Rev. 4 fournit des recommandations pour planifier les correctifs en entreprise. Suis le respect des délais et les risques en retard afin que la revue de la politique repose sur la performance réelle.

Chaque type de scan décrit une partie différente de l’évaluation. L’emplacement, l’accès, le déploiement et l’activité sont des choix distincts : un scan interne peut être authentifié et sans agent, tandis qu’un agent peut évaluer un ordinateur portable hors du bureau. Choisis une combinaison adaptée à l’actif et aux informations nécessaires.

Décide où et comment regarder

Utilise les vues internes et externes. Un scan externe montre l’exposition initiale ; une évaluation interne aide à trouver les chemins accessibles après une compromission ou à une personne interne. Les contrôles authentifiés réduisent généralement les faux positifs et les faux négatifs, car ils examinent directement les versions des paquets et les paramètres. Utilise des comptes de scan dédiés avec les privilèges minimaux permettant une évaluation approfondie. Stocke les identifiants dans le coffre du scanneur, surveille-les et renouvelle-les.

Adapte le déploiement à l’actif

Les agents transmettent à une console les informations recueillies localement. Ils conviennent aux ordinateurs portables qui se connectent rarement au réseau de l’entreprise et aux hôtes cloud pris en charge. Le déploiement, la mise à jour et la surveillance des agents font toujours partie du programme.

Les scans réseau sans agent ne nécessitent aucun logiciel installé et conviennent aux équipements comme les imprimantes et les commutateurs. Ils nécessitent un accès réseau et, pour obtenir des éléments locaux, des identifiants. Certains outils cloud évaluent aussi les instantanés de disques par les API du fournisseur sans agent sur l’hôte. Vérifie l’accès réellement obtenu, et pas seulement le nom du type de scan choisi.

Distingue l’activité et l’objectif

Les scans actifs envoient des sondes et analysent les réponses. L’évaluation passive observe le trafic existant par un port miroir ou un TAP réseau. L’observation passive évite la charge des sondes sur les systèmes fragiles, mais manque les services qui restent silencieux pendant la période d’observation.

Un scan de découverte cartographie les hôtes, les ports, les services et les systèmes d’exploitation probables. Un scan de vulnérabilités recherche les faiblesses connues. Un scan de conformité à un référentiel compare les paramètres à une exigence comme un CIS Benchmark ou un référentiel interne de durcissement. Il peut par exemple signaler qu’une longueur minimale de mot de passe est de 8 alors que le référentiel approuvé exige 14. La seule découverte d’un port ouvert ne prouve pas une vulnérabilité.

Pour les logiciels, l’analyse statique examine le code source ou les fichiers binaires sans les exécuter. L’analyse dynamique observe un programme en cours d’exécution. Le scan web et le fuzzing sont dynamiques ; le fuzzing soumet des entrées malformées ou aléatoires et recherche des défaillances comme des plantages. La rétro-ingénierie statique peut utiliser un désassembleur pour examiner le code compilé.

Applique ces choix

Un site web public nécessite une vue réseau externe ainsi que des tests web authentifiés de ses fonctions utilisateur. Les agents conviennent aux ordinateurs portables fréquemment hors site. Les contrôles internes authentifiés conviennent aux serveurs Linux d’un centre de données. Pour les automates d’usine, commence par une surveillance passive et coordonne tout contrôle actif testé avec l’équipe technique. Le rapport le plus court peut simplement résulter de la visibilité la plus faible : compare les accès obtenus et les authentifications avant d’interpréter sa taille comme une bonne nouvelle.

Un plan de scan doit produire des éléments de preuve utiles sans interrompre les systèmes évalués. Le périmètre, le calendrier, les accès et les limites de charge doivent figurer dans le plan avant l’exécution du scanneur. Teste uniquement les systèmes et comptes couverts par une autorisation écrite et respecte les règles de test du fournisseur d’hébergement.

Définis le périmètre et les limites opérationnelles

Consigne les plages d’adresses, les noms d’hôtes, les comptes cloud, les applications, les contacts, les plages approuvées et les contrôles dangereux exclus. Coordonne-toi avec les exploitants des systèmes et l’équipe des opérations de sécurité pour qu’ils s’attendent aux alertes des scans. Restreins l’accès au scanneur et à ses rapports : ils contiennent des identifiants et une cartographie détaillée des faiblesses.

Mets à jour le flux d’informations sur les vulnérabilités ou les modules d’extension avant chaque exécution. Limite le nombre de cibles et de contrôles simultanés pour éviter de surcharger les liaisons ou les processeurs. Des identifiants incorrects peuvent verrouiller des comptes, les sondes remplissent les journaux et déclenchent les défenses, et les contrôles intrusifs peuvent faire planter des services fragiles. Utilise des profils adaptés à la production, désactive les contrôles susceptibles de provoquer un déni de service et échelonne les travaux lourds hors des périodes de pointe.

La profondeur du scan est un choix. Un profil de découverte a moins d’impact opérationnel qu’un profil approfondi et intrusif, mais il répond aussi à moins de questions. Teste un nouveau profil sur des systèmes représentatifs avant d’étendre son périmètre. La fréquence doit tenir compte des changements et de l’exposition : un scan interne mensuel est un minimum couramment choisi pour un programme, tandis qu’une évaluation hebdomadaire ou continue fournit des éléments plus récents. Des changements importants et des avis urgents peuvent nécessiter des exécutions supplémentaires.

Atteins chaque segment réseau

Un scanneur central placé derrière un pare-feu peut n’atteindre presque aucun hôte d’un sous-réseau isolé. Place des scanneurs distribués ou des agents dans les segments concernés, ou utilise un accès de scan limité à un périmètre et à une durée précis. Préserve la segmentation en dehors de ce qui est nécessaire et approuvé. Vérifie après l’exécution les hôtes atteints et les authentifications réussies pour éviter que des sondes bloquées ne produisent des résultats apparemment sans constat.

Applique les exigences de scan relatives aux cartes de paiement

Pour l’environnement des données des titulaires de cartes, PCI DSS v4.0.1 exige des scans internes au moins une fois tous les trois mois. Les constats critiques et à haut risque, selon le classement de l’entité, doivent être traités et vérifiés par de nouveaux scans ; l’outil de scan doit utiliser des informations à jour sur les vulnérabilités. Des scans internes suivent également les changements importants.

Les scans internes authentifiés prévus par l’exigence 11.3.1.2 sont obligatoires depuis le 31 mars 2025. Utilise des privilèges de scan suffisants ; documente les systèmes qui ne peuvent pas accepter d’identifiants. L’exigence de scan authentifié ne s’applique pas aux scans distincts après changement important prévus par 11.3.1.3. Les scans externes ont lieu au moins une fois tous les trois mois par l’intermédiaire d’un prestataire de scan agréé (ASV) par le PCI SSC, avec de nouveaux scans si nécessaire pour obtenir des résultats conformes. Les changements importants exigent aussi une évaluation externe au titre de la disposition distincte de la norme relative aux scans après changement.

Protège les processus physiques

Les technologies opérationnelles (OT) comprennent les systèmes qui pilotent des équipements physiques. Les systèmes de contrôle industriel (ICS) et les systèmes SCADA, de supervision et d’acquisition de données, donnent souvent la priorité à la sécurité des personnes et à la disponibilité plutôt qu’à la profondeur du scan. Les anciens automates peuvent mal réagir à des paquets inhabituels. Privilégie la surveillance passive et les outils approuvés par le fournisseur ; teste dans un environnement reproduisant le système et obtiens l’accord de l’équipe technique pour les opérations actives pendant les arrêts planifiés.

Un exemple de plan prévoit de scanner 10.20.0.0/24 avec des identifiants le samedi de 1 h à 5 h, de limiter l’exécution simultanée à 10 hôtes, de mettre à jour les flux le vendredi et d’exporter les constats vers des tickets. Il ajoute un scan externe hebdomadaire et une surveillance passive de l’usine. Les contacts des exploitants et les conditions d’arrêt rendent le plan utilisable si la performance change pendant une exécution.

Commence par la question, puis choisis l’outil. Cartographier une plage d’adresses, évaluer une dépendance et vérifier si une défense détecte une attaque sont des tâches différentes. Les résultats d’un outil doivent être validés, même lorsque le nom du produit est familier.

Trouve les hôtes, les services et les faiblesses connues

Nmap cartographie les ports et les services ; -sV demande la détection des versions des services, -O demande la détection du système d’exploitation et le Nmap Scripting Engine permet d’effectuer des contrôles supplémentaires. Angry IP Scanner propose une découverte simple des hôtes et des ports. Masscan recherche rapidement les ports ouverts sur de grandes plages d’adresses, avec peu de détails sur les services.

Nessus utilise des contrôles sous forme de modules d’extension pour évaluer les vulnérabilités connues. OpenVAS de Greenbone signale les faiblesses avec une note de qualité de détection. Nuclei exécute des modèles YAML pour des contrôles ciblés, notamment sur les services web et les CVE. Le choix des modèles compte, car les contrôles diffèrent par leur objectif et leur impact opérationnel.

Évalue le comportement web

Un scanneur réseau peut trouver un serveur web et des problèmes connus de composants, tandis que les tests web authentifiés examinent le comportement de l’application. Les problèmes de logique métier nécessitent toujours une validation attentive du processus réel.

Examine les ressources cloud et les artefacts logiciels

Prowler et ScoutSuite interrogent la configuration cloud par des API et signalent les problèmes de posture de sécurité. Checkov analyse l’infrastructure sous forme de code, comme les définitions Terraform ou Kubernetes. Trivy recherche les composants vulnérables, les erreurs de configuration et les secrets exposés dans des artefacts, notamment les images de conteneurs et les dépôts, et peut générer des SBOM.

Par exemple, un port de gestion ouvert dans une règle Terraform appelle l’utilisation de Checkov ou de Trivy avant le déploiement. Un compartiment de stockage public déjà déployé appelle une évaluation de la posture de sécurité du cloud. Une bibliothèque intégrée à un conteneur appelle un scan de l’image ou une analyse de composition logicielle. Ces constats peuvent avoir le même responsable, mais nécessitent des éléments de preuve différents.

Reconnais les rôles des tests spécialisés

Maltego construit des graphes de relations à partir de données de sources ouvertes au moyen de transforms ; Recon-ng organise la reconnaissance modulaire. Les deux contribuent à la découverte de la surface d’attaque externe. Metasploit Framework comprend des modules d’exploitation et d’évaluation auxiliaires ; Pacu se concentre sur les tests d’attaque AWS. Des tests spécialisés autorisés peuvent confirmer l’exploitabilité, tandis que les analystes chargés du travail courant ont toujours besoin d’éléments de preuve et d’un dossier de traitement.

GDB et Immunity Debugger examinent les programmes en cours d’exécution, la mémoire et les registres. Ils aident à expliquer les plantages trouvés par fuzzing. Atomic Red Team fournit de petits tests associés à MITRE ATT&CK, et Caldera de MITRE automatise l’émulation d’adversaires. Ces outils de simulation d’intrusions et d’attaques vérifient si les mesures de sécurité détectent ou bloquent des techniques. Un test de détection réussi renseigne sur la mesure testée ; il ne prouve pas que les paquets installés sont à jour.

La gravité aide à trier un rapport, mais les éléments de preuve expliquent pourquoi le scanneur a produit un constat. Lis l’actif concerné et la version, le paramètre ou la réponse détectés avant d’attribuer le travail. Un ticket utile doit donner à son responsable assez de détails pour reproduire et corriger le problème.

Lis le constat comme une fiche

Recherche le titre, l’identifiant du module d’extension ou du contrôle, les références CVE, la gravité, la version et le vecteur CVSS, l’actif, le port, le protocole, le service, les éléments de preuve de la détection, la solution recommandée et les dates de première et de dernière observation. Un identifiant de module d’extension désigne le contrôle du scanneur ; il n’est pas interchangeable avec un identifiant CVE.

Pour un problème web, examine l’URL, le paramètre, la requête, la réponse et le niveau de confiance. Un rapport tel que « Injection de script intersite réfléchie dans le paramètre q de /search » indique une entrée de l’application à examiner. Un résultat cloud doit préciser le compte, la région, l’identifiant de ressource, l’identifiant de contrôle et PASS ou FAIL, afin que le responsable de la bonne ressource puisse agir.

Interprète correctement les états des ports

Examine ces résultats de détection des services :

22/tcp   open     ssh    OpenSSH 7.4
80/tcp   open     http   Apache httpd 2.4.6 ((CentOS))
443/tcp  closed   https
3306/tcp filtered mysql

SSH et HTTP sont exposés à ce scanneur. D’après cette observation, aucun service n’est à l’écoute sur le port 443. L’état du port 3306 reste incertain, car un filtre bloque les éléments nécessaires. Les bannières suggèrent un ancien environnement CentOS ; confirme le système d’exploitation et l’état de son support avec des données obtenues par accès authentifié avant d’enregistrer un constat de fin de vie. CentOS Linux 7 est arrivé en fin de vie le 30 juin 2024 ; il faut aussi vérifier les éventuelles dispositions de support étendu.

Utilise le niveau de confiance pour planifier la validation

La qualité de détection (QoD) de Greenbone évalue les éléments de preuve derrière un résultat. Par exemple, elle est de 97 % pour les contrôles authentifiés des paquets, de 80 % pour les bannières qui indiquent le niveau de correctif et de 30 % pour celles qui ne l’indiquent pas. Les rapports masquent généralement par défaut les résultats inférieurs à 70 %. Burp qualifie le niveau de confiance de certain, probable ou incertain. Un constat grave appuyé par des éléments faibles nécessite une validation rapide ; le niveau de confiance et la gravité répondent à des questions distinctes.

Transforme les lignes répétées en travail utile

Une mise à jour d’un fournisseur peut corriger de nombreuses CVE. Si cinq mises à jour résolvent 900 des 1 240 lignes de constats, regroupe les tickets par mise à jour, responsable et liste d’hôtes concernés. Conserve les liens vers les constats individuels afin que la validation puisse confirmer chaque occurrence concernée.

Compare les scans à l’aide d’états comme nouveau, corrigé, rouvert et persistant. Avant d’accepter une forte baisse du nombre de constats, compare les hôtes accessibles, les authentifications réussies et la durée du scan. Une rotation de mot de passe qui empêche la connexion du scanneur peut faire disparaître les constats locaux du rapport sans supprimer aucune faiblesse. Les résultats informatifs peuvent aussi révéler des services inconnus ou des certificats arrivant à expiration : conserve-les donc dans l’examen.

Un résultat positif et une vulnérabilité réelle sont deux choses différentes. La validation vérifie si le constat s’applique à l’actif. L’examen du bon déroulement du scan aide aussi à trouver les faiblesses que le scanneur n’a pas signalées.

Classe les quatre résultats possibles

Les faux négatifs laissent de véritables faiblesses hors de la liste de travail. Les causes courantes comprennent les échecs d’authentification, les sondes bloquées, les hôtes hors ligne, les éléments absents du périmètre, les flux obsolètes, les logiciels personnalisés non reconnus et les failles sans contrôle disponible. Recoupe l’inventaire, la couverture des scans, les journaux d’authentification et les sources indépendantes lorsqu’un rapport semble étonnamment exempt de constats.

Valide des éléments de preuve jusqu’à la conclusion

1. Lis les éléments de preuve du contrôle et la condition qu’il indique comme vulnérable.
2. Obtiens la version réelle du paquet ou la configuration par un accès authentifié.
3. Compare-la à l’avis pertinent du fournisseur et à la version corrigée.
4. Vérifie si la fonctionnalité concernée et les conditions sont présentes.
5. Recoupe les éléments des agents ou des outils de protection des terminaux et consigne la conclusion.

Une bannière peut être obsolète ou incomplète, et un proxy peut répondre à la place d’une autre machine. Une identification erronée du système d’exploitation peut entraîner des contrôles sur le mauvais produit. Une confirmation manuelle, si elle est nécessaire, relève de tests autorisés assortis d’un plan opérationnel adapté.

Reconnais un correctif rétroporté

Une distribution peut corriger une branche ancienne d’un logiciel tout en conservant son numéro de version d’origine. C’est un rétroportage. Supposons qu’une bannière indique OpenSSH_7.4, alors que la correction dans le projet d’origine est apparue en version 7.7. Cette seule comparaison ne tient pas compte des corrections propres à la distribution.

Dans une distribution fictive, un contrôle authentifié renvoie la version de paquet openssh-7.4p1-23, et l’avis du fournisseur indique openssh-7.4p1-21 comme version corrigée pour la même version prise en charge de la distribution. La version 23 contient le correctif rétroporté : le constat concernant cette CVE précise est donc faux. Si les éléments obtenus par accès authentifié confirment aussi un système d’exploitation sans support, le constat de fin de vie reste réel. Clôturer un constat ne clôture pas tous les risques sur l’hôte.

Supprime le signalement de manière ciblée et réexamine-le

Pour un faux positif confirmé, consigne le contrôle, l’actif, le motif, les éléments de preuve et la date de révision. Limite la suppression du signalement à ce contrôle précis sur cet actif précis. Une désactivation globale pourrait masquer des constats avérés ailleurs, et un changement ultérieur de configuration pourrait invalider l’ancienne conclusion.

Une affirmation comme « nous avons appliqué le correctif » doit être vérifiée : un redémarrage peut être en attente ou une seconde copie installée peut subsister. Vérifie la version ou le paramètre effectif au lieu de te fier au souvenir d’une opération de maintenance.

Utilise le bon dénominateur

Si 6 des 50 constats signalés sont faux, 12 % de l’échantillon signalé est faux. Le taux statistique de faux positifs divise quant à lui les faux positifs par l’ensemble des cas réellement négatifs :

L’échantillon de signalements positifs ne fournit aucun nombre de vrais négatifs : il ne permet donc pas d’établir ce taux. Indique précisément ce que mesure un indicateur ; améliorer les identifiants, le périmètre, les flux et l’emplacement des scanneurs améliore les éléments de preuve derrière les résultats positifs comme négatifs.

Le Common Vulnerability Scoring System (CVSS) décrit la gravité technique sur une échelle de 0,0 à 10,0. Consigne la source, la version et le vecteur du score pour que sa signification soit claire. FIRST maintient le CVSS ; la priorité métier nécessite toujours de tenir compte de l’exposition, des éléments relatifs à l’exploitation et du contexte de l’actif.

Décode l’exploitabilité et l’impact

Une attaque qui sort d’une machine virtuelle peut franchir l’autorité de sécurité du système invité et atteindre celle de l’hyperviseur. Une injection de script intersite peut toucher l’autorité de sécurité du navigateur de la victime. Le périmètre ne désigne pas le nombre de machines dans le scan.

Le vecteur de Heartbleed est CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. Il décrit un accès par le réseau, une complexité faible, aucun privilège ni interaction requis, un périmètre inchangé et un impact élevé sur la confidentialité. Son score de base est de 7,5. AV:N décrit le mode d’accès à la faille ; il ne t’indique pas si ton serveur particulier est accessible depuis Internet.

Utilise les coefficients pour un périmètre inchangé

Les coefficients AV sont N 0,85, A 0,62, L 0,55, P 0,20. Pour AC, L vaut 0,77 et H 0,44 ; pour UI, N vaut 0,85 et R 0,62. Pour PR, N vaut 0,85, L 0,62 et H 0,27 lorsque le périmètre est inchangé ; lorsqu’il est modifié, L vaut 0,68 et H 0,50. Chaque coefficient d’impact vaut 0,56 s’il est élevé, 0,22 s’il est faible et 0 s’il est nul.

Lorsque l’impact est positif, plafonne la somme à 10 et arrondis à la décimale supérieure. Un impact nul donne un score de base nul. Pour AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, ISS vaut 0,914816, l’impact vaut environ 5,8731 et l’exploitabilité environ 3,8870. La somme est d’environ 9,7602, donc le score de base est de 9,8.

Un périmètre modifié utilise une expression différente pour l’impact et un coefficient multiplicateur de 1,08 pour le score de base :

Utilise le calculateur correspondant à la version pour appliquer ces règles sans mélanger les formules.

Interprète le résultat

Les plages de gravité sont : nulle 0,0, faible de 0,1 à 3,9, moyenne de 4,0 à 6,9, élevée de 7,0 à 8,9 et critique de 9,0 à 10,0. L’exigence de privilèges faibles fait passer l’exemple à périmètre inchangé de 9,8 à 8,8 ; l’ajout d’un accès local donne 7,8 ; le seul passage à une complexité d’attaque élevée donne 8,1. Ces scores décrivent des différences techniques, pas des probabilités d’exploitation. Si deux sources divergent, compare les vecteurs et les évaluations des sources avant de choisir le score à consigner.

Un score de base décrit les caractéristiques techniques de la faille. Les informations sur la menace évoluent dans le temps et une même faille peut avoir une importance différente selon le déploiement. Le CVSS prévoit des groupes de métriques distincts pour ces ajustements, avec des règles différentes dans les versions 3.1 et 4.0.

Ajuste la v3.1 dans le temps

Le groupe temporel de la v3.1 comprend la maturité du code d’exploitation, le niveau de remédiation et le niveau de confiance dans le rapport. Leurs coefficients multiplicateurs sont :

La valeur non définie compte pour 1. Multiplie le score de base par les trois coefficients et arrondis à la décimale supérieure. Pour un score de base de 9,8 avec E:U, RL:O, RC:C :

Si la maturité du code d’exploitation devient élevée alors que le correctif officiel reste disponible, le produit devient 9,31 et s’arrondit à 9,4. Les ajustements temporels peuvent abaisser le score de base ou le laisser inchangé ; leurs coefficients ne peuvent pas le faire dépasser le score de base.

Décris l’environnement local

Les métriques environnementales de la v3.1 comprennent les exigences de confidentialité, d’intégrité et de disponibilité (CR, IR, AR), ainsi que des métriques de base modifiées comme MAV et MPR. Les coefficients des exigences sont : élevée 1,5, moyenne 1,0, faible 0,5 et non définie 1,0. Documente les éléments relatifs au déploiement qui justifient chaque ajustement.

Dans l’exemple de Heartbleed, une exigence de confidentialité élevée donne un score environnemental de 9,3, tandis qu’une exigence faible donne 5,7. Une faille de score de base 9,8 avec un vecteur d’attaque modifié en adjacent donne 8,8. Utilise le calculateur environnemental complet ; multiplier un score de base par un coefficient d’exigence ne correspond pas à ce calcul.

Lis les changements de CVSS 4.0

La version 4.0 ajoute les conditions requises pour l’attaque (AT), relatives aux conditions de déploiement ou d’exécution, comme une situation de concurrence. L’interaction utilisateur devient absente, passive ou active. Le périmètre est remplacé par des impacts distincts sur la confidentialité, l’intégrité et la disponibilité du système vulnérable (VC, VI, VA) et des systèmes subséquents (SC, SI, SA).

Les groupes sont base, menace, environnement et métriques supplémentaires. La maturité de l’exploitation dans le groupe menace peut être attaqué, preuve de concept, non signalé ou non défini ; la valeur non définie est évaluée comme attaqué. Les exigences environnementales non définies sont évaluées par défaut comme élevées, et les métriques modifiées d’intégrité et de disponibilité des systèmes subséquents peuvent indiquer des impacts sur la sécurité des personnes. Les champs supplémentaires, notamment la sécurité des personnes, la possibilité d’automatisation, le rétablissement, la concentration de valeur, l’effort de réponse et l’urgence selon le fournisseur, ajoutent du contexte sans modifier le score.

Conserve la nomenclature avec les scores

Utilise CVSS-B, CVSS-BT, CVSS-BE ou CVSS-BTE pour indiquer les groupes de métriques utilisés. La version 4.0 calcule les scores à partir de tables de correspondance : utilise donc le calculateur de FIRST. L’exemple de Heartbleed de FIRST donne 8,7 en CVSS-BT, contre 7,5 en v3.1 ; son exemple de XSS réfléchie dans Zimbra donne 5,1 en v4.0 et 6,1 en v3.1. Un changement de version peut modifier le score sans changer le logiciel ni son déploiement.

La gravité décrit les dommages potentiels dans certaines conditions techniques. Les éléments relatifs à l’exploitation indiquent si les attaquants utilisent une faille ou sont susceptibles de l’utiliser prochainement. Ces signaux complètent le CVSS et le contexte métier ; aucune liste ne décrit à elle seule toutes les vulnérabilités.

Distingue les éléments de preuve des prévisions

La Cybersecurity and Infrastructure Security Agency (CISA) américaine tient le catalogue KEV des vulnérabilités connues pour être exploitées. Pour y figurer, une vulnérabilité doit avoir un identifiant CVE, faire l’objet d’éléments fiables attestant son exploitation dans des conditions réelles et disposer d’instructions claires de remédiation. Les entrées indiquent aussi si son utilisation dans des campagnes de rançongiciels est connue. L’absence du catalogue KEV ne permet pas de conclure sur l’exploitation ; les nouvelles attaques ou les faiblesses sans CVE peuvent ne pas y figurer.

L’Exploit Prediction Scoring System (EPSS) de FIRST estime la probabilité qu’une activité d’exploitation soit observée pour une CVE publiée au cours des 30 prochains jours. Les scores vont de 0 à 1 et sont mis à jour quotidiennement. Le centile indique le rang relatif parmi les CVE évaluées.

Dans un exemple de relevé quotidien, un EPSS de 0,10 au centile 0,88 signifie une probabilité estimée à 10 % d’une activité d’exploitation et un score supérieur ou égal à celui de 88 % des CVE évaluées. Le centile n’est pas une probabilité d’exploitation de 88 %, et le score n’est pas la probabilité que ton propre serveur soit compromis.

Évalue la force du signal

Une preuve de concept publiée montre qu’une méthode d’exploitation existe. L’arsenalisation transforme une méthode en outils fiables et utilisables. Une exploitation confirmée dans des conditions réelles, notamment par des rançongiciels, constitue une preuve plus forte qu’il faut agir maintenant. Suis les avis des fournisseurs, le renseignement sur les cybermenaces, les centres de partage et d’analyse de l’information et les mises à jour des catalogues. Un score EPSS faible peut changer lorsque de nouvelles informations arrivent.

Supposons que le constat A ait un score CVSS de 9,8, un EPSS de 0,004 et soit absent du catalogue KEV sur un serveur de test interne. Le constat B a un score CVSS de 7,5, un EPSS de 0,94 et figure dans le catalogue KEV sur une passerelle VPN accessible depuis Internet. Donne la priorité à B : les attaques confirmées, l’accès direct et le rôle critique de la passerelle se conjuguent. Planifie le traitement de A selon la politique au lieu de le retirer de la liste de travail.

Utilise des arbres de décision pour agir

La catégorisation des vulnérabilités propre aux parties prenantes (SSVC) provient du Software Engineering Institute de Carnegie Mellon University. L’arbre de la CISA prend en compte l’exploitation, l’impact technique, la possibilité d’automatisation, l’importance pour la mission et l’impact sur le bien-être public. Ses décisions sont suivre, suivre, prendre en charge et agir*, allant du suivi normal à une action coordonnée urgente. Applique l’arbre lui-même ; connaître une seule donnée ne suffit pas pour inventer son résultat.

La Binding Operational Directive 26-04 de la CISA, publiée le 10 juin 2026, a remplacé la BOD 22-01. Elle s’impose aux agences fédérales civiles de l’exécutif pour les systèmes concernés et fonde les délais sur l’exposition publique, le statut KEV, l’automatisation de l’exploitation et le contrôle technique partiel ou total. Les autres organisations peuvent utiliser le catalogue KEV volontairement. La période de transition de la directive exige que les agences commencent à appliquer ses nouveaux délais d’évaluation et de remédiation au plus tard le 7 décembre 2026.

Réagis lorsqu’aucun correctif n’existe

Pour une vulnérabilité du jour zéro, applique les mesures d’atténuation du fournisseur, restreins le service concerné et renforce la détection et la surveillance. Dès qu’une correction paraît, hiérarchise son application selon la gravité, l’exposition et les éléments relatifs à l’exploitation. Si des attaques sont signalées, procède rapidement à l’escalade et recherche une éventuelle compromission dans le cadre du processus de réponse aux incidents. L’EPSS couvre les CVE ; évalue les failles du code interne et les erreurs de configuration à partir des éléments qui leur sont propres.

Une priorité indique à un responsable dans quel délai agir et pourquoi. Pars d’un constat validé, puis combine la gravité technique, les éléments relatifs à l’exploitation, l’accessibilité, la valeur de l’actif, les mesures existantes et la disponibilité du traitement. Un score seul ne peut pas décrire les conséquences métier d’une défaillance.

Évalue l’actif et son chemin d’attaque

Les actifs externes sont accessibles depuis Internet. Les actifs internes sont accessibles après l’entrée d’un attaquant dans le réseau ou par une personne interne. Les actifs isolés présentent moins de chemins d’accès, mais les équipements de maintenance et les liaisons de support peuvent toujours franchir la séparation.

La valeur de l’actif comprend son niveau de criticité, la classification des données, le périmètre réglementaire et les dépendances. Un fournisseur d’identité peut détenir directement peu de données clients tout en contrôlant l’accès à de nombreux autres systèmes. Examine les effets sur les services qui dépendent de l’actif vulnérable, et pas seulement sur l’hôte lui-même.

Ne tiens compte d’une mesure compensatoire que si elle bloque le chemin concerné et a été testée. Un pare-feu applicatif web en mode détection uniquement enregistre les attaques mais ne les arrête pas. Une règle de segmentation qui autorise toujours l’accès au service vulnérable depuis les réseaux des utilisateurs laisse ce chemin ouvert.

Applique une politique dans l’ordre prévu

Examine cette politique fictive, appliquée à partir de P1 par ordre décroissant :

F1 est une faille de score 9,8 sur une machine virtuelle de laboratoire isolée, sans exploitation connue, avec un EPSS de 0,02. Elle ne répond ni à P1 ni à P2 : elle relève donc de P3. F2 est une faille de score 7,5 sur un serveur web externe et figure dans le catalogue KEV : P1. F3 est une faille d’injection de score 6,5 sur un portail externe de niveau 1, avec une preuve de concept publique et un EPSS de 0,20 : P2 selon le seuil EPSS. F4 a un score de 8,8 sur un serveur de fichiers interne, avec un EPSS de 0,15 et un correctif : P2 également selon l’EPSS.

Traite F2 en premier. Dans P2, l’exposition externe du portail client de F3 le place avant F4 dans cet exemple. F1 reste planifié. Un tri numérique par CVSS aurait placé en premier la faille peu exposée du laboratoire et retardé le traitement d’un service public dont l’exploitation est connue.

Choisis une action disponible

Un correctif permet de planifier la remédiation. Si aucune correction n’existe, réduis l’exposition et surveille tout en suivant la correction attendue. Les produits en fin de vie nécessitent un plan de remplacement et une protection provisoire. L’absence de correctif modifie le traitement ; elle n’efface pas la priorité.

Examine les combinaisons sur un même actif. Une fuite d’informations qui expose des noms d’utilisateur, des contrôles de connexion faibles et un ancien module d’extension peuvent former un chemin plus grave que chaque ligne examinée isolément. Examine ensemble les constats liés avant de fixer l’ordre de travail.

Explique la décision dans le ticket

Indique l’identité de l’actif, son responsable, les éléments de preuve du constat, le traitement recommandé, la priorité, le délai et le motif. Par exemple : « P1 : la faille confirmée est connue pour être exploitée et le portail est accessible depuis Internet ; termine la remédiation dans le délai de 3 jours prévu par la politique fictive. » Conserve le motif avec le ticket lorsque le travail est regroupé sur plusieurs hôtes. Un faux positif probable fait rapidement l’objet d’une validation avant qu’une décision ferme de traitement ne repose sur lui.

Un traitement modifie la faiblesse, l’exposition ou la décision métier concernant le risque. Choisis le traitement qui répond au constat réel, puis prévois qui le mettra en œuvre et comment son effet sera vérifié. La remédiation est le choix par défaut lorsqu’elle est réalisable.

Distingue les possibilités de traitement

Une mesure compensatoire répond à l’objectif d’une mesure obligatoire lorsque celle-ci ne peut pas être appliquée. Elle doit traiter le même risque, être documentée et vérifiée. Une liste d’autorisation de segmentation peut protéger un service ancien impossible à corriger ; une règle de pare-feu applicatif web peut fournir un correctif virtuel contre un mode d’exploitation connu. La détection seule laisse toujours le chemin d’attaque ouvert.

Classe les mesures de deux façons

Le type d’une mesure décrit sa mise en œuvre : les mesures administratives ou de gestion comprennent les politiques et les décisions relatives aux risques ; les mesures opérationnelles sont des processus humains quotidiens comme la gestion des changements ; les mesures techniques comprennent l’authentification multifacteur et les pare-feu ; les mesures physiques comprennent les serrures et les lecteurs de badges.

La fonction d’une mesure décrit son rôle : les mesures préventives empêchent les événements, les mesures de détection les repèrent, les mesures correctives suppriment les faiblesses ou réparent les dommages, et les mesures de réponse endiguent un incident pendant son déroulement. Un scan de vulnérabilités est une mesure de détection. Un correctif est une mesure corrective. L’isolement automatisé d’un terminal peut être une mesure de réponse. Une mesure peut remplir plusieurs fonctions ; le type et la fonction sont deux classifications distinctes.

Planifie le changement par étapes

1. Teste la mise à jour ou la configuration dans un environnement ressemblant à la production.
2. Mets en œuvre le changement approuvé pendant une fenêtre de maintenance.
3. Prépare les éléments et les étapes du retour arrière, comme une sauvegarde ou un instantané, avant de modifier la production.
4. Valide le fonctionnement du service et la disparition de la faiblesse initiale.

Une faille activement exploitée peut nécessiter l’approbation d’un changement d’urgence. Une fenêtre de maintenance trimestrielle ne peut pas remplacer sans autre formalité un délai de 15 jours fixé par la politique. Négocie une fenêtre supplémentaire, utilise des mises à jour progressives lorsque la redondance le permet ou obtiens une dérogation limitée dans le temps avec des mesures vérifiées.

Traite une mise à jour bloquée

Un module web présente une faille critique d’exécution de code à distance. Le correctif est disponible, mais la certification de l’application prendra trois semaines et le délai est de 15 jours. Désactive le module s’il n’est pas utilisé. Sinon, teste un correctif virtuel, restreins l’accès aux réseaux des partenaires nécessaires et renforce la surveillance. Consigne le risque restant et obtiens la dérogation requise, puis installe la mise à jour certifiée et effectue un nouveau scan.

Réduis aussi la surface d’attaque : découvre les actifs externes par des scans en périphérie, DNS et les enregistrements de certificats ; supprime les services inutilisés et les systèmes retirés. Les tests des mesures de sécurité, les tests d’intrusion, l’émulation d’adversaires et les signalements issus de programmes de prime aux bogues peuvent révéler des chemins qui nécessitent une attention. Supprimer un composant inutile empêche l’accumulation de futurs constats à son sujet.

Certains constats réels ne peuvent pas être corrigés dans le délai prévu par la politique. Une dérogation rend le risque qui en résulte visible et confie la décision à un responsable habilité. C’est une décision encadrée avec une date de fin, pas un moyen de retirer les travaux difficiles du tableau de bord.

Choisis la stratégie de gestion du risque

L’acceptation conserve le risque en connaissance de cause lorsque l’activité est nécessaire à l’organisation ou que les coûts du traitement dépassent le bénéfice attendu. L’atténuation réduit la probabilité ou l’impact. L’évitement met fin à l’activité risquée. Le transfert reporte certaines conséquences financières par un contrat ou une assurance, tandis que la responsabilité reste à l’organisation.

Un contrat ou une police d’assurance n’empêche pas un code d’exploitation d’atteindre un service non corrigé. Examine son périmètre séparément des mesures techniques. Une dérogation refusée laisse toujours une décision à prendre : renforcer les mesures, corriger ou arrêter l’activité.

Rédige le dossier de dérogation

Consigne l’actif et le constat précis, la justification métier, l’analyse du risque, les mesures compensatoires, le risque résiduel, la personne habilitée à approuver, la date d’expiration et les faits déclenchant une révision anticipée. Relie le dossier aux travaux de remédiation afin que la correction permanente prévue reste visible.

Un faux positif signifie que la faiblesse signalée est absente et le constat est clôturé avec des éléments de preuve. Une dérogation signifie que la faiblesse est réelle et que son risque résiduel est conservé temporairement. Supprimer le signalement d’un constat réel en le qualifiant de faux effacerait précisément le risque que la direction doit approuver.

Adapte l’approbation au risque restant

Le responsable du risque approuve à un niveau adapté au risque résiduel. Une dérogation à faible risque peut relever de l’autorité d’un responsable d’actif, tandis qu’un risque résiduel élevé peut nécessiter l’approbation de la direction ou du responsable de la sécurité des systèmes d’information. L’administrateur qui demande le report des travaux n’approuve pas seul sa demande. L’équipe de sécurité évalue les éléments de preuve et recommande des mesures.

Compare le risque restant à l’appétence pour le risque de l’organisation. Une décision dépassant l’autorité déléguée doit être remontée à un niveau supérieur ou refusée. Le fait qu’un système soit difficile à remplacer explique la demande ; il ne prouve pas que son risque est acceptable.

Suis un cas de système ancien

Un instrument de laboratoire utilise un ordinateur de commande sous Windows 7 dont le logiciel du fournisseur ne peut pas fonctionner sur un système plus récent. Le support standard a pris fin le 14 janvier 2020 et son remplacement est budgété pour l’année suivante. L’équipe consigne l’absence de support de l’ordinateur comme un constat réel et propose un réseau isolé, la désactivation du stockage USB, une liste d’applications autorisées et une surveillance supplémentaire.

Le responsable du service et la direction de la sécurité examinent le risque résiduel évalué. La dérogation expire après six mois ou lorsque le remplacement est installé, selon la première échéance atteinte. Le projet de remplacement conserve un responsable et des jalons, même si la date de révision de la dérogation précède sa fin prévue.

Rouvre le dossier lorsque les conditions changent

Un nouveau code d’exploitation, une entrée dans le catalogue KEV, une mesure compensatoire défaillante ou un changement d’exposition peuvent invalider l’évaluation précédente avant son expiration. Réexamine alors le risque, sans attendre la date prévue. Suis le nombre et l’ancienneté des dérogations, les expirations prochaines et les corrections permanentes en attente. Évite les dérogations générales pour des environnements entiers : les actifs peuvent présenter des chemins d’attaque, des responsables et des conséquences différents.

Une mise à jour installée est une action ; une remédiation vérifiée est un résultat. Ne clôture un constat que lorsque les éléments de preuve montrent que la faiblesse initiale a disparu et que le service fonctionne toujours. Suis les délais et la couverture associés à ces preuves afin que les responsables voient où le risque subsiste.

Vérifie la condition initiale

Effectue un nouveau scan des actifs concernés avec le même type de scan pertinent et des identifiants fonctionnels, ou examine directement la version effective du paquet ou le paramètre. Confirme que le contrôle a réussi. Une connexion échouée ne permet pas d’établir qu’une vulnérabilité locale est corrigée. Valide aussi les mesures compensatoires : vérifie que la nouvelle règle d’accès ou le correctif virtuel bloque réellement le chemin concerné.

Une correction peut échouer parce qu’un redémarrage est en attente, qu’un seul nœud du cluster a été mis à jour, qu’une application contient sa propre bibliothèque plus ancienne ou qu’un déploiement écrase le paramètre. Si les instances de remplacement réintroduisent constamment la faille, mets à jour l’image de référence ou le modèle qui les crée. Considère les réouvertures répétées comme le signe d’une cause racine dans le processus de compilation ou de déploiement.

Utilise des états de processus clairs

Fais passer le travail par des états comme ouvert, en cours, risque atténué, risque accepté, résolu en attente de vérification et clôturé. « Risque atténué » signifie qu’une mesure a réduit le risque ; « clôturé » exige les preuves de clôture appropriées. L’intégration du scanneur au système de tickets peut réduire les doublons, mais les changements d’état automatiques doivent toujours respecter les règles de vérification réussie et de dérogation.

Lis les indicateurs ensemble

Cinq constats critiques sont clôturés après 4, 9, 12, 20 et 30 jours :

Avec un SLO de 15 jours, seuls trois ont été traités à temps :

La moyenne respecte le délai de 15 jours alors que 40 % de ces constats ont manqué l’objectif. Présente aussi les constats ouverts en retard : une moyenne calculée sur le travail terminé ne dit rien de l’ancienneté d’un élément non résolu.

Procède à l’escalade pour les travaux qui nécessitent une décision

Les tranches d’ancienneté comme 0 à 30, 31 à 60, 61 à 90 et plus de 90 jours montrent les travaux bloqués. Compare l’ancienneté de chaque élément à son propre délai, puis suis la politique du responsable de l’actif à son supérieur et au comité des risques. Une faille nouvellement exploitée peut nécessiter une escalade immédiate, avant tout seuil d’ancienneté.

Les équipes techniques ont besoin de listes d’hôtes, d’éléments de preuve et de corrections. Les responsables ont besoin des tendances, des principaux risques, des travaux en retard et des ressources ou décisions nécessaires. Une baisse du total peut provenir d’échecs de scan ou de la clôture rapide d’éléments à faible impact : compare donc la couverture et l’ancienneté des constats prioritaires avant d’y voir un progrès.

Les constats applicatifs décrivent des défaillances dans la manière dont les logiciels traitent les données, la mémoire, l’identité ou les erreurs. Adapte la correction au mécanisme. L’OWASP Top 10:2025 est une liste de sensibilisation : défaillance du contrôle d’accès, erreurs de configuration de sécurité, défaillances de la chaîne d’approvisionnement logicielle, défaillances cryptographiques, injection, conception non sécurisée, défaillances de l’authentification, défaillances de l’intégrité des logiciels ou des données, défaillances de la journalisation et des alertes de sécurité, et gestion incorrecte des conditions exceptionnelles.

Empêche les données de devenir des instructions

Une injection se produit lorsqu’une entrée non fiable devient une partie d’une requête ou d’une commande. Utilise des requêtes paramétrées, la validation par liste d’autorisation et des comptes respectant le principe du moindre privilège ; évite les appels au shell construits à partir d’entrées utilisateur. L’injection de script intersite (XSS) exécute un script fourni par un attaquant dans le navigateur d’un autre utilisateur. Une XSS réfléchie revient dans une réponse immédiate, une XSS stockée est enregistrée pour les personnes qui la consulteront plus tard et une XSS fondée sur le DOM apparaît dans le code côté client. Utilise un encodage des sorties adapté au contexte et des modèles sûrs, complétés par une politique de sécurité du contenu. Les cookies HttpOnly limitent l’accès des scripts aux cookies mais ne corrigent pas les sorties non sécurisées.

Distingue les requêtes et les accès aux fichiers

Une SSRF peut atteindre les métadonnées cloud à l’adresse 169.254.169.254. L’inclusion de fichier peut divulguer son contenu ou exécuter son code selon la manière dont l’application le traite.

Protège la mémoire et les permissions

Un dépassement de tampon écrit au-delà de la mémoire allouée sur la pile ou dans le tas. Un dépassement d’entier dépasse la plage d’un type ; un calcul non signé sur 8 bits peut revenir de 255 plus 1 à 0. Utilise des vérifications de bornes, des fonctions sûres et des langages à gestion sûre de la mémoire. L’ASLR, DEP/NX et les canaris de pile rendent l’exploitation plus difficile alors que la faille de code subsiste.

Une défaillance du contrôle d’accès permet aux utilisateurs de dépasser leurs permissions, par exemple en lisant la facture d’un autre client après avoir changé son identifiant. Vérifie l’autorisation côté serveur pour chaque requête et refuse l’accès par défaut. Une élévation verticale de privilèges donne des droits plus élevés ; une élévation horizontale donne les droits d’un autre utilisateur. Les corrections de l’authentification et des sessions comprennent l’authentification multifacteur, des identifiants de session aléatoires, leur renouvellement à la connexion et leur expiration.

Traite la conception et les services connexes

Les défaillances cryptographiques comprennent les données non chiffrées, les clés inscrites en dur et les fonctions de hachage rapides pour les mots de passe. Utilise TLS 1.2 ou une version ultérieure, des clés gérées et des fonctions de hachage lentes pour les mots de passe comme Argon2 ou bcrypt. Supprime les comptes par défaut, les fonctionnalités inutiles, le listage des répertoires et les erreurs trop détaillées. Valide les failles précises des composants séparément du risque lié à l’absence de support en fin de vie.

Une conception non sécurisée nécessite des changements de conception et d’implémentation, ainsi qu’une modélisation des menaces pour identifier les mesures manquantes. L’exécution de code à distance permet à un attaquant de faire exécuter à distance le code de son choix ; l’exécution locale de code exige un accès différent. L’empoisonnement des données corrompt des données fiables ou d’entraînement : contrôle les sources et suis leur provenance. En cas d’erreur, échoue en mode fermé afin que les conditions exceptionnelles n’accordent pas d’accès. Un pare-feu applicatif web peut réduire l’exposition pendant la correction du code, mais le code non sécurisé doit toujours être corrigé.

Un logiciel sécurisé nécessite des contrôles à plusieurs étapes, car aucun test ne voit à lui seul tout le système. Ajoute des exigences de sécurité, la modélisation des menaces, la revue de code, des tests automatisés, des contrôles de déploiement et la maintenance au cycle de développement logiciel (SDLC). Avancer les contrôles appropriés dans le cycle est appelé décalage vers la gauche.

Compare les méthodes de test

Le SAST peut signaler une valeur de requête concaténée dans une requête. Le DAST peut fournir des éléments issus des réponses de l’application de test en cours d’exécution. Valide les éléments combinés avant de choisir la correction du code. Le fuzzing ajoute des tests avec des entrées malformées pour trouver des plantages et d’autres défaillances. L’authentification et la couverture de l’exploration comptent : une exécution DAST qui n’atteint jamais une page d’administration n’en a pas évalué les entrées.

Trouve les dépendances concernées

La SCA lit les manifestes de paquets, les fichiers de verrouillage ou les fichiers binaires pour identifier les composants intégrés. Par exemple, log4j-core 2.14.1 est affecté par Log4Shell, CVE-2021-44228, avec un score CVSS v3.1 de 10,0. La correction exige une version corrigée adaptée et le redéploiement de chaque application contenant le composant. La version 2.17.1, référence historique de remédiation pour Java 8, traite les failles liées à cet incident ; pour les nouveaux travaux, choisis une version actuellement prise en charge et recommandée par le fournisseur.

Une SBOM consigne les composants, versions, fournisseurs et relations de dépendance dans un format lisible par machine comme SPDX ou CycloneDX. Elle indique où un composant est utilisé. Une déclaration VEX d’un fournisseur indique si un produit est non affecté, affecté, corrigé ou en cours d’analyse pour une vulnérabilité. Vérifie que la déclaration VEX correspond au produit et à sa version et examine le motif fourni avant de modifier l’état d’un constat.

Protège la chaîne d’approvisionnement

Les canaux de mise à jour compromis, les paquets malveillants aux noms similaires et les dépendances abandonnées peuvent introduire des risques par l’intermédiaire de fournisseurs de confiance. La compromission de SolarWinds Orion en 2020 illustre une attaque contre un canal de mise à jour. Évalue les pratiques des fournisseurs ; conviens des attentes relatives aux correctifs et à la divulgation ; demande des SBOM ; vérifie les empreintes ou les signatures ; fige les versions des dépendances ; et utilise des registres internes approuvés. Le verrouillage des versions permet de maîtriser les changements, mais une dépendance figée devenue obsolète nécessite toujours une revue et des mises à jour.

Intègre la sécurité au programme

La modélisation des menaces examine la conception pour déterminer ce qui pourrait mal tourner. STRIDE couvre l’usurpation d’identité, l’altération, la répudiation, la divulgation d’informations, le déni de service et l’élévation de privilèges. Transforme les menaces identifiées en mesures de sécurité et en cas de test.

Le Software Assurance Maturity Model (SAMM) de l’OWASP organise l’amélioration du programme autour de la gouvernance, de la conception, de la mise en œuvre, de la vérification et de l’exploitation : trois pratiques par fonction, 15 au total, avec des niveaux de maturité de 1 à 3. Utilise-le pour planifier les capacités, tandis que la programmation sécurisée au quotidien sépare les données des commandes, encode les sorties, protège les identifiants et les sessions, limite les privilèges et gère les erreurs sans exposer les détails internes.

La sécurité du cloud dépend du travail du fournisseur et du client. Identifie le modèle de service avant d’attribuer un constat, puis évalue les paramètres déployés ainsi que les images, le code et les modèles qui les créent. Les ressources cloud peuvent changer plus vite qu’un scan réseau périodique.

Répartis les responsabilités selon le modèle de service

Dans tous les modèles, les clients restent responsables de leurs données et des personnes qui peuvent y accéder. Une base de données gérée peut supprimer le travail de correction du système d’exploitation tout en laissant au client la correction des permissions excessives ou de l’exposition publique.

Lis les constats de posture par ressource

La gestion de la posture de sécurité du cloud (CSPM) vérifie les configurations par les API des fournisseurs, généralement avec un accès en lecture seule. Prowler et ScoutSuite signalent les constats par ressource et par rapport à des référentiels, comme les CIS Foundations Benchmarks pour le cloud. Répète les contrôles, car les paramètres des comptes, les identités et les règles réseau changent fréquemment.

Les constats courants comprennent le stockage public, les permissions d’identité trop larges comme "Action": "*", les volumes ou instantanés non chiffrés, la journalisation désactivée, les clés d’accès enregistrées dans le code, les utilisateurs privilégiés sans authentification multifacteur, les interfaces de gestion exposées et les accès SSH ou RDP ouverts à tout Internet. 0.0.0.0/0 couvre toutes les adresses IPv4 ; une règle qui l’autorise sur le port 22 ou 3389 expose le service de gestion partout où la ressource est accessible.

Corrige la source du déploiement

L’infrastructure sous forme de code (IaC) décrit les ressources dans des modèles. Checkov ou Trivy peut signaler avant le déploiement une règle Terraform contenant cidr_blocks = ["0.0.0.0/0"] pour SSH. Restreins l’accès à la plage administrative nécessaire ou utilise un bastion ou un service de gestion de session approuvé.

Corrige à la fois le paramètre déployé et son modèle. Sinon, le déploiement suivant peut rétablir l’exposition. Les différences entre les paramètres déclarés et réels constituent une dérive de configuration. Une correction effectuée uniquement dans la console peut être temporaire, même si le contrôle immédiat réussit.

Reconstruis les images et couvre les charges de courte durée

Scanne les images de conteneurs à la recherche de paquets du système d’exploitation et de bibliothèques dans le pipeline de compilation et le registre. Reconstruis-les à partir d’une image de base mise à jour et redéploie-les ; ne compte pas sur la correction individuelle des conteneurs en cours d’exécution. Les images de base minimales réduisent le nombre de composants inutiles. Examine aussi les définitions Kubernetes pour repérer les paramètres risqués comme l’exécution privilégiée.

Utilise les API du fournisseur et les étiquettes de ressources pour inventorier les instances de courte durée. Évalue leurs images de référence, leurs modèles et leurs dépendances ; utilise des agents pris en charge ou l’évaluation des instantanés lorsque c’est adapté. Pour les environnements d’exécution sans serveur gérés, les mises à jour du fournisseur suivent les paramètres de mise à jour du service. Les clients maintiennent le code et les bibliothèques des fonctions, reconstruisent les fonctions fondées sur des conteneurs et mettent à jour les environnements d’exécution personnalisés.

Traite un constat de posture jusqu’à sa vérification

Une évaluation découvre un stockage public de données personnelles, un accès root sans authentification multifacteur et un accès RDP ouvert à tout Internet. Restreins immédiatement l’accès aux données exposées et traite de toute urgence l’identité privilégiée et le chemin de gestion. Corrige les règles du compartiment et du réseau dans les ressources déployées et dans l’IaC. Configure l’authentification multifacteur de l’utilisateur root AWS dans la console de gestion ; les API et l’IaC ordinaires ne permettent pas de l’activer. Relance les contrôles pertinents, vérifie que l’accès à l’application fonctionne toujours et vérifie qu’un déploiement ultérieur conserve la correction.