Sept services, tous en ligne.

Analyse du firmware

Vous déposez le firmware compilé, ou la liste des composants issue de votre système de build, et la plateforme l'analyse d'elle-même : ce que contient le produit, dans quelles versions, et quelles vulnérabilités connues il présente. Si vous vendez sous votre marque et n'avez pas le firmware, demandez-le à l'entreprise qui fabrique l'appareil pour vous. Mesuré sur l'image publique d'OpenWrt 25.12.5 en octobre 2026 : la liste des composants a obtenu 9,6 sur 10 aux contrôles BSI TR-03183-2, contre 2,5 en sortie directe du scanner, et 610 vulnérabilités connues ont été rattachées à ses composants.

• Une nomenclature des logiciels (SBOM) au format CycloneDX, avec une note de qualité
• Les vulnérabilités connues de chaque composant, classées par gravité et selon qu'elles sont exploitées ou non
• La catégorie CRA probable du produit, établie avec la même logique que l'autodiagnostic
• Un rapport technique sur la plateforme

Veille quotidienne

Nous tenons à jour la liste des composants de chaque version et la comparons chaque jour aux sources publiques de vulnérabilités et aux catalogues de vulnérabilités exploitées (le KEV de la CISA et la base européenne des vulnérabilités de l'ENISA, l'EUVD).

• Une alerte dès que nous repérons une vulnérabilité exploitée qui touche un composant de votre produit
• Une décision écrite sur chaque vulnérabilité pertinente : si elle vous concerne, et pourquoi
• Un récapitulatif régulier de ce qui a été examiné
• Une trace montrant que vous assuriez la veille, pour une autorité ou un client qui la demande

Notifications via la plateforme de l'ENISA

Quand vous devez notifier, le temps presse. La plateforme ouvre un dossier avec les délais de 24 heures, de 72 heures et du rapport final, et prépare chaque champ de la plateforme unique de signalement de l'ENISA en anglais, avec une traduction dans votre langue en regard, pour que vous les relisiez. La notification part au CSIRT de l'État membre où se trouve votre établissement principal (art. 14.7). La plateforme de l'ENISA n'a pas d'API : une personne soumet donc chaque notification, rien n'est automatique.

alerte précoce

24 h

notification

72 h

rapport final

14 joursaprès la mise à disposition du correctif ; pour un incident grave, un mois après la notification

• Des brouillons de l'alerte précoce (24 h), de la notification (72 h) et du rapport final
• Un avis destiné à vos utilisateurs concernés (art. 14.8)
• La soumission par votre représentant principal, la personne inscrite pour votre entreprise sur la plateforme de l'ENISA, ou par nous en tant que représentant secondaire, avec votre autorisation
• Tant que votre représentant principal n'a pas été vérifié et ne nous a pas invités, c'est lui qui soumet, avec notre texte
• Un journal indiquant qui a soumis chaque notification, et quand

Canal de signalement des vulnérabilités

Pour les unités mises sur le marché à partir du 11 décembre 2027, le CRA exige une politique de divulgation coordonnée des vulnérabilités et une adresse où l'on peut vous signaler des failles. Nous mettons en place les deux et recevons les signalements pour vous.

• Une politique de divulgation en anglais et dans votre langue
• Un fichier security.txt sur votre site, vérifié chaque semaine
• Une adresse de signalement sur votre domaine, qui nous parvient
• Une première réponse au chercheur, et une proposition pour vous

Test de sécurité automatisé du cloud, du web et de l'API

Il examine la partie de votre produit qui vit sur internet : le cloud, le site web et l'API avec lesquels communiquent l'appareil et l'application. Claude, le modèle d'IA d'Anthropic, le réalise avec un jeu fixe d'outils non destructifs, uniquement sur des domaines dont vous avez prouvé qu'ils sont à vous par un enregistrement DNS ou un fichier sur votre site, et uniquement avec votre autorisation signée en ligne, dans laquelle vous fixez le périmètre et la plage horaire. Aujourd'hui, le test est passif : il examine uniquement ce que montrent des requêtes normales. L'analyse des ports et les contrôles par modèles (templates) viendront plus tard.

contrôles passifs aujourd'hui : DNS · certificats et TLS · en-têtes · e-mail · security.txt · sous-domaines

• Les constats avec leur gravité (CVSS 4.0) et la façon de les corriger
• Chaque constat rattaché aux exigences de l'annexe I du CRA
• Un rapport sur la plateforme
• Un second passage une fois les corrections faites

Vérification des fournisseurs et des produits

Pour chaque référence que vous importez, nous vérifions ce que l'article 19 du CRA exige avant la mise en vente, et nous conservons les preuves au cas où une autorité les demanderait. Vos fournisseurs peuvent déposer documents et firmware directement sur la plateforme à partir d'une invitation que vous leur envoyez, sur une page en anglais.

• La liste de contrôle de l'art. 19 pour chaque référence, avec les preuves et leur état
• L'analyse du firmware : ce qu'il contient et quelles vulnérabilités connues il présente, pour voir si le produit correspond à ses documents
• Un verdict technique sur chaque référence
• La déclaration UE de conformité et le dossier, archivés pendant dix ans
• La veille des références tant que vous les vendez, avec une alerte si une vulnérabilité grave apparaît

Vérification rapide avant achat

Avant de passer commande, vous nous envoyez la documentation et le firmware d'un modèle, et nous vous donnons un verdict technique qui indique si, avec ce dont vous disposez, vous pourrez le vendre à partir du 11 décembre 2027 : apte, avec réserves ou inapte, et pourquoi.

• Un verdict en trois niveaux, avec ses motifs
• Ce qui manque au fournisseur, pour que vous puissiez le lui demander
• Les vulnérabilités connues du firmware