L'idée principale du projet est de formaliser l'interaction entre la sécurité de l'information interne et les chercheurs externes, en donnant une indication claire de comment et où envoyer des informations sur les vulnérabilités ou les problèmes de sécurité. La formalisation de l'interaction est un problème grave, tous les sites ne disposent pas de programmes de bug bounty, ni même simplement d'indiquer les contacts des spécialistes de la sécurité. Et les tentatives pour passer à travers le service d'assistance et Twitter se terminent souvent par des assurances que «tout est comme il se doit», et ensuite ignorées.
Bien sûr, cela ne fonctionnera que si la société qui héberge les informations dans security.txt est prête à vérifier et à répondre en temps opportun aux informations reçues via ce canal.
Le développement de la norme se poursuit depuis août 2017, alors qu'il ne s'agit que d'un projet
Internet (
Internet Draft ) et qu'il n'a pas son propre numéro RFC. Malgré cela, plusieurs grandes entreprises telles que
Google ,
Dropbox ,
Pixiv l' utilisent déjà. Dans RuNet, j'ai réussi à trouver
Goloslogos ,
Clean Line ,
Top Deck et
Drive2 .
Les informations suivantes sont suggérées dans security.txt:
- Méthode de contact : lien vers le formulaire de commentaires, le programme de primes aux bogues ou l'adresse postale (c'est le seul élément requis)
- Clé publique PGP : pour le cryptage des informations sensibles
- Lien vers le Temple de la renommée : pour l'appréciation
- Langues de communication : il est possible de spécifier plusieurs
- Lien vers security.txt lui - même : requis pour l'authentification si vous l'avez vérifié avec une signature numérique
- Lien de politique de sécurité : si votre ressource en possède un
- Lien vers les offres d'emploi : si vous recherchez des professionnels de la sécurité
Le formulaire sur le site officiel peut aider à la génération du fichier au format correct.
Références:
→
Site officiel→
Texte du projet sur l'IETF→
Projet Github