Skip to content

Modify security templates to include AppSec approval

Mayra Cabrera requested to merge update-security-issue-and-mr-templates into master

What does this MR do?

Issue and merge request security templates were modified to require AppSec approval. AppSec approval will be required on the merge request targeting master.

It also simplifies the issue security template by removing 'Security Release Tracking Issue' link, since security issues are related to the Tracking issue, it's not really necessary to also include it on the Links section

Related to gitlab-com/gl-infra/delivery#839 (closed)

Examples

Security Issue

Prior to starting the security release work

  • Read the security process for developers if you are not familiar with it.
  • 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 TODOs, so make sure to complete those.
  • On the "Related merge requests" section, ensure all MRs are linked to this issue.
    • This section should only list the merge requests created for this issue: One targeting master and the 3 backports.

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

Security merge request

Related issues

Developer checklist

  • On "Related issues" section, write down the GitLab Security issue it belongs to (i.e. Related to <issue_id>).
  • Merge request targets master, or a versioned stable branch (X-Y-stable-ee).
  • Milestone is set for the version this merge request applies to. A closed milestone can be assigned via quick actions.
  • Title of this merge request is the same as for all backports.
  • A CHANGELOG entry is added without a merge_request value, with type set to security
  • For the MR targeting master:
    • Assign to a reviewer and maintainer, per our Code Review process.
    • Ensure it's approved according to our Approval Guidelines.
    • Ensure it's approved by an AppSec engineer.
      • If you're unsure who should approve, find the AppSec engineer associated to the issue in the Canonical repository, or ask #sec-appsec on Slack.
      • Trigger the package-and-qa build. The docker image generated will be used by the AppSec engineer to validate the security vulnerability has been remediated.
    • Merge request must close the corresponding security issue.
  • For a backport MR targeting a versioned stable branch (X-Y-stable-ee)
    • Ensure it's approved by a maintainer.

Note: Reviewer/maintainer should not be a Release Manager

Maintainer checklist

  • Correct milestone is applied and the title is matching across all backports
  • Assigned to @gitlab-release-tools-bot with passing CI pipelines and when all backports including the MR targeting master are ready.

Does this MR meet the acceptance criteria?

Conformity

Edited by Mayra Cabrera

Merge request reports