State of the Security.txt

Got vulnz? Cool. Don't know a way to report them? Uncool.

That's where security.txt files come in. The concept is very simple: put a file at a predictable location that tells folks exactly how to reach out to you regarding security concerns.

The format has been around in some capacity since at least 2017 and was standardized as part of RFC9116 in 2022. It is easily machine-readable, that means folks can build security.txt tools like findsecuritycontacts.com¹ which makes makes researchers' lives easier and gets vulnz straight to you. Win-win!

Sounds great, right? I think so! But apparently the internet generally doesn't.

Adoption

Only 737 of the top 10,000 sites² have a security.txt — 7.37%. The top 1,000 and 100 predictably have progressively more adoption at 13.2% and 28% respectively.

Also, it looks like Google contributes about 30% of those 737 security.txts. Way to go. It's a bit cheap to note this since Google also happens to own the vast plurality of the top 10k sites, but it highlights that the general industry is not picking this standard up.

Of those security.txts, most are not spec-compliant (including all of Google's)! That's not a huge deal, these files are meant for humans after all. It is a bit sad though, since it hurts machine parsability and also my feelings.

Mostly, it's the either the lack of an expiry date or improper comments that breaks from the spec. Both relatively easy things to ignore and move on from, so that's good. I managed to parse the vast majority of security.txts I hit, with just a few code tweaks to handle non-compliance.

Speaking of expiry dates, I was curious if folks are keeping their security.txt files up to date. Not having a security contact is bad, but being tossed a red herring is much, much worse.

Most deployments don't have expiry dates, but for those that do the vast majority are up to date! I reached out to the 10 domains with expired security.txts.

It looks like most websites set long-ish expiry times on the order of months to a year and manually update them when the time comes, which is totally fine. Other websites like HackerOne (somewhat appropriately) automatically rotate their security.txt every week or so. To me, that instills confidence that I'm going to be getting fresh and active contact info.

Criticism

This encourages low-effort and spammy reports! Most security.txt criticism I see (e.g. from the comments on KrebsOnSecurity's post on the topic or HackerNews) revolve around this accessibility opening the door for low-effort spam vulnerabilty reports.

Now I can write a simple script that will scrape the internet (or a security.txt registry) for sites with security.txt files. Once I find one I launch some automated web vulnerability scanner and just forward the report to the security contact with a note that says “You can send the bounty money to paypal@example.org”. Something ought to stick.

That totally happens. And it's can be annoying. But there's a sort-of reverse catch-22 here. If you're operating a small security program you probably won't have a lot of spam activity; worst comes to worst you drop the email and make it a bit harder to get in contact (but still have it be clear). If you're operating a larger security program, then not being able to handle low-effort vulnerability reports probably means you need to be investing more in your vulnerability intake and management processes.

Our Experience

Asana (the company I work for at the time of writing) has an RFC9116-compliant security.txt as of a few months ago, so I'm feeling pretty comfortable preaching off of my high horse.

We have millions of daily active users, a fantastic customer support team, and a very active (and well-paying) bug bounty program managed by BugCrowd. We get a lot of security reports both via our security contact email security@asana.com and our BugCrowd program, many of which are bogus. But we don't deal with them on the security team, they never reach us!

When a security report comes in to our security@asana.com email address, it is triaged by our general customer support team. In most cases, folks are directed to BugCrowd. In particularly sensitive cases, the reports are escalated directly to the security team.

When a BugCrowd submission comes in, BugCrowd triagers attempt to reproduce and validate the security report. If they are able to, it gets forwarded to the security team. Otherwise, the report is scrapped.

Our security team only gets involved when the report is fully validated. The report gets automatically routed into the intake of our internal vulnerability management process and we respond to it like we respond to any other vulnerability that is discovered (with added communication to the reporter).

Less than 7.5% of reports reach the security team.

To me, this says that our vulnerability reporting and intake process is going pretty well.

That said, if you're interested in helping us improve all this and more as part of a growing, collaborative, and well-supported team, we're hiring a Senior Application Security Engineer.

Conclusion