Qu'est-ce que la gestion des vulnérabilités ?
La gestion des vulnérabilités est le processus continu et systématique d'identification, d'évaluation, de traitement et de signalement des vulnérabilités de sécurité dans l'ensemble du parc technologique d'une organisation. Elle transforme les données brutes de vulnérabilités en réduction actionnable du risque.
Un programme mature va bien au-delà de l'execution d'un scanner — il englobe la découverte des actifs, la hiérarchisation basee sur le risque, les flux de remédiation, la gestion des exceptions, le suivi des metriques et le reporting de conformité.
Le cycle de vie de la gestion des vulnérabilités
| Phase | Activites | Resultats cles |
|---|
| 1. Decouverte des actifs | Maintenir un inventaire complet et à jour de tous les matériels, logiciels et actifs cloud | Registre des actifs avec niveaux de criticité |
| 2. Identification des vulnérabilités | Executer des analyses authentifiees, examiner les avis de sécurité, surveiller les flux de menaces | Resultats bruts de vulnérabilités |
| 3. Hierarchisation | Noter par CVSS + criticité de l'actif + exploitabilite + contexte metier | File de remédiation hierarchisee |
| 4. Remediation | Appliquer les correctifs, configurer, mettre à jour ou appliquer des contrôles compensatoires | Vulnérabilités fermees, enregistrements de changements |
| 5. Verification | Re-analyser pour confirmer les corrections, valider les contrôles compensatoires | Preuves de vérification |
| 6. Reporting | Tableaux de bord de metriques, analyse des tendances, rapports de conformité | Rapports pour la direction et les auditeurs |
| 7. Gouvernance | Revue des politiques, ajustements des SLA, évaluation de la maturité du programme | Politiques mises à jour, ameliorations des processus |
Scoring et hiérarchisation des vulnérabilités
Niveaux de severite CVSS
| Severite | Score CVSS | SLA de remédiation typique | Exemples |
|---|
| Critique | 9.0 – 10.0 | 24-72 heures | Execution de code a distance, contournement d'authentification |
| Eleve | 7.0 – 8.9 | 7-14 jours | Escalade de privileges, injection SQL |
| Moyen | 4.0 – 6.9 | 30-60 jours | Cross-site scripting, divulgation d'informations |
| Faible | 0.1 – 3.9 | 90 jours | Problemes de configuration mineurs, bugs a faible impact |
| Informationnel | 0.0 | Au mieux | Recommandations de bonnes pratiques |
Hierarchisation basee sur le risque
Le CVSS seul est insuffisant. Combinez ces facteurs pour une hiérarchisation efficace :
| Facteur | Description | Poids |
|---|
| Score de basé CVSS | Severite intrinseque de la vulnerabilite | Base |
| Exploitabilite | Un exploit connu existe-t-il ? Est-il activement exploite ? (catalogue CISA KEV) | Eleve |
| Criticite de l'actif | Quelle est l'importance du système affecte pour l'activité ? | Eleve |
| Exposition | L'actif est-il expose sur Internet ou uniquement interne ? | Moyen |
| Sensibilite des données | Quel niveau de classification des données traite-t-il ? | Moyen |
| Contrôles compensatoires | Des contrôles attenuants sont-ils déjà en place ? | Ajustement |
Types d'analyses
| Type d'analyse | Objectif | Frequence | Outils |
|---|
| Analyse de vulnérabilités réseau | Decouvrir les CVE connus dans les OS et services | Minimum hebdomadaire | Nessus, Qualys, Rapid7 InsightVM |
| Analyse authentifiee | Analyse approfondie avec identifiants système pour des resultats precis | Hebdomadaire | Identiques ci-dessus, avec identifiants |
| Analyse d'applications web (DAST) | Tester les applications web en cours d'execution pour le Top 10 OWASP | Par release + mensuellement | OWASP ZAP, Burp Suite, Acunetix |
| Analyse statique (SAST) | Analyser le code source pour trouver des vulnérabilités | A chaque commit (CI/CD) | SonarQube, Checkmarx, Semgrep |
| Analyse de composition logicielle (SCA) | Identifier les dépendances open source vulnerables | A chaque build | Snyk, Dependabot, Grype |
| Analyse d'images de conteneurs | Analyser les images de conteneurs pour les CVE connus | A chaque build + analyse du registre | Trivy, Grype, Prisma Cloud |
| Analyse de configuration cloud | Verifier l'infrastructure cloud pour les mauvaises configurations | Continue | Outils CSPM, Prowler |
| Analyse d'Infrastructure as Code | Analyser les templates IaC avant le deploiement | A chaque commit | Checkov, tfsec, KICS |
Construire un programme de gestion des vulnérabilités
Composants essentiels
| Composant | Description | Indicateur de maturité |
|---|
| Politique | Politique documentée de gestion des vulnérabilités avec périmètre, roles et SLA | Approuvee par la direction, revisee annuellement |
| Inventaire des actifs | Inventaire complet et classifie de tous les actifs | Decouverte automatisee, mise à jour en continu |
| Couverture d'analyse | Tous les actifs analyses selon le calendrier | >95 % de couverture, analyses authentifiees |
| Cadre de hiérarchisation | Approche basee sur le risque au-delà du CVSS brut | Scoring contextuel avec contribution metier |
| Flux de remédiation | Integration ticketing, attribution, suivi | Creation automatique de tickets, suivi des SLA |
| Gestion des exceptions | Processus formel d'acceptation du risque | Documente, limite dans le temps, approuve |
| Metriques et reporting | KPI suivis et rapportes a la direction | Tableau de bord avec analyse des tendances |
| Amelioration continue | Revues regulieres du programme et évaluations de maturité | Scoring de maturité annuel |
Metriques cles
| Metrique | Ce qu'elle mesure | Objectif |
|---|
| Temps moyen de remédiation (MTTR) | Nombre moyen de jours entre la découverte et la correction | Critique <3 jours, Eleve <14 jours |
| Couverture d'analyse | % des actifs analyses selon le calendrier | >95 % |
| Densite de vulnérabilités | Vulnérabilités par actif ou pour 1 000 lignes de code | Tendance a la baisse |
| Taux de respect des SLA | % de vulnérabilités corrigées dans les SLA | >90 % |
| Vulnérabilités en retard | Nombre de vulnérabilités au-delà du SLA | Tendance a la baisse |
| Nombre d'exceptions de risque | Nombre d'exceptions de risque ouvertes | Stable ou en baisse |
| Taux de recurrence | Vulnérabilités qui reapparaissent apres correction | <5 % |
Exigences de conformité
Correspondance avec les référentiels
| Exigence | ISO 27001 | SOC 2 | NIS2 | DORA | PCI DSS |
|---|
| Analyse de vulnérabilités | A.8.8 | CC7.1 | Art. 21(2)(e) | Art. 9(2) | Req. 11.3 |
| Gestion des correctifs | A.8.8 | CC7.1 | Art. 21(2)(e) | Art. 9(2) | Req. 6.3.3 |
| Hierarchisation basee sur le risque | A.8.8 | CC3.2 | Art. 21(2)(a) | Art. 9(1) | Req. 6.3.1 |
| Suivi de la remédiation | A.8.8 | CC7.2 | Art. 21(2)(e) | Art. 9(2) | Req. 11.3.3 |
| Gestion des exceptions | A.5.1 | CC3.2 | Art. 21(1) | Art. 9(1) | Req. 6.3.2 |
| Reporting a la direction | A.5.1 | CC4.2 | Art. 20 | Art. 13 | Req. 12.4 |
Preuves d'audit
| Type de preuve | Description | Referentiel |
|---|
| Politique de gestion des vulnérabilités | Politique documentée avec SLA et voies d'escalade | Tous les référentiels |
| Rapports d'analyse | Resultats d'analyses réguliers montrant la couverture et les resultats | Tous les référentiels |
| Tickets de remédiation | Tickets Jira/ServiceNow avec horodatages et statuts | ISO 27001, SOC 2 |
| Rapports de respect des SLA | Tableau de bord montrant le % corrige dans les SLA | Tous les référentiels |
| Registre des exceptions | Acceptations de risque documentées avec approbations | Tous les référentiels |
| Rapports de tendances | Comptes de vulnérabilités et MTTR mois par mois | SOC 2, NIS2 |
| Resultats de tests d'intrusion | Tests d'intrusion annuels validant les contrôles | ISO 27001, NIS2, DORA |
Erreurs courantes
| Erreur | Impact | Correction |
|---|
| Analyser sans flux de remédiation | Accumulation de vulnérabilités non corrigées | Integrer avec le ticketing, attribuer la propriete |
| Traiter toutes les vulnérabilités de manière egale | Fatigue des alertes, ressources mal allouees | Mettre en oeuvre la hiérarchisation basee sur le risque |
| Analyses non authentifiees uniquement | Manquer 40 a 60 % des vulnérabilités | Deployer l'analyse authentifiee |
| Pas d'inventaire des actifs | Lacunes d'analyse inconnues | Construire et maintenir une découverte automatisee des actifs |
| Suivi manuel dans des tableurs | Echecs d'audit, perte de visibilité | Utiliser une plateforme dediee de gestion des vulnérabilités |
| Ignorer les charges de travail cloud et conteneurs | Angles morts croissants | Etendre l'analyse au cloud, aux conteneurs et a l'IaC |
| Pas de SLA définis | Aucune responsabilisation pour la remédiation | Documenter et imposer des SLA basés sur la severite |
Comment Orbiq accompagne la gestion des vulnérabilités
Orbiq vous aide a demontrer vos contrôles de gestion des vulnérabilités aux clients et auditeurs :
- Collecte de preuves — Centralisez les rapports d'analyse, les tickets de remédiation et les metriques de SLA
- Surveillance continue — Suivez les KPI de gestion des vulnérabilités dans votre environnement
- Trust Center — Partagez votre posture de gestion des vulnérabilités via votre Trust Center
- Correspondance avec les référentiels — Associez les contrôles de gestion des vulnérabilités aux exigences ISO 27001, SOC 2, NIS2 et DORA
- Preparation aux audits — Packages de preuves pre-elabores pour la revue par les auditeurs
Pour aller plus loin