Surveillance
Surveillance continue des vulnérabilités des produits livrés
La surveillance continue des vulnérabilités consiste à recontrôler les composants de chaque produit que vous prenez encore en charge au regard des données de vulnérabilités à mesure qu’elles évoluent, et pas seulement quand votre code change. Une analyse propre au moment de la sortie devient obsolète à mesure que de nouveaux avis de sécurité paraissent : c’est la surveillance qui transforme une analyse ponctuelle en gestion continue des vulnérabilités, comme l’attend le règlement sur la cyberrésilience (Cyber Resilience Act).
Offre Free, sans carte bancaire.
Pourquoi une analyse propre devient-elle obsolète ?
Une analyse de vulnérabilités répond à une question, à un instant donné : quelles vulnérabilités connues affectent ces versions de composants, d’après les données des avis de sécurité du jour. De nouveaux enregistrements CVE sont publiés chaque jour, et les enregistrements existants sont révisés à mesure que les versions affectées, les correctifs et les preuves d’exploitation sont connus. Votre produit n’a pas besoin de changer pour que son risque change : une image firmware sans problème connu en mars peut porter une faille activement exploitée en juin, avec exactement les mêmes octets sur chaque appareil déployé.
C’est pourquoi le CRA conçoit la gestion des vulnérabilités comme un processus plutôt que comme un événement. L’annexe I, partie II, demande aux fabricants de recenser et de documenter les vulnérabilités et les composants, de corriger sans retard et de soumettre régulièrement le produit à des tests et examens de sécurité efficaces. Ces obligations courent pendant toute la période d’assistance, que l’article 13, paragraphe 8, fixe à cinq ans au minimum, sauf si le produit est censé être utilisé moins longtemps.
Réanalyser les versions livrées plutôt que la branche principale
Analyser la branche principale à chaque modification est utile, mais cela vous renseigne sur le code que vous livrerez ensuite, pas sur le code qu’exécutent vos clients. Les appareils sur le terrain exécutent des versions publiées : la 2.3 sur certains, la 2.4 sur d’autres, et une longue traîne d’unités jamais mises à jour. Chaque version prise en charge a besoin de sa propre liste de composants, recontrôlée au regard des données actuelles des avis de sécurité, car la question « nos clients sont-ils exposés ? » trouve sa réponse dans la version, pas dans la branche.
Conservez une nomenclature des logiciels (SBOM) par version publiée, rattachée au numéro de version que voient les utilisateurs. Quand un nouvel avis correspond, vous pouvez alors dire quelles versions sont affectées et vers quelle version corrigée orienter les clients. Pour les logiciels, l’article 13, paragraphe 10, du CRA vous permet de ne corriger que la dernière version substantiellement modifiée, à condition que les utilisateurs des versions antérieures puissent y passer gratuitement et sans frais supplémentaires pour adapter leur environnement.
Rapprochement par SBOM : surveiller sans reconstruire
Au lieu de reconstruire et de réanalyser le produit, vous conservez le SBOM produit lors de la sortie et vous comparez régulièrement les noms et les versions de ses composants aux bases d’avis de sécurité comme OSV.dev, la NVD et la base de données européenne des vulnérabilités (EUVD) de l’ENISA. Comme le SBOM décrit ce qui a été livré, une correspondance porte sur des versions réellement livrées. Le résultat ne vaut que ce que vaut le SBOM : les composants sans version ni identifiant de paquet ne peuvent pas être mis en correspondance de façon fiable, et le code embarqué (vendored) ou lié statiquement que le SBOM ne recense pas reste invisible.
Ce rapprochement complète une réanalyse complète périodique, sans la remplacer. Une analyse complète bénéficie d’une meilleure détection des composants et de nouvelles règles d’analyse, et repère des problèmes qui ne sont pas du tout des vulnérabilités de composants, comme des secrets commités ou des erreurs de configuration : lancez-en une à chaque version et chaque fois que le build change.
Comment KEV et EPSS aident-ils à prioriser les nouvelles vulnérabilités ?
La surveillance produit un flux de correspondances ; la priorisation décide lesquelles traiter en premier. Deux signaux publics y aident. Le catalogue Known Exploited Vulnerabilities (KEV) de la CISA recense les vulnérabilités qui ont un identifiant CVE, des preuves fiables d’exploitation dans la nature et des consignes de remédiation claires. L’Exploit Prediction Scoring System (EPSS) du FIRST publie chaque jour, pour chaque CVE, une probabilité estimée qu’elle soit exploitée dans la nature au cours des 30 prochains jours. Le CVSS décrit la gravité qu’aurait une exploitation ; KEV et EPSS indiquent si elle a eu lieu ou quelle est sa probabilité.
Combinez-les avec votre propre contexte. Une vulnérabilité listée dans le KEV et présente dans un composant que vous livrez devrait être triée le jour même : le code vulnérable est-il présent et atteignable dans votre build, et quelles versions le contiennent ? Consignez le raisonnement dans tous les cas ; une décision « non affecté » documentée est aussi utile à un auditeur qu’un correctif.
Comment la surveillance alimente-t-elle les notifications de l’article 14 du CRA ?
Depuis le 11 septembre 2026, l’article 14 du CRA impose aux fabricants de notifier les vulnérabilités activement exploitées contenues dans leurs produits au CSIRT désigné comme coordinateur et à l’ENISA, via la plateforme unique de signalement de l’ENISA. L’alerte précoce est due dans les 24 heures suivant la prise de connaissance par le fabricant, la notification de vulnérabilité dans les 72 heures, et le rapport final au plus tard 14 jours après qu’une mesure corrective ou d’atténuation est disponible. En vertu de l’article 69, paragraphe 3, l’article 14 couvre aussi les produits relevant du champ d’application mis sur le marché avant le 11 décembre 2027.
Le délai court à partir de la prise de connaissance : la surveillance est donc l’amont de votre processus de notification. Une nouvelle entrée KEV qui correspond à un composant d’un produit publié est un signal qu’une personne doit évaluer rapidement : s’agit-il d’une vulnérabilité activement exploitée contenue dans votre produit, c’est-à-dire existe-t-il des preuves fiables qu’un acteur malveillant l’a exploitée dans un système sans l’autorisation de son propriétaire ? Quelle que soit la réponse, l’article 13, paragraphe 7, attend de vous que vous documentiez les vulnérabilités dont vous prenez connaissance et que vous mettiez à jour l’évaluation des risques, le cas échéant.
Comment fixer une cadence de surveillance et des responsables
La surveillance échoue en silence quand personne n’est responsable de ce qu’elle produit. Mettez par écrit la cadence et les responsables, dans le cadre de la politique de gestion des vulnérabilités dont vous avez de toute façon besoin pour le CRA, et testez le circuit une fois avant de vous y fier. Une base à adapter à vos produits :
- Un responsable par produit, avec un suppléant, qui examine les nouvelles correspondances chaque jour ouvré et les correspondances KEV le jour même.
- Un registre des versions prises en charge, chacune avec son SBOM et sa date de fin d’assistance.
- Un rapprochement de chaque version prise en charge au moins une fois par jour, et une réanalyse complète à chaque version ou changement de build.
- Un ordre de tri : d’abord les vulnérabilités connues comme exploitées, puis les scores EPSS élevés, puis la gravité CVSS, en tenant compte de l’exposition.
- Une personne capable d’approuver une notification au titre de l’article 14 dans les 24 heures, week-ends compris.
- Un registre des décisions pour chaque correspondance (affecté, non affecté, corrigé dans une version désignée), avec ses éléments de preuve.
Disponible aujourd’hui dans KROMSE
Sur les offres payantes, KROMSE recontrôle le dernier SBOM de chaque produit au regard des données actuelles des avis de sécurité et affiche les nouvelles correspondances dans le produit.
- Toutes les 6 heures, le dernier SBOM de chaque produit est recontrôlé auprès d’OSV.dev, pour 5 produits au maximum par espace de travail et par cycle, à tour de rôle.
- Les nouvelles correspondances apparaissent sous forme de notifications dans l’application, et un bouton « Run monitoring now » lance un contrôle à la demande.
- Les constats dotés d’un identifiant CVE sont enrichis avec CISA KEV, FIRST EPSS, la NVD et la base de données européenne des vulnérabilités (EUVD) de l’ENISA.
- Chaque analyse produit des SBOM CycloneDX et SPDX, et vous pouvez importer les SBOM dont vous disposez déjà.
- Sur les offres payantes, des projets internes de rapports au titre de l’article 14 du CRA pour les étapes à 24 heures, à 72 heures et finale, au format PDF, à faire approuver par une personne ; KROMSE ne les soumet jamais.
- Limites actuelles : vous ne pouvez pas définir votre propre calendrier, la surveillance n’envoie aucun e-mail et elle ne lance pas de réanalyse automatiquement.
Prochainement
Sur la feuille de route, pas encore disponible. Les dates sont des objectifs, pas des promesses ; cette page change le jour où une fonctionnalité est mise en service.
- À venir · T4 2026 (décembre)Surveillance selon votre calendrier, avec des agents IA. Les nouvelles analyses s’exécuteront selon un calendrier que vous définirez, avec des agents IA qui surveilleront les nouveaux avis de sécurité, trieront ceux qui s’appliquent, proposeront des correctifs et prépareront le rapport pour votre revue.
- À venir · T4 2026 (novembre)Correctifs proposés par l’IA, approuvés par une personne. KROMSE proposera des correctifs pour les constats, rédigés avec l’IA et appliqués uniquement après l’approbation d’une personne de votre équipe.
- À venir · T1 2027Envoi à la plateforme unique de signalement de l’ENISA. Une fois qu’une personne aura approuvé une notification au titre de l’article 14, KROMSE l’enverra à la plateforme unique de signalement de l’ENISA.
Questions fréquentes
Quelle est la différence entre l’analyse de vulnérabilités et la surveillance continue des vulnérabilités ?
Une analyse inspecte un produit une fois et liste les vulnérabilités connues de ses composants à ce moment-là. La surveillance continue répète la comparaison à mesure que les données des avis de sécurité évoluent, généralement en rapprochant à nouveau le SBOM de chaque version : vous apprenez ainsi l’existence de nouvelles vulnérabilités dans les produits livrés sans attendre la prochaine modification du code.
À quelle fréquence faut-il recontrôler les produits livrés pour détecter de nouvelles vulnérabilités ?
Aucune législation de l’UE ne fixe d’intervalle. Le CRA exige des tests et examens réguliers et une correction sans retard, et son délai de notification court à partir de la prise de connaissance d’une vulnérabilité activement exploitée : l’intervalle devrait donc vous permettre d’en repérer une en quelques heures, pas en quelques semaines. Un rapprochement du SBOM quotidien ou plus fréquent, complété par une réanalyse complète à chaque version, constitue un point de départ raisonnable.
Une inscription au KEV impose-t-elle une notification au titre de l’article 14 du CRA ?
Pas automatiquement. L’article 14 porte sur les vulnérabilités activement exploitées contenues dans votre produit : il doit exister des preuves fiables qu’un acteur malveillant a exploité la vulnérabilité dans un système sans l’autorisation de son propriétaire. Une entrée KEV est une preuve solide d’exploitation, mais une personne doit encore établir si le code vulnérable se trouve dans votre produit. Dès que vous savez que c’est le cas, le délai de 24 heures court.
La surveillance compte-t-elle pour les produits mis sur le marché avant l’application du CRA ?
Oui, pour la notification. L’article 69, paragraphe 3, rend l’article 14 applicable aux produits relevant du champ d’application mis sur le marché avant le 11 décembre 2027, et l’article 14 s’applique depuis le 11 septembre 2026. La FAQ de la Commission sur le CRA précise que, pour ces produits, les fabricants doivent notifier mais ne sont pas tenus de respecter les autres obligations, comme la gestion des vulnérabilités. Pour repérer une vulnérabilité exploitée dans ces produits, encore faut-il savoir ce qu’ils contiennent.
KROMSE m’envoie-t-il un e-mail quand une nouvelle vulnérabilité concerne mon produit ?
Pas aujourd’hui. Sur les offres payantes, KROMSE recontrôle toutes les 6 heures le dernier SBOM de chaque produit auprès d’OSV.dev, pour 5 produits au maximum par espace de travail et par cycle, à tour de rôle, et affiche les nouvelles correspondances sous forme de notifications dans l’application. La surveillance selon un calendrier que vous définissez, avec des agents IA, figure dans la feuille de route.
Guides associés
Sources
- Règlement (UE) 2024/2847 (règlement sur la cyberrésilience), EUR-Lex
- Commission européenne : FAQ sur la mise en œuvre du règlement sur la cyberrésilience
- ENISA : plateforme unique de signalement (Single Reporting Platform)
- ENISA : base de données européenne des vulnérabilités (EUVD)
- CISA : catalogue Known Exploited Vulnerabilities
- FIRST : Exploit Prediction Scoring System (EPSS)
- OSV : base de données de vulnérabilités open source