Trouvez les failles exploitées dans vos dépendances
Le 11 septembre, le compte à rebours de 24 h démarre à la connaissance. Voici comment repérer une dépendance activement exploitée.
Une faille sort dans une bibliothèque que vous embarquez. Quelqu’un l’exploite chez un de vos clients. Vous l’apprenez trois jours plus tard, dans un fil de discussion.
À partir de demain, cette situation a un délai attaché pour les fabricants en Europe. Voici comment la voir venir.
Ce qui démarre le 11 septembre
Demain, vendredi 11 septembre, l’article 14 du Cyber Resilience Act s’applique. Si vous apprenez qu’une vulnérabilité de votre produit est activement exploitée, vous devez une alerte précoce sous 24 heures et une notification sous 72 heures. Destinataires : le CSIRT désigné comme coordinateur dans votre État membre, et l’ENISA. La plateforme unique de notification de l’ENISA est prévue pour la même date (article 16).
Le rapport final vient plus tard. 14 jours après la mise à disposition d’une mesure corrective ou d’atténuation.
Le reste du règlement attend le 11 décembre 2027. SBOM, documentation technique, marquage CE, et les amendes de l’article 64. Demain, rien de tout ça n’est exigible.
La question que personne ne pose
Le compte à rebours démarre quand vous en avez connaissance, pas quand une autorité vous écrit. Tout dépend donc d’un seul point. Par quel canal apprenez-vous qu’une faille de votre produit est exploitée ?
Beaucoup de petits éditeurs l’apprennent par hasard, au détour d’un message client ou d’un fil public.
« Activement exploitée » a une définition
Article 3, point 42 : des éléments fiables indiquent qu’un acteur malveillant a exploité la vulnérabilité dans un système, sans l’autorisation du propriétaire.
Toutes les CVE ne remplissent pas ce critère. Une faille publiée dans votre pile, sans preuve d’exploitation, ne déclenche pas le délai de 24 heures. Cette distinction vous évite de lancer la procédure à chaque bulletin de sécurité.
Le catalogue KEV comme signal
CISA publie un catalogue des Known Exploited Vulnerabilities, environ 1 700 entrées. Une entrée y arrive quand une exploitation a été constatée. Ce catalogue ne dit pas le droit européen. Il donne une liste courte, datée et publique, à croiser avec ce que vous embarquez.
Croiser suppose de savoir ce que vous embarquez. D’où l’inventaire.
L’inventaire d’abord, l’obligation ensuite
L’annexe I, partie II, point 1 demande une nomenclature logicielle couvrant au moins les dépendances de premier niveau. Exigible le 11 décembre 2027. Utile aujourd’hui, pour une raison pratique : sans liste, vous ne pouvez pas répondre en quelques minutes à « est-ce que ce paquet est chez moi ? ».
Prenons un cas concret. Un développeur seul vend une application auto-hébergée en Node. Son fichier de verrouillage contient 400 paquets, presque tous transitifs. Un matin, une faille d’un parseur très répandu passe en exploitation active.
Sans inventaire, il ouvre trois dépôts et cherche à la main. Avec un inventaire régénéré à chaque version, il sait en une minute s’il expédie la version touchée, et dans quel produit. Le délai commence au même instant pour les deux. Un seul a le temps d'écrire l’alerte.
Trois choses à poser avant demain
Un inventaire de dépendances par produit, régénéré à chaque version. Une alerte qui croise cet inventaire avec les failles connues et le catalogue KEV. Une page qui dit qui décide de notifier, qui écrit, et où sont les modèles.
Aucune des trois ne demande un avocat. La troisième tient sur une feuille.
Avant tout ça, le périmètre
Tout ce qui précède suppose que vous êtes fabricant au sens du règlement. Un service utilisé seulement dans un navigateur ne l’est pas (considérant 12). Un projet libre maintenu hors activité commerciale non plus (considérant 18). Une personne seule qui vend un plugin sous son nom, oui (article 3, point 13).
Le test de périmètre pose huit questions et rend une évaluation écrite avec les références d’articles : https://crakit.eu/fr/champ-d-application/
Ce que ça ne fait pas
Aucun outil ne décide à votre place qu’une faille de votre produit est activement exploitée. Le catalogue KEV ne couvre pas tout. Une analyse de dépendances lit les fichiers que vous lui donnez et rien d’autre. Il n’y a pas de surveillance continue là-dedans, et je n’en promets pas.
Ce n’est pas un conseil juridique.
Ce n’est pas un conseil juridique.