From 1040e73ed3d4bdd38d573a6fe7cdf6f177e354d3 Mon Sep 17 00:00:00 2001 From: Kitsune Ral Date: Sat, 25 May 2019 20:21:54 +0900 Subject: SECURITY.md Moved over text about vulnerabilities reporting and extended it with more details on supported versions and commitments. --- SECURITY.md | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 SECURITY.md diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 00000000..9bb46715 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,32 @@ +# Security Policy + +## Supported Versions + +| Version | Supported | +| ------- | ------------------ | +| master | :white_check_mark: | +| 0.5.x | :white_check_mark: | +| older | :x: | + +## Reporting a Vulnerability + +If you find a significant vulnerability, or evidence of one, use either of the following contacts: +- send an email to [Kitsune Ral](mailto:Kitsune-Ral@users.sf.net); or +- reach out in Matrix to #kitsune:matrix.org (if you can, switch encryption on). + +In any of these two options, indicate that you have such information (do not share it yet), and we'll tell you the next steps. + +By default, we will give credit to anyone who reports a vulnerability in a responsible way so that we can fix it before public disclosure. +If you want to remain anonymous or pseudonymous instead, please let us know; we will gladly respect your wishes. +If you provide a fix as a PR, you have no way to remain anonymous; you also thereby lay out the vulnerability itself +so this is NOT the right way for undisclosed vulnerabilities, whether or not you want to stay incognito. + +## Timeline and commitments + +Initial reaction to the message about a vulnerability (see above) will be no more than 5 days. From the moment of the private report or +public disclosure (if it hasn't been reported earlier in private) of each vulnerability, we take effort to fix it on priority before +any other issues. In case of vulnerabilities with [CVSS 2.0](https://nvd.nist.gov/cvss.cfm) score of 4.0 and higher the commitment is +to provide a workaround within 30 days and a full fix within 60 days after the specific information on the vulnerability has been +reported to the project by any means (in private or in public). For vulnerabilities with lower score there is no commitment on the timeline, +only prioritisation. The full fix doesn't imply that all software functionality remains accessible (in the worst case +the vulnerable functionality may be disabled or removed to prevent the attack). -- cgit v1.2.3