Security.txt
securitytxt.org
Security.txt
1–10 of 148 posts
Re: Security.txt
#2....because security teams have great working relationships with all the the owners of all the content platforms in an org...
Just make an abuse@ or security@ catch-all for your mail server and point all your domains' MX there. If you're worried about spam, build in a bounce-back that asks for a signed email to make it past the bounce. Security researchers can figure that out.
Re: Security.txt
#3A section for acknowledgements?
Also the Contributions AKA "these random accounts from twitter may have participated to the project to some degree, but we don't want to disclose their names or contributions" section of the website made me smile.
Re: Security.txt
#4....because security teams have great working relationships with all the the owners of all the content platforms in an org... Just make an abuse@ or security@ catch-all for your mail server and point all your domains' MX there. If you're worried about spam, build in a bounce-back that asks for a signed email to make it past the bounce. Security researchers can figure that out.
> If you're worried about spam, build in a bounce-back
This is really bad advice. Always disable spam filtering outright on abuse@ and postmaster@, never filter them, never bounce anything. Read every one. I'm not saying hook those mailboxes up to automatically make a JIRA case on each inbound -- there is screening to be done. However, the idea of abuse@ is that spam is often forwarded directly to it if it's originating from you; if you are catching spam to abuse@ or postmaster@, well, do the math.
abuse@, postmaster@, security@ and friends are discussed in RFC 2142, with a couple "must" directives that are important:
> However, if a given service is offerred [sp], then the associated mailbox name(es) must be supported, resulting in delivery to a recipient
Emphasis mine.
Re: Security.txt
#5A section for acknowledgements? Also the Contributions AKA "these random accounts from twitter may have participated to the project to some degree, but we don't want to disclose their names or contributions" section of the website made me smile.
according to the IETF draft, the acknowledgements directive is meant to point to a page thanking people who have discovered and reported vulnerabilities in the past.
doesn't seem very useful to me. since the document supports comments, just put that link in a comment.
Re: Security.txt
#6....because security teams have great working relationships with all the the owners of all the content platforms in an org... Just make an abuse@ or security@ catch-all for your mail server and point all your domains' MX there. If you're worried about spam, build in a bounce-back that asks for a signed email to make it past the bounce. Security researchers can figure that out.
> If you're worried about spam, build in a bounce-back This is really bad advice. Always disable spam filtering outright on abuse@ and postmaster@, never filter them, never bounce anything . Read every one. I'm not saying hook those mailboxes up to automatically make a JIRA case on each inbound -- there is screening to be done. However, the idea of abuse@ is that spam is often forwarded directly to it if it's origina…
This is great information! Slightly off topic, but I’m curious about your username. Why have you kept on using a throwaway for all of these years?
Re: Security.txt
#7I seem to remember suggesting jobs.txt as a listing for a company’s open positions. Someone even made a site promoting the idea.
What I mean to say is that the concept of a domain is much deeper than html, and we use it so shallowly. The web is distributed and simple if we want it back.
Re: Security.txt
#8Ive only done security in SaaS in my career. This text file is pretty useleas. Disclosure is very out of place, and indicates to me that it's pretty much just for companies with a bug bounty
I'm a bit negative, but I don't want more useless emails from security researchers. Companies that do security well will adopt this, and are already easy to get ahold of...
Re: Security.txt
#9Should surely be .well-known/security.txt, or if not explain why not.
rfc5785 "Defining Well-Known Uniform Resource Identifiers (URIs)"
[edit: I see the FAQ says that, while the linked Internet Draft says it goes at top-level like robots.txt]
Re: Security.txt
#10....because security teams have great working relationships with all the the owners of all the content platforms in an org... Just make an abuse@ or security@ catch-all for your mail server and point all your domains' MX there. If you're worried about spam, build in a bounce-back that asks for a signed email to make it past the bounce. Security researchers can figure that out.
> If you're worried about spam, build in a bounce-back This is really bad advice. Always disable spam filtering outright on abuse@ and postmaster@, never filter them, never bounce anything . Read every one. I'm not saying hook those mailboxes up to automatically make a JIRA case on each inbound -- there is screening to be done. However, the idea of abuse@ is that spam is often forwarded directly to it if it's origina…
Reading all mail to postmaster@ has been utterly impractical for many years.