Security Team

On this page

Security topics

At a high level, the topic of security encompasses the

  1. application
  2. infrastructure of GitLab.com
  3. organization and internal processes

Issue Triage

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).

Use labels

Always. Use ~security and as appropriate also ~bug, ~feature proposal, ~customer. Add Security Level priority labels ( ~SL1, ~SL2, ~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.

Security Priority Labels

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 SL1 SL1 SL2
L2 - Medium SL1 SL2 SL3
L3 - Low SL2 SL3 SL3

Escalating from the Security Team to the Development Team

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 SL2 or 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.

Note

Security releases

The processes for security releases is described with a checklist of events on the critical release process page, as well as in the release-tools project.