Scan de vulnérabilités — trouver les portes avant l'attaquant

Le concept en une phrase

Un scan énumère systématiquement les faiblesses connues d’un système — services exposés, versions vulnérables, composants embarqués — pour prioriser ce qu’on corrige.

Un système TAAF fait tourner des dizaines de services, chacun avec ses propres versions, ses propres bibliothèques, ses propres ports ouverts. Personne ne peut vérifier ça à la main, service par service. Le scan automatise l’énumération — il ne remplace pas le jugement humain, mais il évite de chercher une aiguille dans une botte de foin sans boussole.

Les grands principes

1. Vulnérabilité ≠ exploit ≠ compromission

Trois mots souvent confondus, trois réalités très différentes :

Vulnérabilité — une faiblesse identifiée dans un logiciel ou une configuration (une version obsolète, un bug connu). Elle existe, mais n’est pas forcément exploitable dans ce contexte précis.
Exploit — un code ou une technique qui démontre qu’on peut tirer parti de cette vulnérabilité pour obtenir un effet (accès, élévation de privilège, déni de service).
Compromission — le résultat concret d’un exploit réussi contre un système réel : l’attaquant a effectivement pris pied.

Un scan de vulnérabilités s’arrête à la première étape : il signale des faiblesses potentielles. Il ne prouve pas qu’elles sont exploitables ici, ni qu’un système est compromis. C’est le rôle du pentest (voir la page Purple team) de pousser plus loin.

2. Le langage commun — CVE, CVSS, et pourquoi le score brut ment

flowchart LR
    V[Faille découverte] --> C[CVE\nidentifiant unique]
    C --> S[CVSS\nscore de sévérité 0-10]
    S --> Ctx["+ Contexte du système\n(exposé ? critique ? patché ailleurs ?)"]
    Ctx --> P[Priorité réelle\nde correction]

CVE (Common Vulnerabilities and Exposures) — un identifiant public et unique attribué à chaque vulnérabilité connue (ex. CVE-2024-3400). C’est le langage commun qui permet à tous les outils et équipes de parler de la même faille sans ambiguïté.
CVSS (Common Vulnerability Scoring System) — un score de 0 à 10 qui évalue la sévérité théorique d’une CVE (facilité d’exploitation, impact potentiel).

Le piège : un CVSS élevé sur une CVE qui touche un service non exposé, déjà isolé par la segmentation, ou dont le correctif est déjà appliqué ailleurs dans la chaîne ne mérite pas la même urgence qu’un CVSS élevé sur un service directement accessible depuis Internet. Le score brut ignore le contexte — l’exposition réelle du système audité est ce qui transforme un score en priorité.

3. Scanner le réseau — Nmap : découvrir, énumérer, versionner

Nmap reste l’outil de référence pour explorer ce qu’un réseau expose réellement, en trois temps :

Découvrir — quelles machines sont actives sur le réseau (balayage de plage d’adresses).
Énumérer — quels ports sont ouverts sur chacune d’elles.
Versionner — quel service, quelle version précise tourne derrière chaque port ouvert (souvent le point d’entrée pour croiser ensuite avec une base de CVE).

C’est la première étape de toute reconnaissance, côté attaquant comme côté auditeur : on ne peut évaluer que ce qu’on a d’abord découvert.

4. Scanner l’intérieur des artefacts — SBOM + Grype, la supply chain

Un scan réseau ne voit que l’extérieur d’un service. Mais un logiciel moderne embarque souvent des dizaines, voire des centaines de dépendances — des bibliothèques tierces dont les vulnérabilités deviennent celles de l’application qui les embarque, sans que personne ne l’ait choisi directement.

SBOM (Software Bill of Materials) — une nomenclature exhaustive de tout ce qu’un logiciel ou un conteneur contient réellement (bibliothèques, versions, licences). C’est la liste d’ingrédients du logiciel.
Grype — un scanner qui prend ce SBOM (ou l’image elle-même) et le croise avec les bases de CVE connues, pour révéler les vulnérabilités cachées dans la chaîne d’approvisionnement logicielle, invisibles à un simple scan réseau.

C’est le complément indispensable de Nmap : l’un scanne ce qui est exposé sur le réseau, l’autre scanne ce qui est embarqué à l’intérieur.

5. Les limites du scanner — faux positifs, et ce qu’un scan ne verra jamais

Un scanner reste un outil automatisé, avec ses limites structurelles :

Faux positifs — un scanner peut signaler une vulnérabilité sur la base d’un numéro de version, sans savoir qu’un correctif a été appliqué manuellement (backport) sans changer ce numéro.
Angles morts — un scan ne détecte que des faiblesses connues et cataloguées. Il ne verra jamais une erreur de logique métier, une mauvaise combinaison de permissions légitimes, ou une technique d’attaque qui n’exploite aucune CVE (comme le living-off-the-land, qui détourne des outils légitimes déjà présents sur le système).

C’est exactement la limite qui justifie l’étape suivante : un scan dit ce qui pourrait être exploité, mais seule une mise à l’épreuve active — le purple team — dit ce qui est réellement détecté ou exploitable.

Où ça sert dans TAAF

TP Scan & Reconnaissance — cartographier le réseau TAAF avec Nmap et croiser les versions trouvées avec des CVE connues.
Volet Syft/Grype du TP Conformité — générer un SBOM et scanner la supply chain logicielle d’un système TAAF.

Ressources associées

Ces liens sont des points de départ pour vos propres recherches — voir la bibliothèque complète sur la page Ressources, section Audit & durcissement.

À chercher par vous-même : « CVE vs CVSS », « Nmap service version detection », « SBOM software bill of materials », « Grype vulnerability scanner », « vulnerability vs exploit vs compromise ».