TL; DR
La plupart des listes de vulnérabilités indiquent ce qui pourrait mal tourner. CISUn catalogue KEV vous indique ce qui ne va pas en ce moment. Les vulnérabilités exploitées connues (KEV) sont des CVE dont l'exploitation active en conditions réelles est confirmée. CISL'organisme A tient à jour le catalogue officiel et fixe les délais de correction pour les agences fédérales par le biais de la directive opérationnelle contraignante 22-01. La plupart des organisations privées utilisent la même liste pour faire le tri parmi les alertes et identifier ce qui doit réellement être corrigé en premier.
CVSS, EPSS et KEV répondent à trois questions différentes. Le score CVSS mesure la gravité théorique : quelle pourrait être la gravité de la situation ? Le score EPSS prédit la probabilité d'exploitation dans les 30 jours : quelle est la probabilité que cette vulnérabilité soit ciblée ? Le score KEV confirme l'exploitation active : est-elle actuellement attaquée ? Une vulnérabilité avec un score CVSS modéré, un score EPSS élevé et une étiquette KEV est plus urgente qu'une vulnérabilité avec un score CVSS critique sans preuve d'exploitation. Ces trois indicateurs sont complémentaires et non interchangeables.
Un risque clé dans votre dépendance n'est pas un risque théorique — il a une date limite. Les KEV impliquent fréquemment des composants, des frameworks, des conteneurs et des éléments tiers. CI/CD des dépendances que les équipes considèrent comme sûres. L'exploitation de la vulnérabilité CVE-2023-4966 (CitrixBleed) a été confirmée quelques jours seulement après sa divulgation. La vulnérabilité CVE-2024-1086 a été récupérée par des groupes de ransomware peu après son inscription au catalogue KEV. standard La fenêtre de correction pour les KEV exposés à Internet est de 1 à 3 jours, et non le cycle de correctifs habituel.
Cet article traite de : Que sont les KEV et en quoi diffèrent-elles des CVE, CVSS et EPSS ? Comment construire un flux de travail de priorisation autour des KEV ? CISUn catalogue ; et comment Xygéni automatise la corrélation des KEV, l'application des garde-fous et la remédiation sur l'ensemble du spectre CI/CD pipelines — y compris une politique de garde-fous YAML fonctionnelle.
Que sont les vulnérabilités exploitées connues (KEV) ?
Chaque scanner de vulnérabilités produit des résultats classés selon la gravité CVSS. Le problème est que CVSS mesure l'impact théorique, et non l'exploitation active. CISUn catalogue des vulnérabilités connues et exploitées (KEV) résout un problème différent et plus urgent : il répertorie les CVE actuellement exploitées par les attaquants, avec les dates limites de correctifs. Pour toute équipe cherchant à déterminer les priorités de correction, il s’agit du signal le plus exploitable.
Vulnérabilités connues exploitées (KEV) Ces Des vulnérabilités répertoriées dans la base de données CVE ont été confirmées comme étant exploitées en production.L'Agence américaine de cybersécurité et de sécurité des infrastructures (CISA) maintient l'officiel Catalogue KEV et impose des délais de mise en conformité jusqu'à Directive opérationnelle contraignante 22-01. De nombreuses organisations privées utilisent désormais cette liste pour prioriser les correctifs.
Bien que CVSS Les scores mesurent défaillances impact, les KEV représentent infection exploitation. Autrement dit, ils transforment le « potentiellement exploitable » en « exploité », ce qui exige des SLA plus rapides et une automatisation accrue. guardrails.
KEV vs CVE vs EPSS
Les équipes de sécurité confondent souvent ces termes apparentés. Comprendre la différence est crucial pour une évaluation précise des risques.
| Acronyme | Matériau | Interet |
|---|---|---|
| CVE | NVD | Identifiant unique d'une vulnérabilité divulguée. |
| CVSS | NVD / PREMIER | Mesure la gravité théorique (impact + exploitabilité). |
| EPSS | FIRST.org | Prédit la probabilité d'exploitation dans les 30 jours. |
| Kev | CISA | Confirme l'exploitation en conditions réelles et fixe les délais de correction des problèmes. |
Ensemble, ces systèmes forment une hiérarchie des risques : CVSS indique la gravité potentielle du problème, EPSS indique sa probabilité et Known Exploited Vulnerabilities indique ce qui se produit réellement.
Pour en savoir plus: Score CVSS : Comment fonctionne le score CVSS ? et EPSS vs CVSS : quelle est la différence ?
Pourquoi les KEV sont importantes pour les développeurs et CISOs
Tout d'abord, les KEV mettent en évidence comportement de l'attaquant en directDeuxièmement, elles impliquent fréquemment composants tiers, frameworks, conteneurs ou CI/CD des dépendances que les équipes considèrent comme sûres. Par conséquent., Un correctif tardif peut ouvrir des voies de migration latérale au sein de votre infrastructure de construction et de livraison.
Exemples récents :
- CVE-2024-1086 (Linux nf_tables) : Ajouté au catalogue KEV ; exploité par des groupes de ransomware au milieu de l'année 2024.
- CVE-2023-4966 (CitrixBleed) : Exploitation confirmée quelques jours après sa divulgation ; cycles de correctifs d'urgence imposés dans le monde entier.
Emporter: Les véhicules à énergie contrôlée (KEV) ne sont pas des menaces potentielles, ils sont infection Par conséquent, traitez chaque vulnérabilité exploitée connue comme telle. « réparer maintenant », à moins que l'analyse d'accessibilité ne prouve le contraire.
Comment suivre et prioriser les vulnérabilités exploitées connues
Pour commencer, consultez le site officiel. CISCatalogue des vulnérabilités exploitées connues et marquez toutes les correspondances dans votre scanner de sécurité. Ensuite, utilisez ces informations pour déterminer les corrections à effectuer en priorité. De plus, combinez Vulnérabilités exploitées connues au Résultats EPSS pour éliminer le bruit et se concentrer sur les faiblesses qui affectent réellement votre code en cours d'exécution.
Flux de travail étape par étape :
- Synchroniser les données: Récupérez les dernières mises à jour depuis CISÉtablissez une liste chaque jour et combinez-la avec vos autres flux de données sur les vulnérabilités.
- Résultats de la recherche par étiquette : Étiquetez chaque résultat comme « Exploité connu » lorsque l'identifiant correspond à celui-ci. CISUne liste.
- Vérifier la disponibilité : Vérifiez si le code vulnérable s'exécute effectivement dans votre application ou votre build. pipeline.
- Évaluer l'exploitabilité : Utilisez le EPSS pour déterminer quels autres problèmes pourraient bientôt être ciblés.
- Dates limites de candidature :
- Failles de sécurité exposées sur Internet : correction sous 1 à 3 jours.
- Problèmes internes : réparation sous une semaine.
- Code non utilisé : surveillez-le et vérifiez-le régulièrement.
- Automatiser les réponses : Le système bloque les fusions non sécurisées et ouvre les fusions sécurisées. pull requestset enregistre les exceptions pour s'assurer que les équipes ne manquent rien.
De la prise de conscience à l'action : automatiser les corrections avec Xygeni
En pratique, gérer tout cela manuellement n'est pas viable à grande échelle. Par conséquent, Xygéni connecte directement les vulnérabilités exploitées connues à votre CI/CD Des flux de travail qui transforment les alertes en actions concrètes et guidées.
- Corrélation intelligente : Des correspondances ont été détectées avec les CVE suivantes : CISUne liste et les principaux problèmes à corriger immédiatement à l'intérieur pull requests.
- Accessibilité + Exploitabilité : Confirme si le chemin de code vulnérable s'exécute et établit des liens EPSS données pour précise priorisation.
- Guardrails: Empêche les fusions ou déploiements risqués lorsqu'une faille exploitée affecte des fichiers ou des services sensibles.
- Auto-correction : Ouvre des demandes de fusion sécurisées, vérifie les éventuelles modifications incompatibles et exécute des tests avant la fusion.
- Journaux d'audit : Conserve des registres clairs des réparations effectuées et de leur date, contribuant ainsi aux objectifs de sécurité interne.
En résumé, le renseignement sur les menaces indique ce qui est attaqué, Xygeni garantit que le problème est résolu rapidement, en toute sécurité et automatiquement.
Exemple de politique de garde-fous (YAML)
guardrail:
id: "kev-protection"
description: "Block merges if known exploited vulnerability detected"
conditions:
- match: vulnerability.kev == true
- match: reachability == "reachable"
actions:
- block: merge
- notify: ["slack:#security-alerts", "jira:SEC-OPS"]
- create_pr: true
sla:
critical: 72h
high: 7dCette règle s'applique pas de fusion pour les vulnérabilités connues et exploitées, notifie les canaux concernés et crée automatiquement une demande de fusion de correctif, le tout au sein de votre CI/CD guardrails.
Mini-cas : Prévenir le déploiement d'un véhicule à énergie positive
- Semaine 1 : Une nouvelle bibliothèque open-source passe SAST mais inclut CVE-2023-4966.
- Semaine 2 : La corrélation KEV de Xygeni la détecte dans la dernière version CISUne mise à jour.
- Semaine 3 : Guardrails Interrompre la fusion ; la correction automatique propose une version corrigée.
Résultat: L'équipe a évité d'expédier un vulnérabilité exploitée connue à la production et à la restauration pipeline flux au sein du même sprint.
Xygéni met en corrélation vos CVE ouvertes avec les CISUn catalogue KEV signale automatiquement les vulnérabilités exploitées connues au sein des systèmes. pull requests, impose guardrails qui bloquent les fusions non sécurisées et ouvrent des demandes de fusion corrective avec validation intégrée des changements cassants.
