Résumé

  • La RFC 9116 normalise la découverte d'un contact de signalement et fixe la date après laquelle ses coordonnées deviennent périmées ; elle ne certifie ni la remise d'un message ni sa prise en charge.
  • Une preuve de fonctionnement doit rattacher le fichier récupéré à un test inoffensif, au résultat d'acheminement, à l'accusé de réception, au propriétaire de la file et aux déclencheurs d'un nouveau contrôle.

Analyse

Le fichier paraît irréprochable. Il se trouve sous /.well-known/security.txt, arrive en HTTPS, contient un lien vers la politique, une adresse de contact et une échéance future. Le contrôle automatique est vert. Six mois plus tôt, cependant, l'équipe a changé de prestataire de messagerie. L'alias n'a pas suivi. Le premier véritable signalement extérieur revient avec une erreur définitive.

Ce scénario ne réfute pas la RFC 9116. Il montre qu'on lui a demandé de répondre à une question qu'elle ne pose pas.

La norme règle la découverte. Elle impose au moins un champ Contact et exactement un champ Expires. Sur le Web, le fichier doit être publié sous le chemin bien connu, en texte UTF-8 et via HTTPS. Le registre de l'IANA répertorie security.txt comme suffixe permanent, sous contrôle de modification de l'IETF. Un chercheur et un automate disposent ainsi d'un lieu et d'une grammaire communs.

L'échéance reste essentielle. Après la date indiquée, les informations doivent être tenues pour périmées ; la RFC recommande un horizon inférieur à un an. Ses considérations de sécurité avertissent qu'une information incorrecte ou ancienne peut détourner un rapport vers le mauvais destinataire ou empêcher sa réception. Cette discipline oblige l'éditeur à revoir périodiquement ce qu'il annonce.

Mais Expires est une promesse éditoriale. Ce n'est ni le journal du serveur de courriel, ni l'identifiant d'un dossier, ni l'accusé d'un analyste. Renouveler la promesse ne démontre pas que le service situé derrière les coordonnées fonctionne.

Du repérage à la garde

Il faut séparer deux horloges. L'horloge de publication commence quand l'organisation rédige ou actualise le fichier et choisit sa prochaine échéance. L'horloge de service commence quand un message arrive, reçoit un accusé, est qualifié, affecté, escaladé puis clôturé. Une même date ne peut pas représenter ces étapes.

La première frontière est celle du périmètre. La RFC limite normalement le fichier au domaine ou à l'adresse IP depuis lesquels il a été récupéré, sans extension automatique aux parents et sous-domaines. Une politique centrale peut préciser davantage, mais la portée doit rester vérifiable. Une adresse valide pour le siège n'est pas nécessairement le canal d'un produit acquis récemment.

La deuxième frontière est le transport. Une adresse peut être correctement formée et néanmoins refuser les expéditeurs externes. Un formulaire peut s'afficher tout en échouant à la validation finale. Une plateforme tierce peut créer le dossier sans notifier l'équipe cliente. Le succès HTTP du fichier ne traverse aucune de ces frontières.

La troisième concerne la confidentialité. Le champ Encryption renvoie vers une clé ; il ne l'incorpore pas. La RFC rappelle au chercheur qu'il lui appartient de vérifier l'authenticité de cette clé. Sa disponibilité publique n'établit ni que l'empreinte est encore approuvée ni que l'équipe de permanence sait déchiffrer le message reçu.

La quatrième est l'accusé de réception. Un identifiant durable transforme une remise technique en garde organisationnelle. Une réponse automatique n'a de valeur que si elle correspond à une file surveillée et si elle pourra être rapprochée du dossier traité.

La cinquième est le traitement. Qui qualifie le signalement ? Qui le transfère lorsqu'il vise un système hors périmètre ? Qui coordonne le correctif et informe le chercheur ? La directive contraignante 20-01 de la CISA rend cette différence visible pour les administrations fédérales civiles américaines qu'elle couvre. Elle exige des procédures de suivi jusqu'à résolution, de coordination, d'évaluation, de traitement des hors-périmètre et de communication. Elle demande aussi des délais cibles pour l'accusé, l'évaluation initiale et l'issue. Ce cadre n'est ni une exigence de la RFC 9116 ni une règle mondiale.

Il fournit toutefois un exemple officiel de l'exploitation qui commence après la publication du point d'entrée.

Une preuve légère et sûre

La bonne unité de gouvernance n'est pas un faux dossier de vulnérabilité. C'est une preuve de fonctionnement. Elle enregistre l'URI canonique récupérée, l'empreinte du fichier, l'heure de lecture, l'échéance déclarée et le périmètre concerné. Elle indique le premier contact choisi selon l'ordre publié, ainsi que la version du formulaire ou l'empreinte de clé observée le cas échéant.

Un identifiant de sonde inoffensive relie ensuite les observations. Le message affirme explicitement qu'il s'agit d'un contrôle autorisé de routage. Il ne contient aucune vulnérabilité, donnée personnelle, charge d'exploitation ou information confidentielle. La preuve conserve l'heure d'envoi, l'acceptation ou le rejet par le transport, l'heure et la forme de l'accusé, puis l'identité fonctionnelle du responsable de file et de son suppléant.

Chaque résultat doit rester étroit. Une réponse SMTP positive prouve l'acceptation par un relais, pas la lecture. Une page « merci » prouve une réponse de l'application, pas la persistance du dossier. Un accusé automatique prouve une règle, pas la présence d'un analyste. L'absence d'escalade testée ne doit pas être peinte en vert.

Le rythme suit les changements plutôt qu'un calendrier aveugle : migration DNS ou courriel, nouvelle version du formulaire, rotation de clé, changement d'identité, transfert de fournisseur, départ du responsable, nouvelle politique ou ajout d'un domaine. Hors événement, un contrôle modeste avant l'expiration suffit souvent. L'équipe destinataire doit autoriser la sonde et pouvoir la reconnaître afin qu'elle ne détourne pas les ressources réservées aux vrais signalements.

Conserver la portée de la norme

La preuve ne remplace pas le fichier public. security.txt demeure l'interface commune de découverte ; Canonical, Policy, Preferred-Languages et Encryption réduisent chacun une ambiguïté spécifique. Une signature numérique peut renforcer l'intégrité et la provenance du document.

La preuve répond seulement à ceci : quand le chemin annoncé a-t-il, pour la dernière fois, conduit de la découverte publique à une garde identifiable ? « Fichier actuel, message accepté, aucun accusé » constitue un résultat utile. « Formulaire reçu, dossier créé, suppléant non confirmé » en est un autre. La précision permet de réparer le bon maillon.

Une ligne de synthèse peut rester lisible : fichier récupéré à telle date ; expiration à telle autre ; sonde acceptée ; accusé reçu en vingt minutes ; propriétaire confirmé ; escalade non testée. Ce n'est ni un verdict sur une future vulnérabilité, ni une promesse de délai de correction. C'est l'état documenté d'un canal.

Sources

  1. RFC 9116 — A File Format to Aid in Security Vulnerability Disclosure
  2. Registre IANA des URI bien connues
  3. Directive opérationnelle contraignante 20-01 de la CISA