Security.txt

Most importantly: there are no formal definitions for what these disclosure terms mean, the distinctions between them are not unimportant, and the most important distinctions have nothing at all to do with "disclosure".

To me, as a working professional in this field, "disclosure: full" informs me that if I report a vulnerability in your service, you'll publish some sort of public advisory, or agree to me doing so, on my own timeline, regardless of when you're fully patched and regardless of whether you've confirmed or triaged the bug.

Is that exactly your understanding of "disclosure: full"? If not, there's your first minor problem.

But there's more important problems. Actually, I don't need any permission whatsoever to publish a vulnerability I find in your site, nor is there any real norm in the infosec community that I shouldn't ("responsible disclosure" is a meme propagated by vendors who want to control independent researchers). You can state your preference that I coordinate with you ("coordinated disclosure" is the researcher-friendly way to write "responsible disclosure"), but you can't dictate that to me --- and the suggestion that you could is presumptuous and rude.

But that's still not the big problem. The BIG problem is that disclosure policy has nothing to do with whether you can test.

There is a widespread belief on the US Internet that light web application testing of SaaS products is allowed. It is very much not. Without explicit permission to test a website I put on the Internet, your doing so violates (and probably should violate!) CFAA, and in some states also state statutes. That goes not just for disruptive testing, like seeing if you can break a SQL query, but also for stuff that most testers believe is harmless, like light XSS testing. I can't tell you how many times an XSS test vector "broke" a site for a client, for instance when it got cached as a "recent search" and displayed, in a DOM-breaking way, to every user on the home page for the site. Bring down a site like that without permission, and even if it says "disclosure: full", you might be civilly liable for the downtime.

I think the "disclosure" field here is thus pretty ill-advised. It advertises a policy that isn't super useful for researchers to know, and doesn't define the most important policy, which is "am I allowed to test this site and what are the rules of engagement for doing so".

What does that leave us with? A PGP key and the name of your security email address. The PGP key is useful, but the contact address should just always be "security@" anyways.

There's really no need for a standard format for this stuff. Just create a "security.html" or whatever that reminds people to send mail to security@, publishes your PGP (note to Symantec: public key) key, and gives people permission to test the site.

Update

One of the authors DM'd me to say they're removing "Disclosure" from the next version of the draft, which is I think the right move.

And it's worth remembering that any kind of disclosure "policy" is a request for a favor from the researcher, so it's good to word things accordingly. You wouldn't generally ask for a concession (like honoring an embargo on publicly reporting a finding you took time to generate) right after also "asking" the reporter to report "in good faith".

In my life, I have only reported two different vulnerabilities to two different vendors.

One of them didn't care at all. They were transmitting usernames and passwords in plaintext and I actually showed one of their engineers this, live, in person, and he just shrugged.

The other one told me something to the effect of "yes, this is very serious. We'll look into it right away" and actually fixed it... 3 years later.

Your biggest hurdle isn't reporting vulnerabilities. That's the easy part.

The biggest hurdle is getting someone to care.