Been in or around tech my whole life and this is the first time I've heard of security.txt. This article is trying to shame or something over what even https://securitytxt.org/ is calling "A proposed standard..."?
The “fail to serve” wording in the headline is unnecessarily rage-baity.
It’s an interesting proposal, but trying to shame people into adopting proposed things is more likely to generate groans and disinterest in 2025 than to win converts.
I see these sort of things as a signal. I would personally encourage use internally, because I would like to signal towards the right sort of researchers.
But when you conflate that with some sort of expectation or "minimum effort" and try to shame people with it you signal something else, particularly to people who disagree with the value of said standard. I've had people show me my domains on "DNSSEC Hall of shame" site and my opinion of that site's existence lowers every time.
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).
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.
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).
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.
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.
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.
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.
I’m not really sure why the author made the limitation to “IT Companies” unless what they really mean is the IT organization within the companies. The security.txt seems like it should be utilized by any company that does business on the internet, much like having an abuse email address.
I want to start off with that I do think the goal of this RFC is a laudable one, and anything that follows shouldn't be taken as a damnation of it. If you are on the fence if you should implement security.txt just do it.
This article is a large nothing burger. "I sampled 50 companies, most of which are on the internet because they have to be, and most didn't implement an IETF comment". If these were mostly tech focused companies, or heck security companies, sure it would make sense to shame them, but if there is a vulnerability in Ford's website I would bet the impact is quite low.
Hell this is so poorly thought out I want to go try it on the top 100 websites by volume and maybe try and find a top 100 tech websites.
Been in or around tech my whole life and this is the first time I've heard of security.txt. This article is trying to shame or something over what even https://securitytxt.org/ is calling "A proposed standard..."?
The “fail to serve” wording in the headline is unnecessarily rage-baity.
It’s an interesting proposal, but trying to shame people into adopting proposed things is more likely to generate groans and disinterest in 2025 than to win converts.
I see these sort of things as a signal. I would personally encourage use internally, because I would like to signal towards the right sort of researchers.
But when you conflate that with some sort of expectation or "minimum effort" and try to shame people with it you signal something else, particularly to people who disagree with the value of said standard. I've had people show me my domains on "DNSSEC Hall of shame" site and my opinion of that site's existence lowers every time.
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).
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).
Legit/good-faith reporters will find you regardless.
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".
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.
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
Are these all IT companies? Mazda and Marantz certainly don't seem like they're IT companies.
I’m not really sure why the author made the limitation to “IT Companies” unless what they really mean is the IT organization within the companies. The security.txt seems like it should be utilized by any company that does business on the internet, much like having an abuse email address.
They all are shipping hardware with vulnerabilities.
If Uber or WeWork are tech companies, then I’m sure people are willing to stretch meanings of other fields too
I want to start off with that I do think the goal of this RFC is a laudable one, and anything that follows shouldn't be taken as a damnation of it. If you are on the fence if you should implement security.txt just do it.
This article is a large nothing burger. "I sampled 50 companies, most of which are on the internet because they have to be, and most didn't implement an IETF comment". If these were mostly tech focused companies, or heck security companies, sure it would make sense to shame them, but if there is a vulnerability in Ford's website I would bet the impact is quite low. Hell this is so poorly thought out I want to go try it on the top 100 websites by volume and maybe try and find a top 100 tech websites.