Gestion des vulnérabilités

La Gestion des vulnérabilités est l'endroit où Cert-IX consolide les résultats produits par vos analyses en une liste de travail unique et priorisée. Chaque résultat est rattaché à une vulnérabilité connue — généralement identifiée par une CVE — évalué par gravité, enrichi de signaux d'exploitation réelle et suivi depuis sa première détection jusqu'à un correctif vérifié. L'objectif est simple : aider votre équipe à consacrer ses efforts aux vulnérabilités qui vous exposent réellement à un risque, dans le bon ordre.

Cette page explique d'où proviennent les résultats, comment ils sont priorisés et comment ils évoluent au fil de leur cycle de vie.

D'où proviennent les résultats

La Gestion des vulnérabilités n'effectue pas d'analyse par elle-même — elle agrège les résultats des surfaces d'analyse que Cert-IX fournit déjà. Une même vue peut donc refléter plusieurs sources complémentaires :

Source	Ce qu'elle apporte	Idéal pour
Moteurs Scan API	Analyses à la demande et pilotées par API (par exemple Trivy, Nuclei, Nikto et OWASP ZAP) qui font remonter les CVE dans les images, les dépendances et les services exposés sur le web	Contrôles externes et pilotés par la CI
Agent Bitscanner	Détection continue des vulnérabilités et des CVE sur les réseaux et hôtes internes	Actifs situés derrière le pare-feu
DepCheck (MCP)	Vérifications de vulnérabilités des dépendances pour les bases de code et les agents de codage IA, appuyées sur les mêmes données d'avis de sécurité	Chaîne d'approvisionnement logicielle

Collecter les résultats du réseau interne

Les résultats provenant d'hôtes situés derrière votre pare-feu nécessitent un agent d'analyse. Téléchargez Bitscanner depuis downloads.cert-ix.com et enregistrez-le avec votre Tenant ID (accessible sous Settings → Organization). Consultez Agents d'analyse pour les étapes de déploiement.

Gravité et priorisation

Chaque résultat porte une note de gravité dérivée de son score CVSS, selon les quatre paliers standard :

Gravité	Plage CVSS	Ce que cela signifie généralement
Critique	9.0–10.0	Exposition sévère, souvent exécution de code à distance ou compromission totale. À traiter en urgence.
Élevée	7.0–8.9	Risque significatif. À prioriser rapidement.
Moyenne	4.0–6.9	Risque modéré. À planifier pour correction.
Faible	0.1–3.9	Risque mineur. À traiter selon la capacité disponible.

La gravité seule ne suffit pas pour décider quoi corriger en premier : un problème Moyen activement exploité aujourd'hui l'emporte souvent sur un problème Élevé qui ne l'est pas. Cert-IX superpose des signaux d'exploitation réelle par-dessus le score CVSS brut :

• CISA KEV — indique si la vulnérabilité figure au catalogue Known Exploited Vulnerabilities de la CISA, c'est-à-dire une exploitation active et confirmée.
• EPSS — la probabilité, selon l'Exploit Prediction Scoring System, qu'une vulnérabilité soit exploitée à court terme.
• Exposition — indique si l'actif concerné est exposé sur Internet ou accessible depuis des réseaux non fiables.
• Criticité de l'actif — l'importance du système concerné pour vos opérations.

Corrigez d'abord ce qui est exploité

Un résultat signalé au catalogue CISA KEV ou portant un score EPSS élevé mérite d'être traité avant un problème au CVSS plus élevé mais sans preuve d'exploitation. Les vulnérabilités exploitées dans la nature sont celles que les attaquants utilisent en ce moment même.

Le cycle de vie d'une vulnérabilité

Les résultats évoluent à travers un ensemble d'états défini, de sorte que chacun dispose toujours d'un statut actuel clair et d'une prochaine étape claire :

1. Identifiée — une analyse a détecté la vulnérabilité.
2. Confirmée — elle a été validée comme un problème réel plutôt qu'un faux positif.
3. Assignée — un responsable est chargé de la corriger.
4. En cours — un correctif est en cours d'application.
5. En attente de vérification — le correctif a été appliqué et attend une nouvelle analyse.
6. Résolue — une analyse de suivi confirme que la vulnérabilité a disparu.

