~securitylabel. Please use confidential issues for topics that should only be visible to team members at GitLab.
#securitychat channel for questions that don't seem appropriate to use the issue tracker or the internal email address for.
At a high level, the topic of security encompasses the
The Security team needs to be able to communicate the priorities of security related issues to the Product, Development, and Infrastructure teams. Here's how the team can set priorities internally for subsequent communication (inspired in part by how the support team does this).
~security and as appropriate also
~customer. Add Security Level priority labels (
~SL3) to indicate perceived priority inside the Security Team.
The reasoning behind adding an
~SL label to every of these issues is that each issue should have had someone consider the urgency and impact, and this is best done at time of creating the issue since that is when the information and context is "fresh" in your mind. It is OK to change the assessment and label at a later date upon reflection. When issues are filed without an
~SL label it will be unclear whether an issue lacks the label due to lack of urgency / impact, or due to missing a step in the process.
Use the following as a guideline to determine which Security Level Priority label to use for bugs and feature proposals. For this, consider the likelihood and impact of a security incident that could result from this issue not being resolved.
|Likelihood \ Impact||I1 - High||I2 - Medium||I3 - Low|
|L1 - High|| || || |
|L2 - Medium|| || || |
|L3 - Low|| || || |
Issues with an
SL1 rating should be immediately brought to the attention of the relevant product managers, and team leads by pinging them in the issue and/or escalating via email and chat if they are unresponsive.
Issues with an
SL3 rating should also be brought to the attention of product managers and team leads, but in the context of getting them scheduled for next (patch) releases; they should have a lower sense of urgency.