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

/label ~security