Add latest changes from gitlab-org/security/gitlab@12-6-stable-ee

.gitlab/issue_templates/Security developer workflow.md

 <!--
 # Read me first!
-Create this issue under https://dev.gitlab.org/gitlab/gitlabhq
+Create this issue under https://gitlab.com/gitlab-org/security
 Set the title to: `Description of the original issue`
 -->
-### Prior to starting the security release work
+## Prior to starting the security release work
 - [ ] Read the [security process for developers] if you are not familiar with it.
-- [ ] Link to the original issue adding it to the [links section](#links)
-- [ ] Run `scripts/security-harness` in the CE, EE, and/or Omnibus to prevent pushing to any remote besides `dev.gitlab.org`
-- [ ] Create a new branch prefixing it with `security-`
-- [ ] Create a MR targeting `dev.gitlab.org` `master`
-- [ ] Add a link to this issue in the original security issue on `gitlab.com`.
-#### Backports
-- [ ] Once the MR is ready to be merged, create MRs targeting the latest 3 stable branches
-    - [ ] At this point, it might be easy to squash the commits from the MR into one
-    - You can use the script `bin/secpick` instead of the following steps, to help you cherry-picking. See the [secpick documentation]
-    - [ ] Create each MR targeting the stable branch `X-Y-stable`, using the "Security Release" merge request template.
-    - Every merge request will have its own set of TODOs, so make sure to
-      complete those.
-- [ ] Make sure all MRs have a link in the [links section](#links)
-[secpick documentation]: https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md#secpick-script
-#### Documentation and final details
-- [ ] Check the topic on #releases to see when the next release is going to happen and add a link to the [links section](#links)
-- [ ] Add links to this issue and your MRs in the description of the security release issue
+- [ ] Mark this [issue as related] to the Security Release tracking issue. You can find it on the topic of the `#releases` Slack channel.
+- [ ] Run `scripts/security-harness` in your local repository to prevent accidentally pushing to any remote besides `gitlab.com/gitlab-org/security`.
+- Fill out the [Links section](#links):
+  - [ ] Next to **Issue on GitLab**, add a link to the `gitlab-org/gitlab` issue that describes the security vulnerability.
+  - [ ] Next to **Security Release tracking issue**, add a link to the security release issue that will include this security issue.
+## Development
+- [ ] Create a new branch prefixing it with `security-`.
+- [ ] Create a merge request targeting `master` on `gitlab.com/gitlab-org/security` and use the [Security Release merge request template].
+- [ ] Follow the same [code review process]: Assign to a reviewer, then to a maintainer.
+After your merge request has being approved according to our [approval guidelines], you're ready to prepare the backports
+## Backports
+
+- [ ] Once the MR is ready to be merged, create MRs targeting the latest 3 stable branches
+   * At this point, it might be easy to squash the commits from the MR into one
+   * You can use the script `bin/secpick` instead of the following steps, to help you cherry-picking. See the [secpick documentation]
+- [ ] Create each MR targeting the stable branch `X-Y-stable`, using the [Security Release merge request template].
+   * Every merge request will have its own set of TODOs, so make sure to complete those.
+- [ ] On the "Related merge requests" section, ensure all MRs are linked to this issue.
+   * This section should only list the merge requests created for this issue: One targeting `master` and the 3 backports.
+## Documentation and final details
+
+- [ ] Ensure the [Links section](#links) is completed.
 - [ ] Find out the versions affected (the Git history of the files affected may help you with this) and add them to the [details section](#details)
 - [ ] Fill in any upgrade notes that users may need to take into account in the [details section](#details)
 - [ ] Add Yes/No and further details if needed to the migration and settings columns in the [details section](#details)
 - [ ] Add the nickname of the external user who found the issue (and/or HackerOne profile) to the Thanks row in the [details section](#details)
 - [ ] Once your `master` MR is merged, comment on the original security issue with a link to that MR indicating the issue is fixed.
-### Summary
-#### Links
+## Summary
+### Links
 | Description | Link |
 | -------- | -------- |
-| Original issue   | #TODO  |
-| Security release issue   | #TODO  |
-| `master` MR | !TODO   |
-| `master` MR (EE) | !TODO   |
-| `Backport X.Y` MR | !TODO   |
-| `Backport X.Y` MR | !TODO   |
-| `Backport X.Y` MR | !TODO   |
-| `Backport X.Y` MR (EE) | !TODO   |
-| `Backport X.Y` MR (EE) | !TODO   |
-| `Backport X.Y` MR (EE) | !TODO   |
-
-#### Details
+| Issue on [GitLab](https://gitlab.com/gitlab-org/gitlab/issues) | #TODO  |
+| Security Release tracking issue | #TODO  |
+
+### Details
 | Description | Details | Further details|
 | -------- | -------- | -------- |
@@ -65,6 +62,10 @@ Set the title to: `Description of the original issue`
 | Thanks | | |
 [security process for developers]: https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md
-[RM list]:  https://about.gitlab.com/release-managers/
+[secpick documentation]: https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md#secpick-script
+[security Release merge request template]: https://gitlab.com/gitlab-org/security/gitlab/blob/master/.gitlab/merge_request_templates/Security%20Release.md
+[code review process]: https://docs.gitlab.com/ee/development/code_review.html
+[approval guidelines]: https://docs.gitlab.com/ee/development/code_review.html#approval-guidelines
+[issue as related]: https://docs.gitlab.com/ee/user/project/issues/related_issues.html#adding-a-related-issue
 /label ~security

.gitlab/merge_request_templates/Security Release.md

 <!--
 # README first!
-This MR should be created on `dev.gitlab.org`.
+This MR should be created on `gitlab.com/gitlab-org/security/gitlab`.
 See [the general developer security release guidelines](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md).
-This merge request _must not_ close the corresponding security issue _unless_ it
-targets master.
-
-When submitting a merge request for CE, a corresponding EE merge request is
-always required. This makes it easier to merge security merge requests, as
-manually merging CE into EE is no longer required.
-
 -->
+
 ## Related issues
-<!-- Mention the issue(s) this MR is related to -->
+<!-- Mention the GitLab Security issue this MR is related to -->
 ## Developer checklist
-- [ ] Link to the developer security workflow issue on `dev.gitlab.org`
-- [ ] MR targets `master`, or `X-Y-stable` for backports
-- [ ] Milestone is set for the version this MR applies to
-- [ ] Title of this MR is the same as for all backports
+- [ ] **Make sure this merge request mentions the [GitLab Security] issue it belongs to (i.e. `Related to <issue_id>`).**
+- [ ] Merge request targets `master`, or `X-Y-stable` for backports.
+- [ ] Milestone is set for the version this merge request applies to. A closed milestone can be assigned via [quick actions].
+- [ ] Title of this merge request is the same as for all backports.
 - [ ] A [CHANGELOG entry](https://docs.gitlab.com/ee/development/changelog.html) is added without a `merge_request` value, with `type` set to `security`
-- [ ] Add a link to this MR in the `links` section of related issue
-- [ ] Set up an EE MR (always required for CE merge requests): EE_MR_LINK_HERE
-- [ ] Assign to a reviewer (that is not a release manager)
-## Reviewer checklist
+- [ ] Assign to a reviewer and maintainer, per our [Code Review process].
+- [ ] For the MR targeting `master`:
+  - [ ] Ping appsec team member who created the issue and ask for a non-blocking review with `Please review this MR`.
+  - [ ] Ensure it's approved according to our [Approval Guidelines].
+- [ ] Merge request _must not_ close the corresponding security issue, _unless_ it targets `master`.
+**Note:** Reviewer/maintainer should not be a Release Manager
+## Maintainer checklist
 - [ ] Correct milestone is applied and the title is matching across all backports
 - [ ] Assigned to `@gitlab-release-tools-bot` with passing CI pipelines
 /label ~security
+
+[GitLab Security]: https://gitlab.com/gitlab-org/security/gitlab
+[approval guidelines]: https://docs.gitlab.com/ee/development/code_review.html#approval-guidelines
+[Code Review process]: https://docs.gitlab.com/ee/development/code_review.html
+[quick actions]: https://docs.gitlab.com/ee/user/project/quick_actions.html#quick-actions-for-issues-merge-requests-and-epics