Que signifie « aucune vulnérabilité exploitable connue » dans le Cyber Resilience Act ?
Réponse directe
Le Règlement sur la cyberrésilience exige que les produits soient mis sur le marché sans vulnérabilité exploitable connue (annexe I). Il s'agit d'une exigence de qualité à la mise en circulation, distincte de l'obligation séparée de signaler les vulnérabilités activement exploitées par la suite.
Le RCR est technologiquement neutre : il n'impose ni CVSS, ni EPSS, ni aucun modèle de scoring particulier.
Points clés
- L'annexe I exige une mise sur le marché sans vulnérabilité exploitable connue.
- À distinguer d'une « vulnérabilité activement exploitée », déclencheur de signalement à l'article 14 (art. 3, point 42).
- Technologiquement neutre : CVSS, EPSS et le catalogue KEV de la CISA sont des entrées utiles, pas des exigences légales.
- Exige un tri systématique et défendable, pas un chiffre unique.
- La gestion continue des vulnérabilités s'applique après la mise en circulation pendant toute la période de support.
La réponse complète
« Aucune vulnérabilité exploitable connue » est une exigence de qualité à la mise sur le marché : un produit doit être mis à disposition sans faille exploitable connue et avec une configuration sécurisée par défaut (annexe I). Ce n'est pas la même chose que le déclencheur de signalement. Une « vulnérabilité activement exploitée », qui lance le compte à rebours de 24 heures, est une vulnérabilité pour laquelle existe une preuve fiable d'exploitation malveillante en conditions réelles (art. 3, point 42) ; l'obligation de l'annexe I porte sur ce que vous commercialisez, pas seulement sur ce que vous détectez ensuite.
Le RCR est délibérément technologiquement neutre. Il exige une approche systématique et fondée sur les risques pour identifier et traiter les vulnérabilités, mais il ne codifie ni CVSS, ni EPSS, ni le catalogue KEV de la CISA. Les utiliser est pertinent pour démontrer un processus de tri défendable ; affirmer qu'ils sont légalement imposés est incorrect. Le règlement attend une décision documentée, pas un score particulier.
Comment Acuna GRC s’en charge
- Solution
RCR
Suivez chaque vulnérabilité jusqu’à sa correction, gardez la documentation technique RCR, tracez les failles exploitées et réutilisez votre travail NIS2.
- Module
Gestion des vulnérabilités
Les éléments vulnérables remontés par vos scanners, regroupés en un constat par vulnérabilité, avec un responsable et une échéance.
- Module
Intégrations et API
Connectez Acuna GRC aux outils de sécurité, d’identité, de terminaux, RH, cloud, code, scan et ticketing que vous utilisez déjà, avec webhooks et API.
Sources
Cette page explique les règles en termes généraux et ne constitue pas un conseil juridique.
Découvrez comment Acuna GRC le pilote.
Dites-nous vos référentiels et votre équipe. Nous vous montrons comment Acuna GRC pilote le programme.
Hébergé en Suisse, dans l'UE ou aux États-Unis
.png&w=3840&q=75&dpl=dpl_4WWtFHEr9P8wkcdWCGky2WYKjEiM)

