Modify security templates to include AppSec approval
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 besidesgitlab.com/gitlab-org/security
. -
Create a new branch prefixing it with security-
. -
Create a merge request targeting master
ongitlab.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.
- This section should only list the merge requests created for this issue: One targeting
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, withtype
set tosecurity
-
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