5 ms·

Most IT companies fail to serve security.txt for RFC 9116 in 2025

43 points by spyc 2y ago

kaladin-jasnah 2y ago
Are these all IT companies? Mazda and Marantz certainly don't seem like they're IT companies.
- dylan604 2y ago
  If Uber or WeWork are tech companies, then I’m sure people are willing to stretch meanings of other fields too
- hk1337 2y ago
  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.
- zeckalpha 2y ago
  They all are shipping hardware with vulnerabilities.
chillfox 2y ago
I really don’t get why you would want to serve security.txt, it just invites an avalanche of automated spam.
- toomuchtodo 2y ago
  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).
  - tptacek 2y ago
    Legit/good-faith reporters will find you regardless.
    - toomuchtodo 2y ago
      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.
      - tptacek 2y ago
        I'm not tearing you apart. I personally wouldn't host a security.txt, but you can.
        toomuchtodo 2y ago
        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.
        2y ago
- WelcomeShorty 2y ago
  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
- lowlevel 2y ago
  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.
MadVikingGod 2y ago
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.
temp0826 2y ago
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/ https://securitytxt.org/ is calling "A proposed standard..."?
- Aurornis 2y ago
  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.
  - technion 2y ago
    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.
    - tptacek 2y ago
      Well, I mean, it's a self-parodying site, since almost every common domain you type into it fails the test. People calling you out for flunking on that site are saying something important about themselves, not about your security practice.
  - spyc 2y ago
    People who spent hours finding the right security contacts for companies without luck would likely disagree. The key failure is not the single missing file, but that security contacts are too hard to find and the effect that has.
    - tatersolid 2y ago
parliament32 2y ago
Meh. Well known records (robots.txt, everything under .well-known/, etc) are meant to be used by automated systems IMO. The only automated system that would ever use this is email harvesters. You can find our security contact in the whois record for our domain, or through the "vulnerability reporting" link in the footer of our homepage. Good enough.

43 points by spyc 2y ago

kaladin-jasnah 2y ago

Are these all IT companies? Mazda and Marantz certainly don't seem like they're IT companies.

dylan604 2y ago
If Uber or WeWork are tech companies, then I’m sure people are willing to stretch meanings of other fields too
hk1337 2y ago
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.
zeckalpha 2y ago
They all are shipping hardware with vulnerabilities.

chillfox 2y ago

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

toomuchtodo 2y ago
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).
- tptacek 2y ago
  Legit/good-faith reporters will find you regardless.
  - toomuchtodo 2y ago
    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.
    - tptacek 2y ago
      I'm not tearing you apart. I personally wouldn't host a security.txt, but you can.
      - toomuchtodo 2y ago
        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.
        2y ago
WelcomeShorty 2y ago
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
lowlevel 2y ago
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.

MadVikingGod 2y ago

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.

temp0826 2y ago

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/ https://securitytxt.org/ is calling "A proposed standard..."?

Aurornis 2y ago
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.
- technion 2y ago
  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.
  - tptacek 2y ago
    Well, I mean, it's a self-parodying site, since almost every common domain you type into it fails the test. People calling you out for flunking on that site are saying something important about themselves, not about your security practice.
- spyc 2y ago
  People who spent hours finding the right security contacts for companies without luck would likely disagree. The key failure is not the single missing file, but that security contacts are too hard to find and the effect that has.
  - tatersolid 2y ago

parliament32 2y ago

Meh. Well known records (robots.txt, everything under .well-known/, etc) are meant to be used by automated systems IMO. The only automated system that would ever use this is email harvesters. You can find our security contact in the whois record for our domain, or through the "vulnerability reporting" link in the footer of our homepage. Good enough.