You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This would make it much easier for people to discover how to report things (99% of the time you can plug a product name in and get the web page no problem, then the problem becomes finding the contact details for reporting your security vulnerability).
Emailing board as well to start discussion.
The text was updated successfully, but these errors were encountered:
Also obligatory note: I know CVE tries not to be prescriptive of how an organization runs security response (disclosure policies, embargoes, etc.) but this seems like a pretty simple change, and doesn't really impact the actual handling of flaws other than to make them easier to report.
This security.txt is a good idea. It seems to be still in a draft phase and not ready for general consumption. For example, it uses the term 'Full' disclosure in this draft is quite different in context than what 'full disclosure' means in general.
There is a growing need for vendors to share their contact details in a standard way to facilitate vulnerability related communication between researchers, upstream or downstream vendors. I would suggest to stay tuned for FIRST SIG work on this matter.
https://securitytxt.org/
TL;DR: security.txt for reporting security issues, like robots.txt for telling web robots how to behave.
Example file:
# Our security address
Contact: security@example.com
# Our PGP key
Encryption: https://example.com/pgp-key.txt
This would make it much easier for people to discover how to report things (99% of the time you can plug a product name in and get the web page no problem, then the problem becomes finding the contact details for reporting your security vulnerability).
Emailing board as well to start discussion.
The text was updated successfully, but these errors were encountered: