Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

Vulnerability SLA

devsecops

Définition

Un Vulnerability SLA (Service Level Agreement) est un accord formel définissant les délais maximaux de remédiation des vulnérabilités découvertes, selon leur criticité. C'est un élément fondamental de la gouvernance de la gestion des vulnérabilités dans un programme DevSecOps mature, transformant des objectifs informels en engagements mesurables et auditables. La définition d'un Vulnerability SLA repose sur plusieurs paramètres : le score CVSS (Common Vulnerability Scoring System) de la vulnérabilité, son exploitabilité réelle dans le contexte (via des données EPSS - Exploit Prediction Scoring System, KEV - Known Exploited Vulnerabilities), l'exposition du système affecté (internet-facing vs. interne), et la sensibilité des données traitées. Un framework de Vulnerability SLA typique définit quatre niveaux : Critique (CVSS ≥9.0 ou CVE exploitée activement) avec un délai de 24h à 7 jours selon l'exposition, Haute (7.0-8.9) avec 30 jours, Moyenne (4.0-6.9) avec 90 jours, et Faible (<4.0) avec 180 jours ou acceptation du risque. Ces délais courent à partir de la date de découverte confirmée et qualifiée, pas de la date de la CVE publique. La mise en place de Vulnerability SLAs nécessite plusieurs prérequis organisationnels. Un processus de découverte et de triage automatisé (SAST, SCA, DAST, scans d'infrastructure), une gouvernance claire sur les propriétaires des systèmes affectés, un système de suivi centralisé (ASPM - Application Security Posture Management), et des processus d'escalade pour les SLA en risque de dépassement. Les dérogations (exceptions) au SLA doivent être documentées et approuvées par le responsable sécurité. Elles incluent des mesures de compensation (WAF, contrôles de détection renforcés, segmentation réseau) et une date d'échéance de remédiation. Un processus de dérogation transparent est préférable à des SLA trop stricts qui seraient systématiquement violés sans visibilité.

Définir les niveaux de criticité et les délais

Un Vulnerability SLA efficace combine le score CVSS avec des données d'exploitabilité contextuelles (EPSS, KEV CISA). Une vulnérabilité CVSS 8.0 sans exploit public sur un système interne non critique peut recevoir un SLA de 60 jours, tandis qu'une CVSS 7.0 avec exploit actif sur un service internet-facing impose un délai de 24-48h. Cette contextualisation évite la paralysie par l'alerte sur des milliers de vulnérabilités à faible risque réel.

Intégration dans les outils de suivi

Les Vulnerability SLAs doivent être intégrés dans les outils de ticketing (Jira, ServiceNow) avec des alertes automatiques en cas de dépassement imminent (à J-5, J-2, J). Les tableaux de bord de conformité SLA, ventilés par équipe et par criticité, permettent un pilotage en temps réel. Des intégrations avec les scanners de vulnérabilités (Snyk, Qualys, Tenable) automatisent la création de tickets et l'assignation aux propriétaires.

Processus de dérogation et mesures compensatoires

Une politique de dérogation formalisée est indispensable pour les cas légitimes : dépendance d'un fournisseur sans patch disponible, impact opérationnel disproportionné d'une correction urgente. La dérogation documente le risque accepté, les mesures compensatoires (WAF rule, détection SIEM renforcée), l'approbateur, et une date d'échéance absolue. Le registre des dérogations est audité trimestriellement.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis