Add docs for security issue and MR associations

We've accumulated a bit of terminology around security release issues
and merge requests and how they all relate to each other, so a diagram
might be helpful.
parent 573c00d2
......@@ -16,7 +16,7 @@ At GitLab, we have two types of security releases:
Also see [the GitLab Maintenance Policy](
for the information on determining supported releases and assigning versions.
# General process overview
## General process overview
Release manager process is [described here]( The release
manager also makes sure that all the deadlines (described below) are
......@@ -29,7 +29,121 @@ Developers need to follow the process [defined here](
Quality engineers need to follow the process [defined here](
# Non-critical Security Releases
### Terminology
1. **Security vulnerability issue** - A confidential issue in a GitLab Canonical project (`gitlab-org/some-project`), detailing a security vulnerability and steps to reproduce.
Usually created via HackerOne.
Example: [gitlab-org/gitlab#193100](
1. **Security release tracking issue** - A confidential issue in `gitlab-org/gitlab` which is the high-level overview of an entire security release (critical or otherwise).
Created via [issue template](
Example: [gitlab-org/gitlab#209019](
1. **Security implementation issue** - An issue in a GitLab Security project (`gitlab-org/security/some-project`), outlining the versions affected, detailing the steps a developer needs to take to remediate the vulnerability, and associating backports.
Created via [issue template](
Example: [gitlab-org/security/gitlab#80](
1. **Security merge request (MR)** - A merge request in a GitLab Security project (`gitlab-org/security/some-project`), resolving a vulnerability in a specific branch.
Created via [merge request template](
Example: [gitlab-org/security/gitlab!314](
1. **Release task issue** - Used by [release managers] as a checklist of steps to complete the release.
Created via ChatOps (`/chatops run release prepare --security`).
Example: [gitlab-org/release/tasks#1272](
#### Issue association
graph RL
classDef canonical fill:#74bd3d
classDef security fill:#ff7272
secVuln(Security vulnerability Issue)
secRelease(Security release Issue)
secFix(Security implementation issue)
task{{Release task issue}}
class secVuln canonical
class secRelease canonical
class secFix security
secFix -->|references| secVuln
secFix ---|related| secRelease
task -.->|references| secRelease
#### Merge request association
graph RL
classDef canonical fill:#74bd3d
classDef security fill:#ff7272
secFix(Security implementation issue)
secMR1(["Security MR 1 (master)"])
secMR2(["Security MR 2 (backport)"])
secMR3(["Security MR 3 (backport)"])
secMR4(["Security MR 4 (backport)"])
class secFix security
class secMR1,secMR2,secMR3,secMR4 security
secMR1 -->|closes| secFix
secMR2 & secMR3 & secMR4 -.->|references| secFix
#### Merging
graph TD
classDef security fill:#ff7272
coMerge{{"/chatops run release merge --security"}}
coMergeMaster{{"/chatops run release merge --security --master"}}
secMR1(["Security MR 1 (master)"])
secMR2(["Security MR 2 (backport)"])
secMR3(["Security MR 3 (backport)"])
secMR4(["Security MR 4 (backport)"])
coMerge --> secMR2
coMerge --> secMR3
coMerge --> secMR4
secMR2 --> |merge| stable129
secMR3 --> |merge| stable128
secMR4 --> |merge| stable127
coMergeMaster --> secMR1
secMR1 --> |merge| master
master -.-> |cherry-pick| autodeploy
class secMR1,secMR2,secMR3,secMR4 security
class stable129,stable128,stable127 security
class master,autodeploy security
*NOTE:* The `--master` flag is not mutually exclusive and would also merge the backports if not already merged.
[release managers]:
## Non-critical Security Releases
Every 28th of the month, we are releasing patch versions of GitLab containing
non-critical security fixes. This date has been chosen as it gives enough
......@@ -37,7 +151,7 @@ time to release regular patch releases after standard release on the 22nd of
the month. This date also allows us to create and test fixes internally as
the next development cycle (starting on the 8th) starts.
## Release deadlines
### Release deadlines
Anything that can be carried out before the deadline, should be done.
Anything that is not done by the deadline requires immediate escalation to
......@@ -73,7 +187,7 @@ required because package promotion takes time to propagate.
Blog post, tweet and the email announcement should be complete by **10:00 Pacific time on the 28th**.
# Critical Security Releases
## Critical Security Releases
Depending on the severity and impact of the vulnerability, an
immediate patch release consisting of just the security fix may be warranted.
......@@ -134,7 +248,7 @@ completeness the process is written here:
Each involved role should follow their own guide, and create separate issues
linking to the main release issue.
# Guides by role
## Guides by role
- [Release Manager]
- [Security Engineer]
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment