Vulnérabilités

Le module Vulnérabilités relève les paquets installés sur vos machines, dans vos images de conteneurs, dans vos fonctions serverless et dans vos dépôts Git, puis les compare au catalogue des vulnérabilités connues. Un constat est produit par CVE et par paquet sur chaque ressource, avec un score de risque qui combine la gravité, la probabilité d'exploitation, l'exploitation observée et l'exposition de la ressource.

D'où viennent les paquets

Source	Comment l'inventaire est fait
Disques des machines	Sur la copie de disque décrite dans Hôtes, Trivy parcourt le système de fichiers monté (paquets du système et des langages). Sur un disque Windows, les programmes installés sont lus dans la ruche de registre SOFTWARE (clés Uninstall, 64 et 32 bits), avec la version de Windows.
Images de conteneurs	Le module Kubernetes relève les images de chaque cluster et les analyse avec Trivy, avec les secrets de téléchargement du cluster et les identifiants du registre du compte.
Fonctions et conteneurs serverless	Le scanner de fonctions serverless télécharge le paquet de code de la fonction et l'inventorie avec Trivy, qui lit les paquets installés (node_modules, *.dist-info, binaires Go) ; une fonction déployée depuis une image est analysée comme une image, avec les identifiants du registre du compte.
Dépôts Git	À chaque analyse d'un dépôt connecté, les fichiers de verrouillage sont lus : package-lock.json, yarn.lock, go.sum, requirements.txt, Pipfile.lock, Cargo.lock, Gemfile.lock, composer.lock. Les répertoires node_modules, vendor, .terraform, dist et build sont ignorés.

Pour un dépôt, les fichiers de dépendances que le module ne lit pas encore sont nommés dans le résultat plutôt qu'ignorés : poetry.lock, pdm.lock, pom.xml, gradle.lockfile, packages.lock.json et paket.lock (NuGet), mix.lock, pubspec.lock, Podfile.lock, conan.lock, vcpkg.json, Chart.lock, flake.lock, go.work.sum, bun.lockb, et un Cargo.toml sans Cargo.lock. Le statut ctadel/sca posé sur la demande de fusion le dit alors en clair ; voir Infrastructure as code. L'analyse d'une demande de fusion ou d'une branche secondaire alimente le commentaire et le statut de la demande, mais n'écrit ni ne ferme les constats du dépôt, qui décrivent la branche par défaut.

Chaque paquet est relevé avec son nom, sa version complète (époque, version et révision pour un paquet de distribution), son paquet source et son écosystème, ainsi que la famille et la version du système d'exploitation de la source.

Le catalogue

Ctadel tient le catalogue des vulnérabilités dans votre instance et le rafraîchit toutes les 24 heures :

Source	Contenu	Usage
NVD (API 2.0 du NIST)	Toutes les CVE, avec leurs produits affectés (CPE), leurs bornes de versions, leur score et leur vecteur CVSS	Téléchargement complet au premier démarrage, puis seulement les CVE modifiées depuis la dernière synchronisation réussie
CISA KEV	Les vulnérabilités dont l'exploitation est observée, et celles utilisées par des rançongiciels	Colonne et filtre « KEV » ; plancher de probabilité d'exploitation
EPSS (FIRST)	La probabilité d'exploitation à 30 jours et le percentile de chaque CVE	Colonne et filtre « EPSS » ; score de risque
Alpine SecDB	Les versions corrigées par branche Alpine	Avis de distribution
Debian Security Tracker	L'état de chaque CVE par version de Debian et paquet source	Avis de distribution
Ubuntu Security Notices	Les versions corrigées par version d'Ubuntu et paquet binaire	Avis de distribution

Les configurations NVD qui exigent un système ancien ou spécifique (Gentoo, Slackware, Mandrake, Mandriva, un noyau antérieur à la version 3) sont écartées pour éviter de faux positifs.

La correspondance

Pour chaque paquet d'une source, Ctadel cherche les CVE dont un produit porte le même nom (nom du paquet, nom sans préfixe lib ni suffixe -dev, artefact Maven, paquet source), puis vérifie dans l'ordre :

1. L'écosystème. Le type du paquet est ramené à un écosystème du catalogue : deb, rpm, apk, windows, jar, go, python, npm, gem, rust, nuget, composer. Un paquet Python ne correspond pas à une CVE d'un module Node du même nom.
2. La version. La version installée est comparée aux bornes de la CVE (FIXED: version corrigée, RANGE: intervalle, ou version exacte). Une version vide, latest ou * ne peut pas être placée dans un intervalle et ne correspond jamais. Deux versions de branches manifestement différentes ne sont pas comparées.
3. Le système cible. Une CVE qui ne vaut que pour un système (Ubuntu 22.04, Debian 12) n'est retenue que si la source tourne sur ce système ; les versions mineures de Debian comptent pour la même version.
4. Les avis de la distribution. Pour un paquet de distribution, l'avis d'Alpine, de Debian ou d'Ubuntu fait autorité : si la distribution a marqué la CVE corrigée pour la version installée ou supérieure (correctif rétroporté sans changement de version amont), ou jamais affectée pour cette version de la distribution, le constat n'est pas produit. Les versions Debian et Ubuntu sont alors comparées comme dpkg le fait (3.0.11-1~deb12u1 est antérieure à 3.0.11-1).

