-
Notifications
You must be signed in to change notification settings - Fork 190
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
docs:feat - Security Policies (#1052)
Signed-off-by: Lucas Bruno Ferreira <lucas.bruno@zup.com.br> (cherry picked from commit d309b63) Signed-off-by: Wilian Gabriel <wilian.silva@zup.com.br>
- Loading branch information
1 parent
2c11096
commit a615329
Showing
1 changed file
with
50 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,50 @@ | ||
# **Security Policies** | ||
|
||
Zup's Open Source projects adopt recommendations from the **OpenSSF Security Scorecards** and the **OpenSSF Best Practices Badge** program. Our projects must have a public policy for security vulnerabilities disclosure. | ||
|
||
## **Supported versions** | ||
|
||
|Version |Supported | | ||
|--- |--- | | ||
|Latest branch version |Yes | | ||
|Other versions |No | | ||
|
||
### **Private Disclosure Process of Vulnerabilities** | ||
|
||
Zup's Open Source Engineering team and its product communities care about reported security vulnerabilities. | ||
|
||
Our community request that every suspected vulnerability are disclosed privately and responsibly. | ||
If you find a vulnerability or even a possible one, follow the instructions: | ||
|
||
**1.** Send us an e-mail to **secure.opensource@zup.com.br**. You need to add the information below: | ||
|
||
- Type of vulnerability (for example Buffer Overflow, SQL Injection, Cross-Site Scripting, etc.). | ||
- Full paths of the source files related to the vulnerability manifestation. | ||
- The location of the affected source code (tag/branch/commit or direct URL). | ||
- Step-by-step instructions to reproduce the problem and you can also add any special configuration required to it. | ||
- Proof-of-concept or exploit code (if possible). | ||
- The impact of the problem, including how an attacker might exploit the vulnerability. | ||
|
||
**2.** The **Horusec** team will acknowledge your e-mail and they will send you a more detailed response indicating the next steps to handle the vulnerability you have reported. | ||
|
||
**3.** The **Horusec** team will keep you informed about the progress of the fix and its public disclosure. They may ask you for additional information. | ||
|
||
### **Public Disclosure Process of Vulnerabilities** | ||
|
||
If you become aware of a publicly disclosed vulnerability, please IMMEDIATELY send an e-mail to secure.opensource@zup.com.br, informing the **Horusec** team about it so they can address it via analysis, fix, new versioning, and release. | ||
|
||
Whenever is possible, the **Horusec** team may request the person who made the vulnerability's public disclosure to address it through a private process, for example, if details about exploiting the flaw are not available yet. | ||
|
||
### **Disclosure Policy** | ||
|
||
When the **Horusec** team receives a vulnerability report, a team member is assigned as a primary handler. This person will contact the product's Tech Lead to coordinate the bug fix and new fixed version release process, see the steps of this process below: | ||
|
||
**Step 1.** Confirm the issue and determine if the supported version is affected; | ||
|
||
**Step 2.** Audit code to find similar issues; | ||
|
||
**Step 3.** Prepare fixes for the supported version. These fixes will be released as soon as possible. | ||
|
||
### **Community** | ||
|
||
If you have any suggestions on how we can improve this process, please submit a pull request and contribute to the project too! |