Sécurité et conformité produit

Canal de signalement de vulnérabilités pour NIS2 et CRA

Un canal de signalement de vulnérabilités pour NIS2 et CRA donne à un chercheur extérieur un seul endroit sûr pour signaler une faille dans votre produit. Le règlement sur la cyberrésilience en fait une obligation légale pour les fabricants à partir du 11 décembre 2027. NIS2 ne l'impose pas, et les référentiels d'audit que réclament les acheteurs non plus.

11 sept. 2026

Vous devez signaler une vulnérabilité activement exploitée à un CSIRT national

11 déc. 2027

Vous devez publier une politique de divulgation et une adresse de contact pour chaque nouveau produit

Signalements entrants et signalements sortants

Deux obligations différentes portent le même nom. Pour les distinguer, demandez dans quel sens circule le signalement.

Un ingénieur sécurité relit du code sur deux écrans dans un bureau calme
Entrant, un chercheur vous signale une faille

Une personne extérieure à votre entreprise trouve une faille dans votre produit et vous en informe. C'est la divulgation coordonnée de vulnérabilités. Il vous faut une adresse publiée pour la recevoir, une politique écrite et un moyen sûr de répondre.

Sortant, vous signalez à l'État

Vous informez une équipe nationale de cybersécurité ou un régulateur qu'un incident est survenu. L'article 23 de NIS2 et l'article 14 du CRA fonctionnent ainsi, et tous deux fixent des délais courts. Disposer d'un canal pour les chercheurs ne satisfait ni l'un ni l'autre.

Les textes

Quels textes exigent un canal de signalement

Un seul de ces textes crée une obligation légale pour les entreprises européennes. Les quatre autres sont des normes et des guides sur lesquels les clients interrogent souvent.

Règlement sur la cyberrésilience (UE) 2024/2847
Crée une obligation légale

L'annexe I impose au fabricant de tenir une politique de divulgation coordonnée des vulnérabilités. Il doit aussi publier une adresse où signaler les failles. Aucune taille minimale d'entreprise n'est prévue. Les amendes atteignent 15 millions d'euros ou 2,5 pour cent du chiffre d'affaires mondial. L'obligation pèse sur les fabricants, donc une entreprise qui se contente d'acheter du logiciel n'est pas concernée. Pour chaque produit, elle démarre le jour où ce produit est mis en vente ou substantiellement modifié, à partir du 11 décembre 2027.

NIS2, directive (UE) 2022/2555
Souvent mal lue

NIS2 n'oblige pas votre entreprise à tenir un canal public pour les chercheurs. L'article 12 confie cette tâche à chaque État membre et à l'équipe nationale de cybersécurité qu'il désigne. L'usage de la base européenne des vulnérabilités est facultatif. Les entreprises concernées ont droit à une seule ligne, à l'article 21, paragraphe 2, point e : traitement et divulgation des vulnérabilités. Si un fournisseur vous dit que NIS2 impose un canal de signalement, vérifiez d'abord votre loi nationale.

ISO/IEC 29147 et ISO/IEC 30111
Normes de processus

29147 couvre la partie visible par le chercheur : comment vous recevez un signalement, comment vous répondez à la personne qui l'a envoyé et comment vous publiez le résultat. 30111 couvre l'enquête et la correction au sein de votre équipe. Ni l'une ni l'autre n'est une loi, et aucune ne délivre de certification. La plupart des politiques publiées les suivent, donc une équipe sécurité qui relit la vôtre attendra la même structure.

CISA BOD 20-01 et NIST SP 800-216
Un modèle, pas une obligation

La directive 20-01 impose aux agences fédérales des États-Unis de publier une politique de divulgation des vulnérabilités. NIST SP 800-216 décrit le même travail plus en détail. Aucun des deux ne s'applique à une entreprise européenne. Ils valent la lecture parce qu'ils ont fixé le format que les acheteurs recherchent aujourd'hui. Cela veut dire indiquer quels systèmes un chercheur peut tester, promettre de ne pas engager de poursuites contre une personne agissant de bonne foi, et donner une seule adresse pour les signalements.

