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.
• Make sure the issue really needs to follow the security release workflow.
• Add a ~severity::x label to the issue and all associated merge requests.
• IMPORTANT: Mark this issue as linked to the Security Release Tracking Issue. You can find it here. This issue MUST be linked for the release bot to know that the associated merge requests should be merged for this security release.
• Fill out the Links section:
  • Next to Issue on GitLab, add a link to the gitlab-org/gitlab issue that describes the security vulnerability.
• If this change affects the public interface (public API or UI) of the product, post in the #support_gitlab-com Slack channel to explain the impact and discuss a mitigation plan for users that might be affected. If you need Support feedback or approval, reach out in #spt_managers Slack channel or mention @gitlab-com/support/managers.

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.
• If this includes a breaking change, make sure to include a mention of it for the relevant versions in doc/update/index.md

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
  • The 3 stable branches correspond to the versions in the title of the Security Release Tracking Issue.
  • 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

• To avoid release delays, please nominate a developer in a different timezone who will be able to respond to any pipeline or merge failures in your absence @gitlab-username
• Ensure ~severity::x label is on this issue, all associated issues, and merge requests
• 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
CVE ID request on gitlab-org/cves	#TODO for AppSec

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
Breaking change to UI or public API	Yes/No
Thanks

/label ~security