debian-mirror-gitlab/.gitlab/issue_templates/Security developer workflow.md at ecad3f3e663eaf426e6a649c53a3cc537a5b3c77

Read the security process for developers if you are not familiar with it.
Link to the original issue adding it to the links section
Run scripts/security-harness in the CE, EE, and/or Omnibus to prevent pushing to any remote besides dev.gitlab.org
Create an MR targetting org master, prefixing your branch with security-
Label your MR with the ~security label, prefix the title with WIP: [master]
Add a link to the MR to the links section
Add a link to an EE MR if required
Make sure the MR remains in-progress and gets approved after the review cycle, but never merged.
Assign the MR to a RM once is reviewed and ready to be merged. Check the RM list to see who to ping.

Once the MR is ready to be merged, create MRs targetting the last 3 releases
- 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 seckpick documentation
- Create the branch security-X-Y from X-Y-stable if it doesn't exist (and make sure it's up to date with stable)
- Create each MR targetting the security branch security-X-Y
- Add the ~security label and prefix with the version WIP: [X.Y] the title of the MR
Make sure all MRs have a link in the links section and are assigned to a Release Manager.

Check the topic on #security to see when the next release is going to happen and add a link to the links section
Find out the versions affected (the Git history of the files affected may help you with this) and add them to the details section
Fill in any upgrade notes that users may need to take into account in the details section
Add Yes/No and further details if needed to the migration and settings columns in the details section
Add the nickname of the external user who found the issue (and/or HackerOne profile) to the Thanks row in the details section

/label ~security