Modify security templates to include AppSec approval

Issue and merge request security templates were modified to require
AppSec approval. AppSec approval will be required on the merge request
targeting master.

It also simplifies issue security template by removing 'Security Release
Tracking Issue' link, since security issues are related to the Tracking
issue, it's not really necessary to also include it on the Links section

Related to https://gitlab.com/gitlab-com/gl-infra/delivery/-/issues/839

.gitlab/issue_templates/Security developer workflow.md

@@ -9,19 +9,17 @@ Set the title to: `Description of the original issue`
 ## Prior to starting the security release work
 
 - [ ] Read the [security process for developers] if you are not familiar with it.
-- [ ] 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`.
+- [ ] Mark this [issue as related] to the Security Release Tracking Issue. You can find it on the topic of the `#releases` Slack channel.
 - 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
 
+- [ ] Run `scripts/security-harness` in your local repository to prevent accidentally pushing to any remote besides `gitlab.com/gitlab-org/security`.
 - [ ] 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 been approved according to our [approval guidelines], you're ready to prepare the backports
+After your merge request has been approved according to our [approval guidelines] and by a team member of the AppSec team, you're ready to prepare the backports
 
 ## Backports
 
@@ -49,7 +47,6 @@ After your merge request has been approved according to our [approval guidelines
 | Description | Link |
 | -------- | -------- |
 | Issue on [GitLab](https://gitlab.com/gitlab-org/gitlab/issues) | #TODO  |
-| Security Release tracking issue | #TODO  |
 
 ### Details
 

.gitlab/merge_request_templates/Security Release.md

@@ -13,25 +13,33 @@ See [the general developer security release guidelines](https://gitlab.com/gitla
 ## Developer checklist
 
 - [ ] **On "Related issues" section, write down the [GitLab Security] issue it belongs to (i.e. `Related to <issue_id>`).**
-- [ ] Merge request targets `master`, or `X-Y-stable` for backports.
+- [ ] Merge request targets `master`, or a versioned stable branch (`X-Y-stable-ee`).
 - [ ] 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`
-- [ ] Assign to a reviewer and maintainer, per our [Code Review process].
+- [ ] A [CHANGELOG entry] is added without a `merge_request` value, with `type` set to `security`
 - [ ] For the MR targeting `master`:
-  - [ ] Ask for a non-blocking review from the AppSec team member associated to the issue in the [Canonical repository](https://gitlab.com/gitlab-org/gitlab). If you're unsure who to ping, ask on `#sec-appsec` Slack channel.
+  - [ ] Assign to a reviewer and maintainer, per our [Code Review process].
   - [ ] Ensure it's approved according to our [Approval Guidelines].
-- [ ] Merge request _must not_ close the corresponding security issue, _unless_ it targets `master`.
+  - [ ] Ensure it's approved by an AppSec engineer.
+    - If you're unsure who should approve, find the AppSec engineer associated to the issue in the [Canonical repository], or ask #sec-appsec on Slack.
+    - Trigger the [`package-and-qa` build]. The docker image generated will be used by the AppSec engineer to validate the security vulnerability has been remediated.
+  - [ ] Merge request _must_ close the corresponding security issue.
+- [ ] For a backport MR targeting a versioned stable branch (`X-Y-stable-ee`)
+  - [ ] Ensure it's approved by a maintainer.
 
 **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 and **when all backports including the MR targeting master are ready.**
 
 /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
+[CHANGELOG entry]: https://docs.gitlab.com/ee/development/changelog.html
+[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
+[Canonical repository]: https://gitlab.com/gitlab-org/gitlab
+[`package-and-qa` build]: https://docs.gitlab.com/ee/development/testing_guide/end_to_end/#using-the-package-and-qa-job