Résumé

  • La version 00 de draft-bruhns-securitytxt-product-security, datée du 10 septembre 2026, propose deux extensions facultatives à security.txt : Product-Security et Product-Security-Policy.
  • La première désigne des URI de contact pour les vulnérabilités de produits ; la seconde renvoie vers une politique HTTPS appelée à préciser notamment le périmètre, le triage et la divulgation.
  • Il s’agit d’un Internet-Draft individuel. Aucun groupe de travail ne l’a adopté et l’IANA n’a pas enregistré ces deux noms de champ.
  • Un aiguillage réussi n’attribue pas automatiquement un modèle, une version ou un composant à l’équipe qui reçoit le message. Il faut conserver la décision de prise en charge.

Le bon guichet peut rester le mauvais responsable

L’ambiguïté apparaît souvent après la première bonne nouvelle. Le courriel n’a pas rebondi. Un accusé de réception est arrivé. Pourtant, le dossier reste bloqué : l’équipe gère la gamme actuelle, pas la version en fin de support ; le distributeur reçoit les demandes mais ne produit pas le correctif ; la marque commerciale ne possède plus la branche logicielle concernée.

Ce scénario ne met pas en cause la disponibilité du canal. Il révèle une autre frontière. Une adresse de contact répond à une question de départ — où envoyer le signalement — alors que le traitement exige une décision plus précise : quel acteur accepte la responsabilité pour quel artefact ?

La différence est durable. Les domaines Web changent moins vite que les catalogues. Un produit peut être racheté, revendu en marque blanche, forké ou maintenu par un tiers. Sa vulnérabilité peut appartenir à une bibliothèque commune. Le nom de la boîte de réception ne suffit pas à reconstruire cette histoire.

Deux champs encore au stade de la proposition

La fiche du Datatracker classe Product Security Fields for security.txt parmi les Internet-Drafts individuels. Son historique ne comporte que la version 00, publiée le 10 septembre. Ce statut permet la discussion ; il ne vaut ni adoption par un groupe de travail, ni consensus de l’IETF, ni RFC.

Le texte proposé autorise plusieurs lignes Product-Security. Chacune contient un URI de signalement de vulnérabilités touchant les produits, selon les mêmes contraintes d’URI que Contact. Leur ordre indique la préférence de l’éditeur.

Product-Security-Policy ne peut apparaître qu’une fois et pointe vers une ressource HTTPS. La politique devrait y définir les produits couverts, les pratiques d’accusé de réception et de triage, les délais attendus, les règles de divulgation ou d’embargo, les signalements anonymes et les garanties offertes aux recherches menées de bonne foi.

Cette énumération est utile parce qu’elle oblige à regarder au-delà du courriel. Mais le projet décrit ce que la page de politique devrait expliquer ; il ne crée pas un identifiant de produit et ne certifie pas la correspondance entre une version et l’organisation qui publie la page.

L’IANA n’a pas encore ajouté ces noms

Une section du projet demande l’enregistrement des deux champs sous le régime Expert Review. Le registre public de l’IANA ne les contient pas à la date d’observation. On y trouve notamment Contact, Expires, Canonical, Encryption, Policy, Preferred-Languages, ainsi que les extensions enregistrées CSAF, Bug-Bounty et Hiring.

La nuance est institutionnelle. Une demande placée dans une section IANA Considerations décrit l’état souhaité du registre ; elle ne le modifie pas. Le RFC 8126 définit l’Expert Review comme une politique où des experts désignés évaluent une demande selon les règles du registre. L’existence du projet n’anticipe pas leur décision.

Des essais locaux restent possibles. Le RFC 9116 exige qu’un analyseur ignore les extensions inconnues. Le nouveau texte conseille donc aux éditeurs de continuer à accepter les signalements produit sur le champ général Contact, afin que les anciens outils ne perdent pas leur voie de secours. Compatibilité ne signifie toutefois pas reconnaissance universelle.

Le domaine publié ne décrit pas tout le catalogue

Le périmètre ordinaire de security.txt repose sur la ressource depuis laquelle le fichier est récupéré. Selon le RFC 9116, le document trouvé pour un domaine ou une adresse IP ne s’étend pas automatiquement à ses parents ou sous-domaines. Une organisation peut publier des informations pour ses produits et services, mais le format ne constitue pas un inventaire des modèles et versions.

Il faut donc réaliser une jointure que le champ de contact ne contient pas. D’un côté se trouvent le modèle, la référence de paquet, le numéro de version, la branche de micrologiciel ou le commit observé. De l’autre se trouvent une origine Web, une politique et une file de traitement. Sans trace du rapprochement, l’audit ne voit qu’un message livré à un domaine associé à la marque.

Les cas limites ne sont pas rares : équipement en marque blanche, composant open source intégré, produit vendu mais maintenu sous contrat par un tiers, version sortie du support, acquisition dont les anciennes pages restent en ligne. Une politique peut répondre à ces situations. Sa précision et son historique font alors le travail de gouvernance ; la simple présence du lien ne le fait pas.

La confiance reste une propriété de la publication

Le RFC 9116 impose Expires pour que des coordonnées obsolètes puissent être reconnues. Il fournit Canonical afin de désigner l’emplacement voulu et recommande la signature. Un attaquant capable de modifier la surface de publication pourrait autrement détourner le chercheur vers son propre contact.

Ces mécanismes consolident la provenance du fichier. Ils ne prouvent pas la compétence produit. Une signature valide atteste une continuité cryptographique, pas la propriété d’un composant. Une URL canonique choisit la copie de référence, pas la version couverte. L’étape de prise en charge reste nécessaire après la vérification du document.

Le RFC sépare aussi découverte et autorisation : la présence ou l’absence d’un fichier n’accorde ni ne refuse le droit de tester. Une politique produit peut exposer des garanties, mais son libellé doit être lu dans son périmètre et sa juridiction ; le champ qui y mène n’en élargit pas les effets.

Consigner la prise en charge de l’artefact

Un reçu utile commence par l’objet signalé : famille, modèle, composant, paquet, version, build, branche et canal de distribution, selon les données disponibles. Il conserve ensuite l’origine et l’URL canonique du fichier, l’heure de récupération, son échéance, le résultat de signature et l’entrée Product-Security retenue avec son rang de préférence.

Il faut aussi figer l’URL de Product-Security-Policy et un hachage ou numéro de version de la page. L’équipe destinataire enregistre la clause de périmètre qui justifie l’acceptation, le refus ou la réorientation, puis l’identifiant du dossier ou du transfert. Le détail sensible de la vulnérabilité n’a pas besoin d’être public pour que cette décision soit vérifiable.

Ce reçu est une proposition éditoriale de Daniel Kade, pas une obligation du projet, du RFC 9116 ou de l’IANA. Il ne remplace pas le contrôle de fonctionnement du canal. Il conserve ce qui se produit juste après : l’acteur qui accepte la responsabilité pour l’artefact exact.

Sources