How 104 software vendors tell you where to report a vulnerability

/.well-known/security.txt is a small text file, standardised as RFC 9116, that says where to send a security report. We read it at every vendor in the registry and checked it against the two things the standard makes mandatory: a contact, and an expiry date that has not passed.

Expired files

Every security.txt has to carry an Expires date, after which RFC 9116 says the file should be treated as stale. It exists so that an abandoned file with a dead mailbox stops being trusted. These files were past that date on the day we read them:

An expired file is usually forgotten rather than abandoned: the contact in it may well still work. Amazon Web Services' file had expired on 24 September 2026 when we first read it on 11 October, and had been renewed by our next reading on 17 October.

Missing a required field

20 files have no Expires field at all and 3 have no Contact field, the line the file exists to carry. 1 has an Expires that is not a date in the format the standard requires (RFC 3339).

Expiry dates years ahead

The standard also recommends an Expires less than a year away, so that someone looks at the file again. 21 of the 47 files in date set it further out, measured from the day we read them. This is a recommendation, not a requirement, and none of these is counted as a fault above.

Where reports go

Of the 69 files with a contact, 24 give only an email address, 25 only a web page or form (often a bug bounty platform), and 20 give both. 60 link a disclosure policy, which says what a researcher may test and what the vendor promises in return.

No file

27 vendors answer neither /.well-known/security.txt nor the older /security.txt on their main website. That does not mean they have no way to report a vulnerability: a vendor can publish one on an ordinary page, which this count does not look for. It means the standard place to look is empty:

Box, Brevo, Cisco Webex, Docusign, Elastic Cloud, Grafana Labs, Klaviyo, KnowBe4, Langdock, Make, Miro, Nextcloud, Oracle Cloud, Pennylane, Personio, Pipedrive, Pleo, S3NS, Salesforce, Sinch, T Cloud Public, Typeform, Usercentrics, Workday, Xero, Zapier, monday.com.

3DS Outscale, Matomo Cloud, Twilio answer the path with a web page instead of a text file, which a tool reading security.txt cannot use. MongoDB and SAP disallow the path in their robots.txt, so we did not read it and say nothing about whether a file is there.

How this was read

Each file was fetched from the vendor's main website, on the homepage's host and then on the bare domain, and parsed field by field without a model; values are kept as written. The latest readings are from 2026-10-17, and the files are read again every week, so a vendor that renews its file drops off the expired list at the next reading. Products of one company that share a website share its file, so Google's three products count three times. The full method is on the methodology page.