|
| 1 | +# Security Policy <!-- omit in toc --> |
| 2 | + |
| 3 | +## Contents <!-- omit in toc --> |
| 4 | + |
| 5 | +- [How to Report](#how-to-report) |
| 6 | +- [Response and Handling](#response-and-handling) |
| 7 | +- [Disclosure Policy](#disclosure-policy) |
| 8 | +- [Supported Versions](#supported-versions) |
| 9 | +- [Prevention](#prevention) |
| 10 | +- [Acknowledgments](#acknowledgments) |
| 11 | + |
| 12 | +## How to Report |
| 13 | + |
| 14 | +* Please [report](https://github.com/ThinkParQ/beegfs-rust/security) potential security |
| 15 | + vulnerabilities using [GitHub's private vulnerability |
| 16 | + reporting](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability). |
| 17 | + Make sure to not disclose this information in public. |
| 18 | +* Provide a detailed description of the potential vulnerability, ensuring you include steps that can |
| 19 | + help in reproducing the issue. |
| 20 | + |
| 21 | +## Response and Handling |
| 22 | + |
| 23 | +We will make every effort to response to and resolve security issues in a timely manner. To that end |
| 24 | +our goals when handling security issues are: |
| 25 | + |
| 26 | +* Acknowledge every report within three working days. |
| 27 | +* Assess the report, evaluate its impact and severity, and determine its authenticity providing an |
| 28 | + new update within five working days. |
| 29 | +* Work diligently to address any verified vulnerabilities. While the time to deliver a fix will vary |
| 30 | + depending on complexity, throughout this process, we'll provide timely updates on our progress |
| 31 | + until resolution. |
| 32 | +* Once the vulnerability has been fixed, make a public announcement crediting you for the discovery |
| 33 | + (unless you wish to remain anonymous). |
| 34 | + |
| 35 | +## Disclosure Policy |
| 36 | + |
| 37 | +Upon confirmation of a security issue, our approach is: |
| 38 | + |
| 39 | +1. Verify the vulnerability and determine affected versions. |
| 40 | +2. Develop a fix or a workaround. |
| 41 | +3. Upon a successful fix or workaround, inform the community through a public advisory. |
| 42 | + |
| 43 | +## Supported Versions |
| 44 | + |
| 45 | +Security fixes are made available in the latest major version and backported to older versions per |
| 46 | +the [BeeGFS support policy](https://github.com/ThinkParQ/beegfs/blob/master/SUPPORT.md) |
| 47 | + |
| 48 | +## Prevention |
| 49 | + |
| 50 | +To help prevent security vulnerabilities, we: |
| 51 | + |
| 52 | +- Regularly review and update our dependencies using Dependabot and CodeQL. |
| 53 | + |
| 54 | +- Adhere to best coding practices and conduct regular code reviews. |
| 55 | + |
| 56 | +- Actively seek feedback and input from our developer community on security matters. |
| 57 | + |
| 58 | +## Acknowledgments |
| 59 | + |
| 60 | +We're thankful to our community for their active involvement in enhancing the safety of our project. |
| 61 | +Those who've identified vulnerabilities are recognized in our release notes, unless they've opted |
| 62 | +for anonymity. |
0 commit comments