TL;DR : L’essentiel
- security.txt est un petit fichier texte, normalisé par l’IETF (RFC 9116), qui indique à toute personne découvrant une faille comment et à qui la signaler. Il se place toujours au même endroit : /.well-known/security.txt.
- Deux champs sont obligatoires : un moyen de contact (Contact) et une date d’expiration (Expires). Les autres précisent la politique de divulgation, les langues acceptées ou la clé de chiffrement à utiliser.
- Le fichier n’est qu’une porte d’entrée. Sans politique de divulgation publiée et sans équipe capable de trier les signalements, il crée plus de bruit qu’il ne réduit de risque.
- Le contexte réglementaire change la donne : NIS2 organise la divulgation coordonnée des vulnérabilités en Europe, et le Cyber Resilience Act impose depuis septembre 2026 aux fabricants de produits numériques de signaler les vulnérabilités activement exploitées.
- Pour un décideur, la bonne question n’est pas « avons-nous un fichier security.txt ? », mais « un signalement reçu ce soir sera-t-il lu, qualifié et traité ? ».
Un chercheur en sécurité découvre une faille sur le site d’une organisation. Il veut la signaler. Commence alors souvent un parcours incertain : formulaire de contact générique, adresse info@ qui ne répond pas, message LinkedIn à un employé au hasard. Faute de canal clair, le signalement se perd, arrive trop tard, ou n’est jamais envoyé. Dans le pire des cas, la faille est publiée sans que l’organisation ait eu le temps de la corriger, ou elle finit exploitée par quelqu’un de moins bien intentionné.
La norme security.txt répond à ce problème de la manière la plus simple possible : un fichier placé à un emplacement standard, qui dit qui contacter et selon quelles règles. Ce guide explique ce que contient ce fichier, pourquoi il ne suffit pas à lui seul, comment il s’inscrit dans les obligations réglementaires européennes et suisses, et quelles décisions il implique pour un responsable sécurité ou un dirigeant.
security.txt normalise le point de contact sécurité
security.txt est un fichier texte publié sur un site web à l’adresse https://exemple.ch/.well-known/security.txt. Il décrit, dans un format lisible par un humain comme par une machine, la manière de signaler une vulnérabilité à l’organisation. Le principe s’inspire du fichier robots.txt, que les moteurs de recherche consultent depuis des décennies pour savoir quelles pages indexer.
L'essentiel Cybersécurité, IA & Tech
Rejoignez la communauté. 3 fois par semaine, recevez l'analyse des tendances par Marc Barbezat. Pas de spam, juste de l'info.
Proposée en 2017, la norme a été publiée par l’IETF en avril 2022 sous la référence RFC 9116. Elle impose trois règles de base : le fichier doit être servi en HTTPS, il doit contenir au minimum un contact et une date d’expiration, et il doit être placé dans le répertoire normalisé /.well-known/.
Un fichier minimal ressemble à ceci :
Contact: mailto:security@exemple.ch
Expires: 2027-09-30T23:00:00.000Z
Preferred-Languages: fr, en, de
Policy: https://exemple.ch/divulgation-vulnerabilites
Canonical: https://exemple.ch/.well-known/security.txt
Chaque champ répond à une question précise
La norme définit un nombre limité de champs, chacun répondant à une question que se pose la personne qui veut signaler une faille.
| Champ | Statut | Question à laquelle il répond |
|---|---|---|
| Contact | Obligatoire | Où envoyer le signalement ? (adresse email, formulaire web, téléphone) |
| Expires | Obligatoire | Ces informations sont-elles encore à jour ? |
| Policy | Recommandé | Quelles sont les règles du jeu : périmètre, délais, engagements réciproques ? |
| Preferred-Languages | Recommandé | Dans quelle langue écrire ? |
| Encryption | Recommandé | Quelle clé utiliser pour chiffrer un signalement sensible ? |
| Canonical | Recommandé | Ce fichier est-il bien la version officielle ? |
| Acknowledgments | Facultatif | Où l’organisation remercie-t-elle publiquement les découvreurs ? |
| Hiring | Facultatif | L’organisation recrute-t-elle des profils sécurité ? |
| CSAF | Facultatif | Où trouver les avis de sécurité publiés au format CSAF ? |
Deux champs méritent une attention particulière de la part d’un décideur.
Expires oblige l’organisation à revoir régulièrement son fichier. La norme recommande une durée de validité inférieure à un an. Un fichier expiré signale un point de contact abandonné, ce qui est pire que pas de fichier du tout : il donne une fausse assurance au chercheur et révèle un défaut de gouvernance à qui sait regarder.
Policy pointe vers la politique de divulgation des vulnérabilités. C’est le document qui transforme un simple contact en processus.
La norme recommande également de signer le fichier avec une clé OpenPGP, afin qu’un attaquant ayant compromis le site ne puisse pas remplacer discrètement l’adresse de contact par la sienne.
Le fichier n’est qu’une porte, la politique de divulgation fait le reste
Publier un fichier security.txt sans rien derrière revient à installer une sonnette sans personne pour ouvrir. La vraie décision porte sur la politique de divulgation des vulnérabilités (VDP, pour Vulnerability Disclosure Policy), vers laquelle pointe le champ Policy.
Une politique de divulgation répond aux questions que tout chercheur se pose avant de signaler une faille :
- le périmètre : quels sites, applications et services sont concernés, et lesquels sont exclus ;
- les méthodes autorisées : ce que le chercheur peut tester, et ce qui est interdit (déni de service, accès aux données de tiers, ingénierie sociale) ;
- les engagements de l’organisation : délai d’accusé de réception, délai de qualification, information du chercheur sur la correction ;
- le cadre juridique : l’engagement de ne pas poursuivre un chercheur agissant de bonne foi et dans le respect des règles fixées ;
- la publication : le délai après lequel la faille peut être rendue publique, et les modalités de reconnaissance du découvreur.
Cette politique ne doit pas être confondue avec un programme de bug bounty. Une politique de divulgation ouvre un canal et fixe des règles, sans promettre de récompense. Un bug bounty ajoute une rémunération, généralement gérée par une plateforme spécialisée qui filtre les signalements. La plupart des organisations commencent par la première ; la seconde suppose une maturité et un budget que toutes n’ont pas.
Un canal clair accélère la réponse aux incidents
Les bénéfices de security.txt ne se limitent pas aux relations avec les chercheurs indépendants.
Le délai de réaction diminue. Un signalement qui arrive directement à l’équipe sécurité, au lieu de transiter par le support client ou le service communication, gagne souvent plusieurs jours. Sur une vulnérabilité critique, ces jours comptent.
Les notifications à grande échelle atteignent leur cible. Lorsque les centres nationaux de cybersécurité, les CERT ou des chercheurs identifient des milliers de systèmes vulnérables après la publication d’une faille, ils ont besoin d’un moyen automatisé de trouver le bon interlocuteur. Un fichier lisible par machine, à un emplacement connu, est précisément ce qui rend ces campagnes possibles.
L’organisation envoie un signal de maturité. Publier un point de contact sécurité montre que l’organisation accepte l’idée d’avoir des failles et s’est organisée pour les traiter. Pour un partenaire, un client ou un auditeur, c’est un indicateur simple, vérifiable de l’extérieur.
NIS2, le Cyber Resilience Act et les autorités renforcent l’enjeu
security.txt reste une norme volontaire. Mais la divulgation coordonnée des vulnérabilités, qu’il facilite, est devenue une attente réglementaire explicite.
Aux États-Unis, la CISA a imposé dès 2020 aux agences fédérales, par sa directive BOD 20-01, de publier une politique de divulgation des vulnérabilités, en citant security.txt comme moyen de désigner le point de contact.
Dans l’Union européenne, la directive NIS2 structure la divulgation coordonnée des vulnérabilités à l’échelle des États membres, en confiant à des CSIRT nationaux un rôle de coordinateur entre ceux qui découvrent les failles et ceux qui doivent les corriger. La gestion et la divulgation des vulnérabilités font partie des mesures attendues des entités concernées.
Le Cyber Resilience Act (CRA) va plus loin pour les fabricants de produits comportant des éléments numériques, logiciels comme matériels. Depuis le 11 septembre 2026, ils doivent signaler les vulnérabilités activement exploitées et les incidents graves via la plateforme unique de l’ENISA : alerte précoce sous 24 heures, notification complète sous 72 heures, rapport final au plus tard 14 jours après la mise à disposition d’un correctif. À partir de décembre 2027, les autres obligations du règlement s’appliqueront, dont la mise en place d’une politique de divulgation coordonnée et d’un point de contact pour recevoir les signalements. Une organisation ne peut pas déclarer ce qu’elle ne détecte pas : un canal de signalement fonctionnel devient une condition pratique de conformité. Les entreprises suisses qui commercialisent des produits numériques sur le marché européen sont directement concernées.
En Suisse, l’Office fédéral de la cybersécurité (OFCS) recommande aux entreprises et aux organisations de publier un fichier security.txt, et l’administration fédérale l’applique à ses propres sites.
Les pièges qui transforment le fichier en passif
Un fichier security.txt mal géré peut exposer davantage qu’il ne protège. Cinq situations reviennent régulièrement.
Une adresse que personne ne lit. Une boîte security@ non surveillée, ou redirigée vers une adresse générique, fait perdre les signalements tout en donnant l’illusion d’un canal ouvert. Le contact doit aboutir à une équipe identifiée, avec un délai de réponse défini.
Un fichier expiré. La date d’expiration est souvent oubliée après la première publication. Un rappel automatique, rattaché à un responsable nommé, suffit à éviter ce défaut visible de tous.
Le « beg bounty ». Rendre le contact visible attire aussi des messages automatisés : rapports de scanners sans analyse, failles sans impact réel, demandes de récompense insistantes. Une politique de divulgation claire, qui précise ce qui ne sera pas considéré comme une vulnérabilité et qu’aucune rémunération n’est prévue, permet de trier rapidement. Des filtres simples sur les formulations types de ces messages complètent le dispositif.
Un seul domaine couvert. Le fichier n’est souvent publié que sur le site principal, alors que les sous-domaines, les applications métier et les anciens sites restent sans point de contact. La norme permet de rediriger vers un fichier central ; encore faut-il l’avoir prévu.
Aucun lien avec la gestion des incidents. Un signalement de vulnérabilité peut révéler une compromission en cours. Le processus de traitement doit donc être relié à la gestion des incidents et, pour les organisations concernées, aux obligations de notification aux autorités.
Déployer security.txt en six étapes
La mise en place technique prend quelques minutes. L’organisation qui doit l’accompagner demande davantage de réflexion.
- Désigner un responsable du point de contact et de la mise à jour du fichier.
- Choisir le canal : adresse dédiée, formulaire sécurisé ou plateforme de divulgation, avec un délai de réponse réaliste au regard des ressources disponibles.
- Rédiger la politique de divulgation : périmètre, méthodes autorisées, engagements, cadre juridique, modalités de publication.
- Publier le fichier sur chaque domaine exposé, en HTTPS, idéalement signé, avec une date d’expiration inférieure à un an.
- Relier le processus à la gestion des vulnérabilités et des incidents, et aux obligations de notification applicables (NIS2, CRA, obligations nationales).
- Revoir chaque année le fichier, la politique et les statistiques de signalements reçus.
Questions fréquentes sur security.txt
Qu’est-ce qu’un fichier security.txt ?
C’est un fichier texte normalisé par l’IETF (RFC 9116), publié à l’adresse /.well-known/security.txt d’un site web. Il indique comment signaler une vulnérabilité à l’organisation : contact, politique de divulgation, langues acceptées, clé de chiffrement. Il est lisible à la fois par les humains et par les outils automatisés.
Quels sont les champs obligatoires de security.txt ?
Seuls deux champs sont obligatoires : Contact, qui indique où envoyer un signalement, et Expires, qui fixe la date au-delà de laquelle les informations ne doivent plus être considérées comme fiables. La norme recommande une durée de validité inférieure à un an.
security.txt est-il obligatoire ?
Non, security.txt reste une norme volontaire. En revanche, la divulgation coordonnée des vulnérabilités qu’il facilite est désormais attendue par plusieurs cadres : NIS2 dans l’Union européenne, le Cyber Resilience Act pour les fabricants de produits numériques, et les recommandations de l’OFCS en Suisse.
Quelle différence entre security.txt, une politique de divulgation et un bug bounty ?
security.txt indique où signaler une faille. La politique de divulgation fixe les règles : périmètre, méthodes autorisées, délais, protection juridique du chercheur de bonne foi. Un bug bounty ajoute une récompense financière, généralement gérée par une plateforme spécialisée. Les trois sont complémentaires, et le premier sans le deuxième a peu de valeur.
Comment éviter d’être submergé par des signalements sans intérêt ?
En publiant une politique de divulgation qui précise ce qui n’est pas considéré comme une vulnérabilité et qu’aucune récompense n’est prévue en dehors d’un programme dédié. Des filtres sur les rapports automatisés et, pour les organisations les plus exposées, le recours à une plateforme de divulgation qui assure un premier tri complètent le dispositif.
Quel lien entre security.txt et le Cyber Resilience Act ?
Depuis le 11 septembre 2026, le CRA impose aux fabricants de produits numériques de signaler à l’ENISA les vulnérabilités activement exploitées. À partir de décembre 2027, il exige aussi une politique de divulgation coordonnée et un point de contact pour les signalements. security.txt est le moyen standard de rendre ce point de contact visible et exploitable.
Faut-il publier security.txt sur tous les sous-domaines ?
Idéalement, chaque domaine et sous-domaine exposé doit permettre de trouver un point de contact. La norme autorise un fichier central vers lequel les autres sites redirigent, ce qui simplifie la maintenance et évite les fichiers orphelins.
Pour approfondir le sujet
sécurité.txt
Une norme proposée qui permet aux sites web de définir des politiques de sécurité. Lire la suite
Security.txt – Enregistrez un contact de sécurité sur votre site Internet
En cas de problème de cybersécurité au sein d'une entreprise ou d'une organisation, il est crucial d'en informer aussitôt le responsable de la sécurité. Or, il est généralement difficile, voire impossible, de retrouver ce dernier sur les sites Internet. La… Lire la suite
RFC 9116 : Un format de fichier pour faciliter la divulgation des vulnérabilités de sécurité | Éditeur RFC
Lorsque des failles de sécurité sont découvertes par des chercheurs, les canaux de signalement appropriés font souvent défaut. De ce fait, certaines failles peuvent ne pas être signalées. Ce document définit un format lisible par machine (« security.txt ») afin d’aider les… Lire la suite
BOD 20-01 : Élaborer et publier une politique de divulgation des vulnérabilités | CISA
Cette page contient une version adaptée au Web de la directive opérationnelle contraignante 20-01 de l'Agence de cybersécurité et de sécurité des infrastructures, intitulée « Élaborer et publier un Lire la suite
Loi sur la cyber-résilience – Obligations de déclaration
À compter du 11 septembre 2026, les fabricants sont tenus de signaler les vulnérabilités exploitées et les incidents graves affectant la sécurité des produits comportant des éléments numériques. Conformément à l'article 71, paragraphe 2, de la loi sur les produits… Lire la suite
Cette veille vous a fait gagner du temps ?
Aidez DCOD à payer ses serveurs et à rester 100% gratuit et indépendant.