Règles sectorielles et référentiels d'audit
Aucune exigence trouvée

SOC 2 ne mentionne pas la divulgation de vulnérabilités. Cyber Essentials ne la mentionne pas non plus. ISO/IEC 27002 ne comporte aucune mesure couvrant un canal de signalement externe. En pratique, la demande arrive par les questionnaires de sécurité des clients. La liste MVSP réclame une politique publiée qui indique ce qui peut être testé, promet de ne pas poursuivre un chercheur de bonne foi et donne des coordonnées.

Les dates et les seuils proviennent des textes européens. Votre régulateur ou votre secteur peuvent exiger davantage.

Une allée entre des baies de serveurs dans un centre de données, diodes d'état allumées
Des câbles réseau bleus et gris branchés sur un panneau de brassage, commutateurs derrière
Un grand écran mural affichant des lignes de code source dans un bureau sombre
security.txt

Faites pointer votre security.txt vers ce canal

La RFC 9116 définit un court fichier texte à /.well-known/security.txt pour qu'un chercheur trouve le bon contact sans chercher. Le fichier ne vaut que pour le domaine depuis lequel il est servi, il doit donc rester sur le vôtre. L'adresse qu'il contient peut être votre page WeMoral.

Le champ Expires est obligatoire et doit viser moins d'un an. Quelqu'un doit renouveler le fichier avant qu'il n'expire. Nous avons vérifié 155 domaines. Parmi les fichiers trouvés, 48 pour cent enfreignaient les règles et 21 pour cent avaient déjà expiré.

Contact: https://wemoral.com/report/demo
Policy: https://example.com/security-policy
Preferred-Languages: en, fr
Expires: 2027-03-01T00:00:00.000Z
Périmètre

Ce que le canal couvre

WeMoral reçoit le signalement et vous donne un fil sécurisé pour y répondre. Ce n'est pas une plateforme de bug bounty.

Une page à vos couleurs accessible à tous, sans compte à créer
Actif, version, gravité et étapes de reproduction sont des champs de formulaire que vous définissez
Les pièces jointes sont analysées et les données cachées retirées de chaque fichier
Un fil chiffré dans les deux sens, pour demander des précisions sans adresse e-mail de part ni d'autre
Chaque lecture et chaque modification sont journalisées, et les données restent à Francfort

Cela fonctionne sur le même compte et le même panneau que vos autres signalements. Aucun second système à acheter.

Questions fréquemment posées

Seulement si vous êtes fabricant au sens du règlement sur la cyberrésilience. Cette obligation commence le 11 décembre 2027 et vaut pour chaque produit au moment où il est mis en vente ou substantiellement modifié. Une entreprise qui se contente d'acheter du logiciel n'est pas concernée. Vérifiez d'abord vos règles nationales.

Non, et la différence tient au sens. La notification d'incidents est sortante : vous informez un régulateur qu'un événement vous est arrivé, dans un délai court. Le canal de divulgation est entrant : quelqu'un de l'extérieur vous signale une faille. La plupart des équipes ont besoin des deux et les gardent séparés.

Non. La RFC 9116 précise que le fichier ne vaut que pour le domaine depuis lequel il est servi, il doit donc rester chez vous. Nous pouvons être l'adresse vers laquelle il pointe. Mettez votre page de signalement WeMoral sur la ligne Contact.

Oui, et beaucoup d'équipes le font. Gardez toutefois les deux types de signalement séparés. Un salarié qui signale un manquement bénéficie d'une protection légale qu'un chercheur extérieur n'a pas. Prévoyez des référents et des durées de conservation distincts, dans le même panneau.

Lancez votre canal de signalement pour lanceurs d'alerte en moins de 5 minutes !

Page de signalement clé en main, conforme à la loi n° 2022-401 du 21 mars 2022 sur les lanceurs d'alerte. Vous la déployez sans développeur.