## Context This issue loops in PSIRT on the proposal in [epic 1755](https://gitlab.com/groups/gitlab-com/gl-infra/-/work_items/1755) to block post-deployment migrations on security MRs. Per the epic's Plan / Meta section, this issue will serve as the dedicated conversation with PSIRT to gather their thoughts and approval. ## Background ### Problem statement Post-deployment migrations executed in production establish a point of no return, once they run rollback is unavailable. During patch release windows that risk is concentrated, and the only mitigation is roll-forward, which takes 6+ hours and is subject to pipeline failures and flaky tests. https://gitlab.com/gitlab-com/gl-infra/production/-/issues/19280 is an example of an incident that didn't have a rollback option due to an unrelated PDM ### Historical data (full table in the [epic](https://gitlab.com/groups/gitlab-com/gl-infra/-/work_items/1755#:~:text=GitLab.com%20reliability.-,Data,-Data%20up%20to)). Through 2026-06-03. From the data we can see that: - ~1,274 security fixes total - 16 (~1.3%) are direct security-fix MRs containing PDMs (the epic table also lists 9 mirror-syncs of canonical changes for transparency) - Breakdown by [type](https://gitlab.com/gitlab-com/gl-infra/delivery/-/work_items/21612#note_3340915317): - 🟢 Type 1 (housekeeping; block): **6** - 🟡 Type 2 (cleanup of existing data; block + PSIRT sign-off): **9** (3 are severity::1 or severity::2) - 🔴 Type 3 (migration is the fix; escalation): **1** (`security!3962`) - Operations span DML (data updates) and DDL (indexes, foreign keys, background migrations) - Severity range: severity::1 to severity::3; past production incidents include [security!1095](https://gitlab.com/gitlab-org/security/gitlab/-/merge_requests/1095) which directly caused one #### Precedent https://gitlab.com/gitlab-com/gl-infra/delivery/-/work_items/1739) established the same pattern for feature flags — Danger rule + runbook + docs update. ### Proposal under review Block post-deployment migrations on security MRs this has already been scoped under the epic: - **Danger rule:** a CI check in `gitlab-org/gitlab` that detects post-deploy migration files (`db/post_migrate/...`) in security MRs and fails the pipeline with a message pointing to the runbook. Modelled on the existing feature-flag Danger rule and backported to maintained versions. ### Discussion as of 13-05-2026 (picked from https://gitlab.com/gitlab-com/gl-infra/delivery/-/work_items/21612#note_3338731688) A thread was started on https://gitlab.com/gitlab-com/gl-infra/delivery/-/work_items/21612. With the following key points: @fvpotvin in https://gitlab.com/gitlab-com/gl-infra/delivery/-/work_items/21612#note_3340915317 dug into the 14 historical cases and proposed splitting the migrations into three types: 1. Housekeeping migrations that the fix doesn't depend on can be banned, follow-up lands in the regular cycle with no exposure gap. 2. Cleanup of existing data can also be banned since the patch closes the path forward, but existing records stay vulnerable until the cleanup ships. However **PSIRT sign-off should explicitly weigh that gap window**, especially on higher severities. 3. Migrations that are part of the fix itself example https://gitlab.com/gitlab-org/security/gitlab/-/merge_requests/3962, decoupling such a migration would mean shipping the schema change in a patch and the actual fix later. This would need an escalation path rather than blocking it. A joint delivery Appsec approval similar to how the MR was handled. ### Concerns - Should we implement a policy that blocks post-deployment migrations on security MRs as the default and have an escalation path/ review process for migrations that are part of the fix itself? - How would this policy look like in practice and how do we prevent accidental merges if the process isn't followed? - The suggestion "PSIRT sign-off should explicitly weigh the gap window on higher severities." How would the sign-off look like operationally? A comment? An approval rule? A separate process? - How do we design the escalation path so it doesn't reintroduce the "routine post-deploy migration on security MR" pattern?