Hacker News Reader

I agree with the concern about bogus reports from automated scanners -- Tarsnap gets a lot of those (run against the website, even though Tarsnap's bug bounties explicitly exclude the website!).

I suspect that if this is useful at all, it's not for serious testers but rather for people who stumble across issues by accident. There are times when I've had to phone a number in whois to report a problem, because all of the contacts on a company's website went to customer support or marketing -- and there was one occasion when I didn't report something I noticed, because the whois was anonymized.

Bogus reports are an issue security.txt or not. The single and only thing the file provides is a trivially discoverable way to get the contact/submission information for security issues, should they matter for whoever posted the file. That's it. Why make people search for 10min when they can be at a standardized location.

Because then the automated scanners find it too, and send automated reports?

It is just like spam - cheap to send, expensive to read - except you cannot throw it out right away because it may contain actual vulnerability.

The real reason you can’t throw it out right away is because if somebody reports a security issue to you, no matter how bullshit it is, you can’t just outright dismiss it at the risk of a snarky blog coming out attacking your security integrity. Even if the blog is complete nonsense, not everybody who reads it will know that, so the risk to reputation is too high. Bug bounties are almost completely full of incredibly low-effort scanner spam. A company can easily end up wasting huge amounts of its precious security budget getting report spammers to leave them alone. You absolutely never want to do anything to attract those kinds of people to your business, unless you have very carefully weighted up the costs and benefits first.

I honestly think most of the effort that goes into bug bounties and things like security.txt is just busy work for security charlatans who don’t know any better way to be spending their time.

Are you saying automated scanners can't find your other pages? You can also put a submission URL with a captcha in the security.txt file.

If I'm understanding correctly, when "automated scanners" is mentioned here, what's meant is tools that someone runs directly, which scan the software/device and generate loads of red flags. Having a security.txt file makes it that much easier for the tool (or the user) to report the issue, valid or not.

You are correct, but only finding the contact details is easier, submission can still have a high difficulty, methods against spam.

How long does it take you to find the security contact for the coreboot project (www.coreboot.org)? I guess it's on the order of seconds.

And yet we had some interaction on the main mailing list with a journalist covering security fluff (there wasn't much substance) just recently claiming that they "didn't find the contact address" (see https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot....)

So yes, one could say that the journalist should have been more diligent in their search and yet, security is one of the issues where I'd rather hear about things too often than miss something.

If that standard gains traction, I'd expect even a half-competent person in the field to know to look for the two URL patterns (or to use a tool that does it for them) which eliminates the question of "were we clear enough on how to reach out?"

"chance of someone occasionally being less wrong on the internet" for "certainty of steady stream of bogus reports" seems like a pretty bad trade off, let alone one that requires a special standard to achieve.

What's really rough about the steady stream of bogus reports is that they're injecting noise into a channel you really need to read, because amidst all the garbage CAA and Clickjacking and cookie handling and CSP header and Firefox 2.x open redirect nonsense are occasional serious reports of things like XSS, and the important reports aren't any better written than the bad reports so you have to read everything kind of carefully.

My experience has been that you get the decent reports regardless of whether you even have a /security URL, but if you open a formal bounty program you instantly and permanently ratchet up the noise, because this is a way for people in lower-income countries to make money in their bedrooms with a laptop and without much thought. You shitcan the bullshit CAA record reports, but other companies without people who are good at triage on staff don't; they'll shell out a couple bucks for them, even though they're garbage.

Regarding the spam concern, from securitytxt.org:

> Will adding an email address expose me to spam bots? > > The email value is an optional field. If you are worried about spam, you can set a URI as the value and link to your security policy.

It's not spam in the c1alis sense; these are people motivated enough to actually direct a crappy scanner at your site. They'll take the extra minute to go find the email address on the web page you link to.

"Do not rely on security.txt as authorization to test a site!", I was actually thinking of putting up a security.txt recently to do exactly this and explicitly define the terms upon which it would be ok to have people probe my site without retribution. Arguably, this might actually be the most valuable thing to include in a security.txt. I can't really see any down side (can anyone think of any?) as this would help attract attention from the most noble white hats who are likely to help you and are eager to sharpen their skills. Black hats won't care what you put in it. You'd probably want a lawyer to help you flesh out decent terms, but it would be a great playground to have a list of sites that invite people to pen test them under clear terms for mutual benefit.

Having a bug bounty program is generally a delicate dance between letting people too loose at your infrastructure and catching any serious bugs. security.txt or not that's something that probably has to be written clearly or it's "all rights reserved" (don't try to hack us and if you do find something then be very cautious).

As an additional though that just occured to me, we haven't seen how authorization to probe systems (bug bounty system) would interact with GDPR, e.g a breach happens due to a "ethical" hacker, have we?

Interestingly this page started showing up in my server logs recently. I was actually thinking about putting one up but after reading your post I should probably think twice.