@@ -90,7 +90,7 @@ At GitLab, there are two types of patch releases processes:
the [security remediation SLAs](/handbook/security/product-security/vulnerability-management/sla/). Patches that include
[`critical` vulnerabilities](/handbook/security/product-security/vulnerability-management/sla/) will be considered critical patches.
1.**Unplanned**: An immediate patch required outside of the planned patch release cadence to mitigate a high-severity (critical) vulnerability. These ad-hoc patches
are the result of an incident, they require a [security RCA](/handbook/security/root-cause-analysis/) done by the team that introduced the high-severity vulnerability and forced an unplanned release. The AppSec
are the result of an incident, they require a [security RCA](/handbook/security/root-cause-analysis/) done by the team that introduced the high-severity vulnerability and forced an unplanned release. The PSIRT
team is responsible for assessing the vulnerability, working with engineering to decide on the best approach to resolve it and coordinating with Release Managers
on a timeline for the release.
@@ -115,7 +115,7 @@ the respective [maintained versions](https://docs.gitlab.com/policy/maintenance/
- The merge requests are merged by a GitLab maintainer in the stable branch associated to the [maintained version](https://docs.gitlab.com/policy/maintenance/#maintained-versions).
-**Step 1b: Vulnerability fix prepared** - Engineers fix vulnerabilities in the relevant [Security repository](https://gitlab.com/gitlab-org/security). A fix is considered complete only when it has a [security implementation issue](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/security/terminology.md) with the following:
- All checkboxes checked to show all steps have been completed.
- An AppSec and Maintainer approved MR targeting the default branch.
- A PSIRT team member and Maintainer approved MR targeting the default branch.
- A backport MR for each intended version. In most cases this will mean 4 MRs to cover each supported version. Each MR must have passing pipelines, required approvals and be assigned to the release bot for processing.
- The `~"security-target"` label is applied. This will automatically review the issue and link it to the security tracking issue if it is ready.
@@ -185,6 +185,6 @@ Once a security merge request has been merged, it's not advisable to revert it f
If a security vulnerability introduced a non-vulnerability bug, in most cases, the appropriate path forward is to fix the issue in the canonical repository (after the patch release has been published).
If a security vulnerability introduced a high severity non-vulnerability bug, engage with AppSec and Release Managers to coordinate next steps.
If a security vulnerability introduced a high severity non-vulnerability bug, engage with PSIRT and Release Managers to coordinate next steps.
For more information, see [How to Mitigate Bugs Introduced by Security Merge Request](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/security/bugs_introduced_by_security_merge_request.md) runbook.
