diff --git a/general/security/security-engineer.md b/general/security/security-engineer.md index b22edf4615489b53e49b85a6c21bfdd7ff5d0c0e..d71f6a0a64fe82230f2e4884555632c7afc7211d 100644 --- a/general/security/security-engineer.md +++ b/general/security/security-engineer.md @@ -5,6 +5,10 @@ The main difference is in who initiates the release process. * **[Regular](#regular-security-releases)** security releases are scheduled monthly and are initiated by the release management team. ## Dependencies updates +:warning: __Dependency updates are not added by the security release script__. You __must__ add it manually. + +:warning: When updating the blog post, make sure to keep the text related to dependency updates otherwise you will have to type it down again. + Fixes that mitigate 3rd party vulnerabilities are typically added at the end of the blog post with a reference to the existing CVE ID that was assigned to that vulnerability by the 3rd party. [Example of previously used wording](https://about.gitlab.com/releases/2020/03/26/security-release-12-dot-9-dot-1-released/): @@ -15,6 +19,7 @@ The Nokogiri dependency has been upgraded to 1.10.8. This upgrade include a secu ## Overall process +1. Make sure to get a copy of the security release scripts [here](https://gitlab.com/gitlab-com/gl-security/appsec/appsec-team), or `git clone git@gitlab.com:gitlab-com/gl-security/appsec/appsec-team.git` 1. [Prepare blog post](#prepare-blog-post) 1. Follow the appropriate sub-process for a [critical](#critical-security-releases) or [regular](#regular-security-releases) security release 1. [Verify fixes](#verify-fixes) @@ -27,26 +32,12 @@ For all steps in the process, keep in mind that there might be a [GitLab Runner * :warning: The developer should have provided the range of affected versions: ask on the related security issues to provide it if not already provided. * This is required to [request CVEs]. See also [GitLab's CVE Numbering Authority page](https://about.gitlab.com/security/cve/). -* Create a branch for the `Draft` blog post merge request that will go in the [security www-gitlab-com repo](https://gitlab.com/gitlab-org/security/www-gitlab-com). - 1. On the merge request branch in the [security www-gitlab-com repo](https://gitlab.com/gitlab-org/security/www-gitlab-com), make a file in the `sites/marketing/source/releases/posts` with this format: **`YYYY-MM-DD-security-release-gitlab-X-X-X-released.html.md`**. - 1. Make sure that `Draft:` is prepended to the blog post merge request title until it has been reviewed, approved, and the packages have been built and ready for release. - 1. Ensure to add the CVE IDs, vulnerability descriptions, affected versions, remediation info, and a thank you to the reporter. - * Much of this information can be copy and pasted from the [summary table] in the developer security issue created on [GitLab Security]. - 1. Feel free to use a past security release as a guide, for example [this blog post](https://about.gitlab.com/releases/2020/07/01/security-release-13-1-2-release/). -* Please make sure the `tags` section of the post header includes the `security` tag, like so: `tags: security` -* Please add `/images/blogimages/security-cover-new.png` to the `image_title:` field in the front matter. -* Please include a "Receive Security Release Notifications" section at the very bottom of the blog post with links to our contact us page and RSS feed. See previous security release posts or [this issue](https://gitlab.com/gitlab-com/gl-security/security-communications/communications/issues/145#note_240450797) for examples. +* You can generate a preview of the blog post by using the security release script with the following command : `ruby make_blogpost.rb -e youremail@gitlab.com -f 'Your Full GitLab name'` * Make sure that the blog post only mentions fixes that actually made it into the release. Consider the [48h deadline before the Security Release due date](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/security/process.md#security-release-deadlines), every issue associated (even after the deadline) will likely not be included and we should ensure it's not mentioned on the blog post. For anything that was removed, please comment on the related security issue with the blog post text that you have written. +* Once every issue is linked, the versions have been provided, and the security release versions are known you can generate the draft blog post by using the security release script with the following command: `ruby make_blogpost.rb -d -e youremail@gitlab.com -f 'Your full name'`. It will generate the blog post content, but not all headers will be properly generated (you don't need to touch it since the script will automatically modify it with the proper values when publishing the blog post) + * You can update the draft blog post: `ruby make_blogpost.rb -u -e youremail@gitlab.com -f 'Your Full GitLab name'`. Make sure to add again any dependency related information on the draft blog post since they are not added by the script. * Assign the blog post to another member of the appsec team for review. -* Create a WIP issue using the `Security Release Email Alert` template in https://gitlab.com/gitlab-com/gl-security/security-communications/communications/issues for the communications team and request an email notification be sent to subscribers of the `Security Alert` segment on the day of the release. Include a note that this should be sent out **after** the blog post is live. Also mention that you'll include the link to the blog post MR once it is prepared. The content of this notification should be similar to the blog post introduction: - ->"Today we are releasing versions X.X.X, X.X.X, and X.X.X for GitLab Community Edition (CE) and Enterprise Edition (EE). - ->These versions contain a number of important security fixes, and we strongly recommend that all GitLab installations be upgraded to one of these versions immediately. - ->Please forward this alert to appropriate people at your organization and have them subscribe to [Security Notices](https://about.gitlab.com/contact/). You can also receive security release blog updates by subscribing to our [RSS feed](https://about.gitlab.com/security-releases.xml). - ->For more details about this release, please visit our [blog](TODO)." +* Once the draft blog post is finalized, you can create a communication issue for the communication team: `ruby make_blogpost.rb -m -e youremail@gitlab.com -f 'Your Full GitLab name'`. Then request an email notification be sent to subscribers of the `Security Alert` segment on the day of the release. Include a note that this should be sent out **after** the blog post is live. Also mention that you'll include the link to the blog post MR once it is prepared. The content of the notification is automatically added (see template [here](https://gitlab.com/gitlab-com/gl-security/appsec/appsec-team/-/blob/master/security_release_email_alert_body.md)). ### Regular security releases @@ -82,8 +73,8 @@ publishing: * Release manager starts publishing the packages * **When the Release Managers notify about the packages being published:** - * Create a merge request in the [Canonical www-gitlab-com repo](https://gitlab.com/gitlab-com/www-gitlab-com) with the path under `sites/marketing/sou‎rce/releases/posts/‎` and ask that the Release Managers merge it in. -* Put the link of the new blog post in the email notification request issue as well as the security release issue + * Create a merge request and copy the blog post in the [Canonical www-gitlab-com repo](https://gitlab.com/gitlab-com/www-gitlab-com) with the path under `sites/marketing/sou‎rce/releases/posts/‎`. This is done automatically by running `ruby make_blogpost.rb -r -e youremail@gitlab.com -f 'Your Full GitLab name'` and ask that the Release Managers merge it in. +* Put the link of the new blog post in the email notification request issue (it is automatically added to the security release issue) * Make sure the CVE IDs are documented in the corresponding GitLab.com issues and H1 reports * Ping in H1 reports the appsec team member who triaged the issue to notify a fix has been released * Close out the issues on `gitlab-org/gitlab` and the draft blog post merge request that was created in the [security www-gitlab-com repo](https://gitlab.com/gitlab-org/security/www-gitlab-com)