Adds SECURITY.md to outline our security policies #2086
Conversation
| from a member of the website working group within 3 working days. After that, | ||
| the website working group will begin their analysis. Depending on the action | ||
| to be taken, you may receive followup emails. It can take several weeks before | ||
| the website working group comes to a conclusion and resolve the issue. |
There was a problem hiding this comment.
I have mostly just copied from Django's security policy. We might want to update.
There was a problem hiding this comment.
I'd remove or extend the 3 working days timeline, we don't need to set a timeline on ourselves like for the framework.
| - Confirm the problem. | ||
| - Audit code to find any potential similar problems. | ||
| - Apply the relevant patches to the codebase. | ||
| - Deploy the fixed codebase. |
There was a problem hiding this comment.
Do we know how we want to disclose a security issue, since for the website, we don't really need to make releases and ask users to update. Maybe this section should be titled differently. Thoughts?
There was a problem hiding this comment.
My first thought would be, do we even need a disclosure policy at all?
| to follow few guidelines that helps us in analysis and resolving the issue quicker. | ||
|
|
||
| - Include a runnable proof of concept to reproduce the issue | ||
| - User input must be sanitized |
There was a problem hiding this comment.
Are there other website specific guidelines we want to add?
There was a problem hiding this comment.
What does "User input must be sanitized" means in this context?
I'm not sure what it means, so it could also be confusing for a reporter.
As discussed in our last meeting, along with a
.well-known/security.txt, it's nice to have aSECURITY.mdto be shown as our security policy in the GitHub Security tab.This PR adds the policies for reporting a bug and disclosing.