The Internet Engineering Steering Group (IESG) is set to release a web security policy standard, the goal of which is to simplify the vulnerability disclosure process. This proposal, dubbed “A Method for Web Security Policies”, specifies a standardized file (similar to that of robots.txt or humans.txt) named security.txt. This file will give security researchers (or anyone with a security concern to report) an easy way to learn about a site’s disclosure process or contact those responsible for site security. Primary information included in this file includes contact information, public keys for encrypted communication, acknowledgements for previous researchers and more.

For more information on the draft RFC or to create a security.txt file of your own, please reference the project website.

security.txt

More on security.txt

I think this is a great addition to the Internet at large and should prove very beneficial to security researchers. Having created one of my own, I have some additional thoughts/tips if you decide to create one for yourself.

  • I like the idea of having a directive that quickly summarizes what level of “consent” your site has with respect to vulnerability testing. For example, if you don’t authorize testing of any kind, you could specify this. Or, if your site has an open or by-invite-only bug-bounty program, you could specify that instead. For example, the directive/value pair Testing-Consent: None could be used to express this information. Note: This directive is not one of the current standard directives contained in the draft RFC (but perhaps I will submit my own comment).
  • For the Encryption directive, I have decided to make my PGP key available via Keybase. Alternatively, you could use gpg (GnuPG) to create a public/private key pair and serve your public key directly from your site.
  • To combat potential tampering of security.txt, it is recommended to digitally sign the file. Security researchers should verify this signature prior to using any information contained within (see Section 6.1 of Draft RFC). With this in mind, I recommend to not serve both the public key and the security.txt signature from your site since in the event of a compromise, it would be trivial for an attacker to modify both of these files such that the signature would appear to be valid.
  • I’ve also included an additional non-standard directive in my own security.txt file which specifies the date the security.txt file was last updated. Last-Updated would include just a simple date value (e.g. 12/13/2019).

Tips for Using gnupg

A few tips for creating your own signature files and validating the one I have provided in my security.txt file.

Create a .asc signature file.

gpg --sign --armor --detach-sig [file]

Verify a digitally signed file.

gpg --verify [signature.asc file] [file]