Hacker News Reader

Comment by chillfox | Hacker News Reader

I really don’t get why you would want to serve security.txt, it just invites an avalanche of automated spam.

I serve this file for a fintech. If there is a legit vulnerability, I both want that report in my inbox for triage with as little friction as possible and I also want to be able to demonstrate that we made a best effort to receive that information from a good faith reporter. Is it work? Yes, of course, but that’s part of the job (to defend the enterprise).

Legit/good-faith reporters will find you regardless.

The rest of my infosec career is going to be me sharing my decisions and having them torn apart here by people far better and more experienced than me, but I could do worse. I appreciate every time you tell me I’m wrong, that’s how I get better.

I'm not tearing you apart. I personally wouldn't host a security.txt, but you can.

What keeps me up at night (among many scenarios!) is someone who finds a vulnerability and can’t get it to our security team. Maybe they try the same channels as customer care, maybe they send it to someone they find in LinkedIn. I am not confident we would get the info as fast as through channels advertised in our security.txt file. It’ll receive a ton of junk, but if someone legit is sending something, it’ll absolutely come to us. Call it paranoia or lack of faith in other channel systems, I am optimizing for time to resolution from when we get the report in our inbox (we may never even see it through other channels, with it languishing in a queue or inbox outside of what we see).

Also, to be clear, I genuinely appreciate the constructive criticism. It is helpful for all of us (I could be wrong, even if operating from what I believe to be best available knowledge). We all learn together. My apologies if my comment came across otherwise. I want my ideas to be torn apart, in the same way one would defend a thesis amongst peers. Winning arguments is not important to me; my goal is to explore the problem space and hopefully be implementing what is the best solution to a problem. If I am wrong or can do better, I want to know.

Why would you receive any more or less garbage to contact information in a security.txt va just having a security@example.com email on your contact page?

You’ll get the same amount of spam and irrelevant random bug bounty demanders. There’s no substitute to having someone look at the messages and find that needle in the haystack.

Though there are some signal to noise ratio tricks: https://xkcd.com/1181/

I expect a good faith reporter to know of and consume security.txt for reporting. Whether that assumption is valid remains to be seen of course, but I am confident in the assumption (vs an email address advertised on a webpage).

I can also control security.txt through Cloudflare as an option, and have less control of website content.

https://developers.cloudflare.com/security-center/infrastruc...

They may have good faith and be legitimate and also be unwilling to put in more effort to find a contact and report.

False dichotomy. Yes, you can broadly split people who find vulnerabilities into those who want to use or sell them, and those who want to get them fixed. And those who want to use or sell them will never tell the victim.

But those who notice a problem do have some point of aggravation past which they'll just go "I can't be bothered; fuck 'em". You really do want to make it as easy as possible for them to report. (And alsp make it seem as safe as possible; having a reputation for suing reporters is also terrible.)

Now, in practice, I don't thing security.txt is a particularly useful way of doing this, but it is pretty easy to add.

Nobody is selling vulnerabilities that would otherwise be reported by looking something up in a "security.txt".

Not if you need to report the same thing to multiple parties. And why make it hard to someone who does whitehat work for you.

Do you run a paid bug bounty program? I saw an interesting presentation from Finn.no about how they got most of their vulnerabilities through that, basically none from their security.txt file, and a handful from people contacting the CISO on LinkedIn.

We do not, but I am prepared to pay a bug bounty out of my own compensation, for usual corp reasons. We don’t share this of course unfortunately, so I’m relying on good faith reporters to come forward at which point they get a Willy Wonka ticket if the vuln is legit (and not Burpsuite canned reports or the like). It’s…not ideal. You operate within the org constraints you must operate within.

Are you the CISO?

No, but I believe it to be fair and proper to compensate someone for the value they provide in the event the org does not (and simply says thank you upon receipt of a genuine vulnerability report).

We've had people warn for the spam avalanche when we wanted to implement it company wide (about 500 domains).

After 3 years: ZERO spam

Yeah, you will get all kinds of email claiming your insert nonsense tech buzzwords you don’t even have are open to vulnerabilities that don’t apply or exist and they will cc your boss looking for a bogus payday.

Reply on news.ycombinator.com