Introduction : Gestion des vulnérabilités fondée sur les risques en vertu de la loi sur la cyber-résilience
Les équipes modernes savent déjà qu'il est impossible de corriger toutes les vulnérabilités. Ce qui compte vraiment, c'est de corriger les bonnes. C'est pourquoi gestion des vulnérabilités basée sur les risques est devenue l'approche privilégiée des équipes DevSecOps. Cependant, dans l'Union européenne, il ne s'agit plus seulement d'une bonne pratique. Loi sur la cyber-résilience introduit des obligations juridiques concrètes, notamment lorsque le logiciel inclut des problèmes répertoriés dans le CISCatalogue des vulnérabilités exploitées connues.
Dans ce nouveau contexte, la priorisation des vulnérabilités passe d'un choix de sécurité à une obligation de conformité. Les équipes doivent prouver qu'elles comprennent quelles vulnérabilités sont activement exploitées et comment elles décident lesquelles corriger en premier.
Gestion des vulnérabilités basée sur les risques et vulnérabilités exploitées connues
La gestion des vulnérabilités basée sur les risques privilégie l'exposition réelle plutôt que la gravité brute. Au lieu de traiter toutes les CVE de la même manière, les équipes établissent des priorités en fonction de leur exploitabilité, de leur accessibilité et de leur impact.
C'est ici que vulnérabilités exploitées connues jouer un rôle central. Lorsqu'une CVE apparaît dans le CISCatalogue des vulnérabilités exploitées connuesCela confirme que les attaquants l'utilisent déjà en situation réelle. Ce signal est bien plus probant qu'un score théorique.
Si vous souhaitez une explication plus détaillée de ce que sont les KEV et comment les identifier, vous pouvez consulter notre article précédent. Vulnérabilités exploitées connues : que corriger en priorité ?Dans cet article, nous nous intéressons à la manière dont les véhicules à haute énergie (KEV) s'intègrent aux modèles de conformité et de priorisation dans le cadre de la Loi sur la cyber-résilience.
Ce que la loi sur la cyber-résilience exige réellement
Le Loi sur la cyber-résilience Elle instaure des obligations de cybersécurité obligatoires pour les produits comportant des éléments numériques vendus dans l'UE. Selon la documentation officielle de l'UE :
- https://www.european-cyber-resilience-act.com/
- https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
Les fabricants doivent :
- Identifier et gérer les vulnérabilités tout au long du cycle de vie du produit
- Empêcher l'expédition de logiciels avec vulnérabilités exploitées connues
- Mettez en œuvre des mesures correctives rapides dès que l'exploitation est constatée. Il convient d'appliquer des mesures correctives rapides dès que l'exploitation est connue.
- Conserver les preuves de la gestion des vulnérabilitéscisdes ions
Autrement dit, une fois qu'une vulnérabilité apparaît dans le CISCatalogue des vulnérabilités exploitées connues, l'ignorer crée risque à la fois sécuritaire et réglementaire.
Qu’est-ce que la loi sur la cyber-résilience (CRA) ?
Le Loi sur la cyber-résilience Il s'agit d'un règlement européen qui définit des exigences obligatoires en matière de cybersécurité pour les logiciels et les produits numériques vendus en Europe. Il impose aux fournisseurs de gérer les vulnérabilités tout au long du cycle de vie du produit et d'éviter de commercialiser des logiciels présentant des failles de sécurité. vulnérabilités exploitées connues.
Liste de vérification de priorisation des vulnérabilités prête pour l'ARC
| Exigence | Ce que l'ARC attend | Meilleures pratiques pour les équipes |
|---|---|---|
| Exploiter la conscience | Empêcher la distribution de logiciels présentant des vulnérabilités connues et exploitées. | Faire correspondre automatiquement les résultats aux CISCatalogue des vulnérabilités exploitées connues |
| priorisation basée sur les risques | Concentrez-vous sur les vulnérabilités qui créent un risque réel pour la sécurité. | Combinez les KEV, les EPSS, la portée et l'exposition des actifs |
| Remédiation en temps opportun | Appliquez les correctifs sans délai injustifié dès que l'exploitation de la faille est connue. | Définissez des SLA de correction immédiate pour les KEV accessibles et appliquez-les dans CI/CD |
| Surveillance continue | Gérer les vulnérabilités tout au long du cycle de vie du produit | Effectuez des analyses continues du code, des dépendances et pipelines |
| Contrôles de libération | Évitez de commercialiser des produits présentant des failles de sécurité exploitées. | Bloquer les fusions ou les déploiements lorsque les KEV affectent le code accessible |
| Decistraçabilité des ions | Démontrer comment la vulnérabilitécisDes ions ont été créés | Conservez les journaux d'audit pour la détection, la priorisation et les actions correctives. |
| Intégration pour développeurs | Les mesures de sécurité ne doivent pas perturber les flux de développement. | Priorisation de surface directement dans pull requests et CI pipelines |
| Responsabilité du cycle de vie | Maintenir la sécurité après la publication | Suivi des modifications KEV et EPSS pour les versions livrées |
Pourquoi les KEV sont essentielles à la conformité aux CRA
Le CISCatalogue des vulnérabilités exploitées connues Cette liste répertorie les vulnérabilités CVE déjà exploitées par des attaquants. Autrement dit, elle lève toute ambiguïté dans la priorisation.
Au lieu de se demander « Cela pourrait-il être exploité ? », les équipes doivent désormais se poser une question beaucoup plus directe :
« Cette faille est-elle déjà exploitée, et allons-nous quand même la mettre en œuvre ? »
En vertu de la loi sur la cyber-résilience, cette distinction a une importance juridique. Par conséquent, les vulnérabilités clés (KEV) deviennent le principal facteur déclenchant les accords de niveau de service (SLA) de remédiation et le blocage des mises en production. Dans ce contexte, la gestion des vulnérabilités basée sur les risques s'aligne naturellement sur les exigences réglementaires.
Les systèmes CVSS, EPSS et KEV ont des objectifs différents.
Pour établir les priorités correctement, les équipes doivent d'abord comprendre ce que chaque signal représente réellement.
- CVSS montre un impact potentiel
- EPSS estimations de la probabilité d'exploitation
- CISCatalogue des vulnérabilités exploitées connues confirme que l'exploitation a déjà lieu.
Prises individuellement, chaque mesure peut induire en erreur. Cependant, lorsqu'elles sont utilisées conjointement, les équipes obtiennent un contexte beaucoup plus clair. C'est pourquoi la combinaison de ces signaux constitue le fondement d'une gestion efficace des vulnérabilités basée sur les risques.
Gestion des vulnérabilités basée sur les risques en pratique
En pratique, un modèle de priorisation basé sur les risques suit un flux clair et reproductible.
- Détecter les vulnérabilités dans le code et ses dépendances
- Vérifiez les correspondances avec le CISCatalogue des vulnérabilités exploitées connues
- Évaluer la probabilité d'exploitation à l'aide de l'EPSS
- Vérifiez l'accessibilité dans votre application ou pipeline
- Appliquer les règles de remédiation en fonction de l'exposition et du rôle du produit
Par conséquent, les équipes cessent de considérer les listes de vulnérabilités comme des tâches statiques et commencent à les traiter comme des plans de sécurité concrets.cisdes ions.
Différents modèles de priorisation utilisés aujourd'hui par les équipes
Toutes les équipes n'accordent pas la même importance aux risques. En général, nous observons trois modèles communs dans les environnements réels.
1. Modèle de priorité à la gravité
Les équipes corrigent les problèmes en se basant uniquement sur le CVSS.
Ce modèle est facile à adopter. Cependant, il génère des interférences et ne répond pas aux exigences de la loi sur la cyber-résilience.
2. Modèle basé sur la vraisemblance
Les équipes s'appuient sur EPSS pour prédire les prochaines failles que les attaquants pourraient exploiter.
Cette approche permet d'améliorer la concentration. Malgré cela, elle ne permet toujours pas de déceler les vulnérabilités que les attaquants exploitent déjà.
3. Modèle sensible à l'exploitation
Les équipes combinent l'EPSS avec le CISCatalogue des vulnérabilités exploitées connues et contexte technique.
À l'inverse, ce modèle est plus adapté à la gestion des vulnérabilités basée sur les risques et correspond directement aux obligations des agences de notation de crédit.
Comment Xygeni met en œuvre la priorisation des CRA Ready
Xygeni aide les équipes à intégrer la réglementation dans leur flux de travail quotidien.
plutôt que ne comptant que sur dashboards, Xygeni applique decisdes zones précises où se produisent les modifications de code. Par conséquentLa priorisation devient alors automatique et cohérente.
Les fonctionnalités clés incluent :
- Corrélation automatique avec le CISCatalogue des vulnérabilités exploitées connues
- Score de probabilité d'exploitation basé sur l'EPSS
- Analyse de la portée pour confirmer l'exposition réelle
- Guardrails ce blocage fusionne ou libère lorsque les KEV affectent le code accessible
- Correction automatisée via une solution sécurisée pull requests
- Journaux d'audit complets à titre de démonstration Loi sur la cyber-résilience la conformité
En résumé, les équipes ne se contentent pas de constater les risques. Elles agissent en conséquence de manière reproductible et vérifiable.
Exemple de développeur à développeur : un KEV bloque une publication
Imaginez qu'une mise à jour de dépendance introduise une CVE.
- La vulnérabilité apparaît dans le CISCatalogue des vulnérabilités exploitées connues
- Xygeni le détecte pendant le pull request
- L'analyse d'accessibilité confirme que le chemin d'exécution du code
- Guardrails bloquer la fusion automatiquement
- Le bot propose une mise à jour sécurisée et effectue des tests
Le développeur résout le problème dans le même processus. La version reste conforme. Aucune réunion n'est nécessaire.
Autrement dit, il s'agit d'une gestion des vulnérabilités basée sur les risques, appliquée précisément là où les développeurs travaillent déjà.
Pourquoi cela est important au-delà de la conformité
Bien que le Loi sur la cyber-résilience Ce changement a des retombées encore plus importantes.
Les équipes qui privilégient l'utilisation des KEV, des EPSS et du contexte :
- Réduire la fatigue des alertes
- Réduire le temps de réparation
- Évitez les pansements d'urgence
- Déployez des logiciels plus sûrs en toute confiance
Globalement, la conformité découle naturellement d'une gestion de la sécurité menée correctement.
En conclusion : L’ARC rend obligatoire la gestion fondée sur les risques
Le Loi sur la cyber-résilience Cela officialise ce que les équipes de sécurité ont déjà appris à leurs dépens : toutes les vulnérabilités n’ont pas la même importance.
Le CISCatalogue des vulnérabilités exploitées connues Ce document décrit les techniques utilisées actuellement par les attaquants. EPSS prédit leurs futures techniques. Le contexte indique si vous êtes concerné.
Ensemble, ils forment le moderne gestion des vulnérabilités basée sur les risques.
Xygeni aide les équipes à appliquer ce modèle de manière continue, automatique et d'une façon réellement acceptée par les développeurs.
À propos de l’auteur
Écrit par Fatima SaidResponsable marketing de contenu spécialisée en sécurité des applications chez Xygeni Sécurité.
Fátima crée du contenu sur la sécurité des applications, adapté aux développeurs et basé sur la recherche. ASPMet DevSecOps. Elle traduit des concepts techniques complexes en informations claires et exploitables qui relient l'innovation en cybersécurité à l'impact commercial.
