Quelqu’un vous signale une faille : ce qu’il faut faire dans les 72 heures

Un message arrive sur une adresse générique, parfois sur le compte personnel d’un salarié. Quelqu’un explique avoir trouvé une faille sur un de vos services exposés. Le ton est courtois, la description technique. Personne ne sait qui doit répondre, et le message circule trois jours avant d’atterrir quelque part.

Cette séquence est la plus commune, et c’est aussi celle qui produit le plus de dégâts — pas à cause de la faille, mais à cause de la réponse.

Ce qui se passe si vous ne répondez pas

Le rapporteur n’a aucune obligation d’attendre. Le silence est interprété comme un désintérêt, et trois issues suivent, par ordre de fréquence.

Il publie. Sur un blog, une plateforme technique, un réseau social. Vous découvrez la vulnérabilité en même temps que tout le monde, sans correctif prêt, souvent un vendredi.

Il signale ailleurs. À un CERT, à un client à vous, à un journaliste spécialisé. Vous recevez alors la question par un tiers, dans un contexte où la marge de manœuvre est nulle.

Il laisse tomber. C’est le cas le plus fréquent, et le plus trompeur : la faille reste, et la prochaine personne qui la trouvera n’aura peut-être pas les mêmes intentions.

Dans les trois cas, l’organisation a perdu la seule chose qui comptait : le temps d’agir avant que l’information ne circule.

Les trois erreurs de réaction

La menace juridique. Le réflexe existe encore : répondre par un courrier d’avocat évoquant l’accès frauduleux à un système de traitement automatisé. C’est un très mauvais calcul. D’abord parce que le droit français protège explicitement le signalement de bonne foi auprès de l’ANSSI, ce qui affaiblit considérablement la position. Ensuite parce que la menace est presque systématiquement rendue publique par son destinataire, et que le sujet devient alors la réaction de l’entreprise, plus la faille. Enfin parce que le message se propage : plus personne ne vous signalera quoi que ce soit.

Le silence poli. « Merci, nous transmettons aux équipes concernées », puis plus rien pendant six semaines. Fonctionnellement équivalent à l’absence de réponse.

La minimisation immédiate. Répondre « ce n’est pas exploitable » avant d’avoir reproduit. Si le rapporteur démontre le contraire, la crédibilité est perdue pour toute la suite de l’échange.

Ce qu’il faut faire, dans l’ordre

Accuser réception vite, même sans réponse technique

Sous 72 heures, un message court suffit : la réception est confirmée, quelqu’un est nommé comme interlocuteur, un premier retour est annoncé sous dix jours ouvrés. Cela n’engage sur rien d’autre que le processus, et cela suspend presque toujours le compte à rebours.

Reproduire avant de qualifier

Un signalement sur trois environ décrit un comportement attendu, ou une faiblesse théorique sans chemin d’exploitation. Un autre tiers décrit un vrai problème sous-estimé par son auteur. La qualification demande de reproduire, pas de lire.

Point de vigilance : la reproduction peut révéler que la faille est exploitée depuis un moment. Le signalement devient alors un incident, avec les obligations de notification qui vont avec — 72 heures à la CNIL si des données personnelles sont concernées.

Annoncer un délai, et le tenir

C’est le cœur de la négociation. La pratique établie tourne autour de quatre-vingt-dix jours entre le signalement et la publication, avec des ajustements pour les correctifs lourds. Ce délai n’est ni une règle légale ni un droit : c’est un usage que la plupart des rapporteurs respectent si l’organisation communique.

Un délai annoncé et tenu vaut mieux qu’un délai court et dépassé. Si la correction prend six mois parce qu’elle suppose une reprise d’architecture, dites-le : c’est négociable. Ce qui ne l’est pas, c’est de laisser passer la date sans prévenir.

Créditer

La reconnaissance publique est, dans l’écrasante majorité des cas, la seule contrepartie attendue. Elle ne coûte rien et transforme un rapporteur en interlocuteur durable.

Le canal, à mettre en place avant d’en avoir besoin

Trois éléments, réalisables en une journée :

• Une adresse dédiée — la convention établie est security@ sur votre domaine principal — relevée par plusieurs personnes, jamais une boîte individuelle.
• Un fichier de contact sécurité publié à l’emplacement standard sur votre site, indiquant où écrire et dans quelle langue. C’est ce que les chercheurs consultent en premier.
• Une page de politique, en quelques paragraphes : périmètre concerné, engagement de délai de réponse, engagement de ne pas poursuivre un signalement de bonne foi, mention du crédit.

Ce dernier point est le plus structurant. Sans engagement écrit de non-poursuite, un chercheur prudent ne vous écrira pas — et les prudents sont précisément ceux dont vous voulez les signalements.

Ce que le cadre réglementaire change

La directive NIS 2 impose aux États membres de disposer d’une politique de divulgation coordonnée et confie à un CSIRT national un rôle de coordination — en France, le CERT-FR. Pour une entité régulée, disposer d’un canal de signalement et d’un processus de traitement n’est plus une bonne pratique optionnelle : c’est une brique de la gestion des vulnérabilités attendue en supervision.

Le droit français, de son côté, permet depuis plusieurs années de signaler une vulnérabilité de bonne foi à l’ANSSI sans que l’autorité ne transmette l’identité du rapporteur au procureur. Cette protection encadre le signalement, pas l’intrusion : elle ne couvre pas l’exploitation au-delà de la démonstration.

Le vrai indicateur

Il ne porte pas sur le nombre de signalements reçus, mais sur le délai entre la réception et le premier accusé de réception.

Une organisation qui répond en vingt-quatre heures traite ses vulnérabilités. Une organisation qui répond en trois semaines, ou pas du tout, apprendra ses failles par la presse — et la faille ne sera pas le sujet du reportage.

Si vous éditez un logiciel, l’obligation est inversée

Tout ce qui précède décrit la position de celui qui reçoit un signalement. Les éditeurs de logiciels relèvent en outre d’une obligation propre, introduite à l’article L2321-4-1 du code de la défense.

Elle impose de notifier à l’ANSSI les vulnérabilités significatives affectant un produit, ainsi que les incidents compromettant la sécurité des systèmes de l’éditeur lorsqu’ils sont susceptibles d’affecter significativement un de ses produits. Ce n’est pas une faculté : la notification est due, et le CERT-FR publie la procédure et le formulaire correspondants.

Deux conséquences pratiques. D’abord, un éditeur ne peut pas traiter un signalement entrant comme une affaire purement interne : selon la gravité, il déclenche une obligation vis-à-vis de l’autorité. Ensuite, si vous achetez du logiciel, cette obligation pesant sur votre fournisseur est un point à faire figurer au contrat — elle vous donne un fondement pour exiger d’être informé.

Sources

• ISO/IEC 29147 — Vulnerability disclosure et ISO/IEC 30111 — Vulnerability handling processes
• Directive (UE) 2022/2555 (NIS 2) — divulgation coordonnée des vulnérabilités et rôle des CSIRT
• Code de la défense, article L2321-4 — signalement de bonne foi auprès de l’ANSSI
• RFC 9116 — fichier security.txt, format standard du contact sécurité