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.
  • 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.
  • If the issue you're fixing doesn't appear to be something that can be exploited by a malicious person and is instead simply a security enhancement do not hesitate to ping @gitlab-com/gl-security/appsec to discuss if the issue can be fixed in the canonical repository.
• IMPORTANT: Mark this issue as linked to the Security Release Tracking Issue. You can find it on the topic of the #releases Slack channel. 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.
• Add one of the ~severity::x labels to the issue and all associated merge requests.

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
  • 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

• 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