Un résultat peut aussi être marqué risque accepté lorsqu'un correctif n'est pas envisageable et que le risque résiduel est documenté et assumé à la place.

Traiter un résultat

L'ouverture d'un résultat rassemble tout ce qui est nécessaire pour le trier et agir dessus :

• CVE ID — l'identifiant Common Vulnerabilities and Exposures.
• Gravité / CVSS — le score et son palier.
• Exploitation — les indicateurs CISA KEV et EPSS.
• Actifs concernés — les systèmes où la vulnérabilité a été détectée.
• Description — en quoi consiste la faiblesse et son impact potentiel.
• Correction — les recommandations conseillées pour la résoudre.
• Statut et historique — l'état actuel du cycle de vie et une chronologie des changements.

Exemple de résultat

Les champs ci-dessous illustrent la manière dont se présente un résultat une fois collecté. Les valeurs correspondent à une vulnérabilité réelle et publiquement documentée, présentée uniquement à titre d'exemple :

Champ	Valeur
CVE ID	CVE-2021-44228 (« Log4Shell »)
Gravité	Critique (CVSS 10.0)
Exploitation	Listée dans CISA KEV ; EPSS élevé
Actif concerné	Service embarquant Apache Log4j 2.x
Description	Exécution de code à distance non authentifiée via des recherches JNDI dans les chaînes journalisées
Correction	Mettre à niveau Log4j vers une version corrigée (2.17.1 ou ultérieure)
Statut	Confirmée → En cours

Filtrer et cibler

Les grands environnements produisent un grand nombre de résultats ; la liste peut donc être restreinte au sous-ensemble qui vous intéresse — par exemple par gravité, statut du cycle de vie, actif ou groupe d'actifs concerné, statut d'exploitation (KEV / EPSS) ou date de détection. Un ensemble filtré peut être exporté pour être partagé ou pour créer des tickets dans vos propres outils.

Correction

Pour chaque résultat, Cert-IX associe la vulnérabilité à des recommandations de correction. La bonne réponse dépend du problème :

Option	Quand l'utiliser
Patcher	Appliquer le correctif de sécurité de l'éditeur
Mettre à niveau	Passer à une version plus récente et non affectée
Configurer	Modifier les paramètres pour supprimer l'exposition
Atténuer	Appliquer un contrôle compensatoire lorsqu'un correctif n'est pas encore disponible
Accepter	Documenter et accepter formellement le risque résiduel

Après correction, lancez une analyse de vérification sur l'actif concerné. Lorsque l'analyse de suivi ne signale plus la vulnérabilité, le résultat passe à Résolue — bouclant ainsi la boucle entre détection et correctif.

Définir des objectifs de correction

De nombreuses équipes attribuent à chaque gravité une fenêtre de correction cible afin que rien de grave ne traîne. Des points de départ courants sont :

Gravité	Cible typique
Critique	1–2 jours
Élevée	~1 semaine
Moyenne	~30 jours
Faible	~90 jours

remarque

Ces fenêtres sont des exemples illustratifs couramment adoptés par les équipes — non des garanties fixes de la plateforme. Choisissez des objectifs adaptés à votre propre tolérance au risque et à vos obligations réglementaires.

Bonnes pratiques

• Analysez en continu. Gardez les agents d'analyse déployés et lancez des analyses régulièrement afin que les nouvelles vulnérabilités remontent rapidement.
• Priorisez par exploitation, pas seulement par gravité. Traitez les résultats listés dans KEV et à EPSS élevé avant les problèmes mieux notés mais sans preuve d'exploitation.
• Vérifiez toujours. Relancez une analyse après correction avant de faire passer un résultat à Résolue.
• Assumez le risque accepté. Lorsque vous acceptez un risque, notez qui en est responsable et pourquoi, et réexaminez-le périodiquement.

En savoir plus

• Vue d'ensemble de l'analytique — comment la Gestion des vulnérabilités s'intègre aux autres vues analytiques.
• Agents d'analyse — déployez Bitscanner pour la détection des vulnérabilités sur le réseau interne.
• Vue d'ensemble de Scan API — lancez des analyses à la demande et récupérez les résultats par programmation.
• DepCheck (MCP) — vérifications de vulnérabilités des dépendances pour les bases de code et les agents de codage IA.