Provetry
ENDEDemander l’accès anticipé
Test gratuit
Demander l’accès anticipé

Provetry ouvre en novembre 2026. Le test CRA gratuit, les outils et les guides sont disponibles dès maintenant.

Le security.txt et le point de contact du CRA pour les vulnérabilités

6 min de lecture

Sur cette page
  1. Ce que demande le CRA
  2. La norme : la RFC 9116
  3. Un exemple
  4. Bien le faire
  5. Ce que fait Provetry
  6. Sources

Un chercheur trouve une vulnérabilité dans votre produit. À qui écrit-il ? Trop souvent, à un formulaire de contact générique, à l’adresse commerciale, ou à personne : le signalement se perd, ou la faille est publiée sans prévenir. Un fichier security.txt règle cela en un petit fichier texte, placé à une adresse prévisible, qui dit à tout le monde qui contacter et comment.

Ce que demande le CRA

Le Cyber Resilience Act fait d’un point de contact joignable une obligation pour tout fabricant :

  • L’annexe I, partie II, point 6 demande aux fabricants de faciliter le partage d’informations sur les vulnérabilités potentielles, notamment en fournissant une adresse de contact pour les signaler.
  • L’article 13, paragraphe 17 leur demande de désigner un point de contact unique permettant aux utilisateurs de signaler les vulnérabilités, et de le rendre facile à trouver.
  • L’annexe II, point 2 compte ce point de contact parmi les informations qui doivent accompagner le produit.

Le règlement ne cite pas le security.txt. Mais c’est la norme d’Internet faite exactement pour cela, c’est ce que les chercheurs et les analyseurs regardent en premier, et cela ne coûte rien.

La norme : la RFC 9116

Le security.txt a été publié par l’IETF sous le numéro RFC 9116 en avril 2022. Le fichier se trouve à l’adresse :

https://example.com/.well-known/security.txt

Il doit être servi en HTTPS, en texte brut (text/plain; charset=utf-8). Chaque ligne est un champ et une valeur :

Champ Obligatoire Ce qu’il dit
Contact Oui, au moins un Où signaler : une adresse mailto:, https:// ou tel:. Plusieurs lignes possibles, par ordre de préférence
Expires Oui, exactement un La date après laquelle le fichier ne doit plus être considéré comme fiable. Moins d’un an après la date du jour
Encryption Non Où trouver votre clé OpenPGP, pour chiffrer les signalements
Policy Non L’adresse de votre politique de divulgation des vulnérabilités
Acknowledgments Non Une page qui remercie les chercheurs qui vous ont écrit
Preferred-Languages Non Les langues dans lesquelles vous lisez les signalements, comme fr, en
Canonical Non L’adresse (ou les adresses) où ce fichier doit se trouver, pour repérer les copies
Hiring Non Des offres d’emploi en sécurité, si vous voulez en parler

Les avis de sécurité lisibles par machine en ajoutent un : le champ CSAF, défini par la norme CSAF 2.0 de l’OASIS, renvoie à votre provider-metadata.json pour que les outils trouvent vos avis.

Un exemple

Contact: mailto:securite@acme.example
Contact: https://acme.example/securite/signaler
Expires: 2027-10-31T23:00:00.000Z
Encryption: https://acme.example/.well-known/openpgp-key.asc
Policy: https://acme.example/securite/politique-de-divulgation
Acknowledgments: https://acme.example/securite/remerciements
Preferred-Languages: fr, en
Canonical: https://acme.example/.well-known/security.txt
CSAF: https://acme.example/.well-known/csaf/provider-metadata.json

Rédigez et vérifiez le vôtre avec notre générateur et vérificateur de security.txt gratuit.

Bien le faire

  • Ne le laissez pas expirer. Le champ Expires est obligatoire justement pour que les fichiers périmés soient ignorés. Un fichier expiré au printemps dernier dit aux chercheurs que personne ne lit. Mettez un rappel un mois avant la date, et réécrivez le fichier chaque année.
  • Donnez une adresse lue par une personne. Une boîte securite@ partagée, suivie par plus d’une personne, avec un accusé de réception automatique, est le choix habituel. Avec le CRA, un signalement de vulnérabilité exploitée peut lancer un délai de 24 heures : il ne doit pas rester non lu pendant des vacances.
  • Renvoyez à votre politique. Le champ Policy doit pointer vers une politique de divulgation coordonnée publiée, que le CRA exige aussi.
  • Signez-le si vous pouvez. La RFC 9116 recommande d’entourer le fichier d’une signature OpenPGP en clair, pour que chacun vérifie qu’il n’a pas été modifié.
  • Un fichier par domaine. Placez-le sur chaque domaine qui héberge un produit ou ses services, ou redirigez-les vers le principal.
  • Citez-le dans la documentation du produit, pour que le point de contact unique du CRA soit aussi là où les utilisateurs cherchent : notice d’utilisation, page d’assistance, écran « à propos » de l’application.

Ce que fait Provetry

Avec les offres payantes, Provetry rédige votre politique de divulgation coordonnée et un security.txt à partir de quelques réponses, y liste vos produits et leurs périodes d’assistance, et ajoute la ligne CSAF une fois que vous ouvrez une page publique d’avis et enregistrez de nouveau vos réponses. Le fichier doit être réécrit avant d’expirer ; la page Divulgation vous prévient le mois précédent.

Sources