What security.txt is for
When someone finds a vulnerability in your site, the hard part is often finding out whom to tell. security.txt (RFC 9116) is a short text file at /.well-known/security.txt that answers that: a Contact line with an e-mail address or a reporting page, and an Expires line that says until when the information may be relied on. Both are required. Optional fields add an encryption key, the disclosure policy, preferred languages, the canonical URL of the file, a link to acknowledgments and security job openings.
What this tool checks
It requests https://<domain>/.well-known/security.txt and, if that is not there, the older location /security.txt. It follows a few redirects and reports the final URL. Then it parses the fields and flags what RFC 9116 asks for: a missing Contact or Expires, more than one Expires, a date that is not in the required format, a date in the past, a date more than a year away, a file that was served over plain HTTP or with an invalid certificate, links that use http:, a Canonical field that does not match the URL the file was found at, and whether the file carries an OpenPGP cleartext signature.
Many sites answer every unknown path with their home page and status 200. An HTML answer is therefore treated as "not found", not as a broken security.txt. And if the request fails, the result is "could not be checked": the tool never reports a missing file because of a timeout.
Keeping the file useful
An expired file is the most common finding, because Expires is mandatory and easy to forget. Set it less than a year ahead and put the renewal in the same calendar as your certificates and domains. Use an address that reaches people who can act, not a personal mailbox, and sign the file if you want reporters to be able to verify it.