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

Prior to starting the security release work

• Read the security process for developers if you are not familiar with it.
  • Verify if the issue you're working on gitlab-org/gitlab is confidential, if it's public fix should be placed on GitLab canonical and no backports are required.
• 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:
  • Next to Issue on GitLab, add a link to the gitlab-org/gitlab issue that describes the security vulnerability.

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.

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

• 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 to-dos, so make sure to complete those.
• On the "Related merge requests" section, ensure that 4 merge requests are associated: The one targeting master and the 3 backports.
• If this issue requires less than 4 merge requests, post a message on the Security Release Tracking Issue and ping the Release Managers.

Documentation and final details

• Ensure the Links section is completed.
• Add the GitLab versions and editions affected to the details section
  • The Git history of the files affected may help you associate the issue with a release
• 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

Summary

Links

Description	Link
Issue on GitLab	#TODO

Details

Description	Details	Further details
Versions affected	X.Y
GitLab EE only	Yes/No
Upgrade notes
GitLab Settings updated	Yes/No
Migration required	Yes/No
Thanks

/label ~security