Le même couple CVE et paquet n'est compté qu'une fois par source. Les constats de la source qui ne ressortent plus sont fermés avec le statut FIXED ; un constat FIXED dont le paquet réapparaît est rouvert ; un constat IGNORED par un utilisateur reste ignoré. Tant que le catalogue n'est pas entièrement chargé, aucun constat n'est fermé : une absence de correspondance ne prouve rien.

Comparaison des versions

La comparaison générale lit une version par segments numériques et alphabétiques, avec l'époque RPM (1:2.34.1-6.el8), les suffixes de lettres d'OpenSSL (1.1.0j), les révisions de distribution (1.2.3-1ubuntu2) et les marqueurs de préversion (2.0.0-rc1 précède 2.0.0). Une version plus courte est classée avant sa forme complétée de zéros : 1.2 précède 1.2.0, comme dans rpm et dpkg. C'est le bon ordre pour les paquets de distribution, qui sont la majorité de ce qui est comparé ; ce n'est pas celui de npm, de PyPI ni de Maven, où 1.2 et 1.2.0 sont la même version. Cet écart est connu et assumé : un paquet de ces écosystèmes rapporté en 1.2 face à un correctif en 1.2.0 est signalé vulnérable alors qu'il est corrigé.

Score de risque et exposition

La colonne « Risque » affiche un score de 0 à 100 calculé ainsi : 35 points au plus pour le score CVSS (CVSS / 10 × 35), 30 points au plus pour l'EPSS (EPSS × 30), 25 points si la CVE est au KEV, 10 points si la ressource est exposée. La liste est triée par ce score.

L'exposition vient du graphe : toutes les cinq minutes, Ctadel relève les ressources joignables depuis Internet (machines, charges Kubernetes, images qu'elles exécutent) et marque leurs constats comme exposés. Il écrit aussi sur les nœuds CVE du graphe le vecteur d'attaque CVSS (réseau, adjacent, local, physique) et une probabilité d'exploitation : l'EPSS, relevé à 0,9 pour une CVE au KEV et à 0,95 pour une CVE utilisée par des rançongiciels. Les chemins d'attaque du module Chemins d'attaque lisent ces valeurs.

La page « Vulnérabilités »

La page « Vulnérabilités » (adresse /vuln) liste les constats ouverts du projet actif avec les colonnes « Risque », « Sévérité », « ID CVE », « KEV », « EPSS », « Paquet », « Actif », « Correctif » et « Âge ». Les filtres portent sur « Sévérité », « KEV », « EPSS », « Correctif disponible », « Paquet », « Actif » et « Statut » ; le regroupement sur « Sévérité », « Paquet » ou « Actif ». La colonne « Correctif » donne la version corrigée pour le paquet concerné, telle que le catalogue la connaît ; elle est vide quand la CVE n'a pas de borne de correction pour ce paquet. La colonne « Âge » compte les jours depuis la première observation. Le bouton « Exporter CSV » exporte la liste filtrée. La page affiche au plus 2 000 constats. Un clic sur une ligne ouvre le panneau de détail, décrit dans Lire un constat.

Limites

• Le module ne voit que les paquets inventoriés. Un binaire compilé sans métadonnées de paquet, un logiciel installé à la main hors du gestionnaire de paquets, ou une dépendance vendue dans le code ne sont pas relevés. Sur Windows, seuls les programmes inscrits dans les clés Uninstall sont relevés ; les correctifs Windows (KB) ne le sont pas.
• Pour un dépôt Git, seuls les huit fichiers de verrouillage nommés ci-dessus sont lus ; Maven, Gradle, Poetry, NuGet, Helm et les autres sont signalés comme non analysés.
• La comparaison 1.2 avant 1.2.0 produit des faux positifs pour les paquets npm, PyPI et Maven dont la version est écrite sans zéro final.
• Les avis de distribution ne couvrent qu'Alpine, Debian et Ubuntu. Sur Red Hat, SUSE, Amazon Linux et les autres, un correctif rétroporté sans changement de version amont reste signalé.
• La correspondance repose sur les noms de produits de la NVD (CPE) ; un paquet dont le nom diffère du produit NVD n'est pas apparié, et un produit homonyme dans un autre écosystème est écarté par le filtre d'écosystème mais pas par le filtre de nom seul.
• Le catalogue complet est téléchargé au premier démarrage de l'instance ; tant qu'il n'est pas entièrement chargé, les constats existants ne sont pas fermés et les nouveaux scans ne sont que partiellement appariés.
• Une image qui n'a pu être téléchargée, ou dont l'analyse a dépassé quatre minutes, n'a aucun paquet relevé et donc aucune vulnérabilité ; voir Kubernetes.
• L'exposition n'est connue que pour les ressources que le graphe relie à Internet ; une ressource exposée par un chemin que le graphe ne modélise pas n'a pas ses 10 points.
• Aucune notification n'est envoyée pour une nouvelle vulnérabilité ; les notifications portent sur les autres types de constats.