diff --git a/general/security/developer.md b/general/security/developer.md index 184a95e37532c6f46170ea2a5222fb56365449b8..1c9700830046cc158b9094a104fd43d0744f8d12 100644 --- a/general/security/developer.md +++ b/general/security/developer.md @@ -11,9 +11,8 @@ is not disclosing the vulnerability or the fix before we're ready to publicly disclose it. To that end, you'll need to be sure that all of the development for a fix -happens on [dev.gitlab.org], because it's not publicly-accessible. - -[dev.gitlab.org]: https://dev.gitlab.org/ +happens in the [`gitlab-org/security`][security group] group, because it's not +publicly accessible. ## Process @@ -22,47 +21,49 @@ the vulnerability. In this case, it should be a confidential issue on [gitlab.com]. Once a security issue is assigned to a developer, we follow the same merge -request and code review process as any other change, but on [dev.gitlab.org]. -All security fixes are released for [at least three monthly releases], and you -will be responsible for creating backports as well. +request and code review process as any other change, but in the [security +group]. All security fixes are released for [at least three monthly releases], +and you will be responsible for creating backports as well. -When working on a high severity ~S1 issue, the initial work on a [post-deployment patch](#creating-a-post-deployment-patch) as described below, may be done before any -other tasks in the normal workflow at the request of the security engineer, with -the review of the delivery team and infrastructure team as outlined in the -post-deployment patch process. +When working on a high severity ~S1 issue, the initial work on a +[post-deployment patch](#creating-a-post-deployment-patch) (described below) may +be done before any other tasks in the normal workflow at the request of the +security engineer, with the review of the delivery team and infrastructure team +as outlined in the post-deployment patch process. [gitlab.com]: https://gitlab.com/ ### Preparation -- Before starting, run `scripts/security-harness` in the CE/EE repo you will implement - the fix in. This script will install a Git `pre-push` hook that will prevent - pushing to any remote besides `dev.gitlab.org`, in order to prevent accidental +- Before starting, run `scripts/security-harness` in the affected repository. + This script will install a Git `pre-push` hook that will prevent pushing to + any remote besides `gitlab-org/security`, in order to prevent accidental disclosure. - Please make sure the output of running `scripts/security-harness` is + + Ensure the output of running `scripts/security-harness` is + ``` - Security harness installed -- you will only be able to push to dev.gitlab.org! + Security harness installed -- you will only be able to push to security repositories! ``` -- [Create a new issue on org](https://dev.gitlab.org/gitlab/gitlabhq/issues/new?issuable_template=Security+developer+workflow) using the [Security Developer Workflow] template. - Security vulnerabilities that exist in **both** CE and EE should be fixed in - the [CE project on org](https://dev.gitlab.org/gitlab/gitlabhq), and a corresponding MR is required for EE in order to avoid unexpected conflicts and failing tests. + the [CE project](https://gitlab.com/gitlab-org/security/security-ce), and a + corresponding MR is required for EE in order to avoid unexpected conflicts and + failing tests.. - Security vulnerabilities that exist only in EE should be fixed in the [EE - project on org](https://dev.gitlab.org/gitlab/gitlab-ee). -- Security vulnerabilities that exist in Omnibus should be fixed in the [Omnibus - project on org](https://dev.gitlab.org/gitlab/omnibus-gitlab). - -[security developer workflow]: https://dev.gitlab.org/gitlab/gitlabhq/blob/master/.gitlab/issue_templates/Security%20developer%20workflow.md + project](https://gitlab.com/gitlab-org/security/security-ee). +- Security vulnerabilities in other public projects should be fixed in the + corresponding [`gitlab-org/security`][security group] project. ### Branches -Because all security fixes go into [at least three monthly releases] (which -includes the current/next one), you'll be creating at least three branches for -your fix. Merge requests for previously released versions should target the -appropriate stable branches. For example, a fix for version 11.2.3 should -target the branch `11-2-stable`. In the past we used to target dedicated -security branches, but this is no longer the case. +Because all security fixes go into [at least three monthly releases], you'll be +creating at least three branches for your fix. Merge requests for previously +released versions should target the appropriate stable branches. For example, a +fix for version 11.2.3 should target the branch `11-2-stable`. -Your branch name must start with `security`, such as: `security-rs-milestone-xss-10-6`. +As an additional safety measure, public projects have push rules preventing +branches beginning with `security` from being pushed, so be sure to name your +branch beginning with `security`, such as `security-rs-milestone-xss-10-6`. Branch names that start with `security` will be rejected upon a push from the CE and EE repositories on GitLab.com. This helps ensure security merge requests don't get @@ -70,30 +71,21 @@ leaked prematurely. ### Development -#### Create an issue - -On `dev.gitlab.org`, create an issue and select `Security developer workflow` on the template dropdown. The title should be the same as the original one created on `gitlab.com`, for example: `Prevent stored XSS in code blocks`. - -This issue is now your "Implementation issue" and a single source of truth for -all related issues and merge requests. Once the issue is created, assign it to yourself and start working on the tasks. - #### Create merge requests -Open a merge request in the relevant [dev.gitlab.org] project and use the `Security Release` merge request template. -Target the `X-Y-stable` branch that belongs to the target version. -Change the milestone to `X-Y` (e.g. a `11-10-stable` backport MR would have `11.10` set as its milestone). +Open a merge request in the relevant [security group] project using the +`Security Release` template. Target the `X-Y-stable` branch that corresponds to +the target version. -Once your merge requests are created, you should update the security developer workflow issue to include links to all of them. - -**IMPORTANT** All MRs created need to have green pipelines, correct labels and milestones set. In case one of these items is missing or incorrect, release managers will re-assign all related merge requests to the original author and remove the issue from the current security release. -This is necessary due to the number of merge requests that need to be handled for each security release. MRs are to be merged by RMs only. +Follow the steps in the template closely, as failing to do so could prevent the +fix from being included in a security release. #### Creating a post-deployment patch For high severity ~S1 issues, a post-deployment patch may be required. If a post-deployment patch was not already created as part of the initial response -to an ~S1 issue, verify with the security engineer if one is required. If an +to an ~S1 issue, verify with a security engineer if one is required. If an existing patch exists, work with the security engineer to determine if the temporary patch should be replaced with one based on the completed solution. @@ -101,26 +93,19 @@ Follow the [post-deployment patch process](../deploy/post-deployment-patches.md) ### `secpick` script -This is a small script that helps cherry-picking across multiple releases. It will stop -if there is a conflict while cherry-picking, otherwise will push the change to `org`. +This is a small script that helps cherry-picking across multiple releases. It +will stop if there is a conflict while cherry-picking, otherwise it will push the +change to the corresponding [security group] project. -The list of options available running: +View the list of options available by running: -``` +```sh $ bin/secpick --help ``` -For example: - -``` -bin/secpick -v 10.6 -b security-fix-mr-issue -s SHA -``` - -It will change local branches to push to a new security branch for each specified release, -meaning that local changes should be saved prior to running the script. - -This is only useful if we have squashed the original MR commits into a single one, easier -to cherry-pick. +It will change local branches to push to a new security branch for each +specified release, meaning that local changes should be saved prior to running +the script. ### Final steps @@ -137,8 +122,8 @@ branch to ensure that it's included in all future releases. The release manager the MR, so make sure all the MRs, including the MR targeting the master branch have the `security` label. -Be sure to run `scripts/security-harness` again to enable pushing to remotes -other than `dev.gitlab.org`! +Be sure to run `scripts/security-harness` again to enable pushing to all +remotes! ### Questions? @@ -149,4 +134,5 @@ channel in Slack. [Return to Security Guide](process.md) +[security group]: https://gitlab.com/gitlab-org/security [at least three monthly releases]: https://docs.gitlab.com/ee/policy/maintenance.html#security-releases diff --git a/general/security/process.md b/general/security/process.md index ab0dd87e475ab6a3b3f17c5b9aadd8efc659306c..f57ee13b44f6332cc331a23aa18fba044ddf16cc 100644 --- a/general/security/process.md +++ b/general/security/process.md @@ -18,16 +18,16 @@ for the information on determining supported releases and assigning versions. # General process overview -Release manager process is [described here](release-manager.md). The release +Release manager process is [described here][Release Manager]. The release manager also makes sure that all the deadlines (described below) are respected. Any delay needs to be escalated to Director of Backend and Security. -Security engineers need to follow the process [defined here](security-engineer.md). +Additional documentation per role is also available: -Developers need to follow the the process [defined here](developer.md). - -Quality engineers need to follow the process [defined here](quality.md). +* [Backend and Frontend engineers][Developer] +* [Quality engineers][Quality Engineer] +* [Security engineers][Security Engineer] # Non-critical Security Releases @@ -35,7 +35,7 @@ Every 28th of the month, we are releasing patch versions of GitLab containing non-critical security fixes. This date has been chosen as it gives enough time to release regular patch releases after standard release on the 22nd of the month. This date also allows us to create and test fixes internally as -the next development cycle (starting on the 8th) starts. +the next development cycle (starting on the 8th) begins. ## Release deadlines diff --git a/general/security/release-manager.md b/general/security/release-manager.md index ffc57c438a6faba18cb11c24e8deb141755278ae..e22016db9b0e4641350ab25ddbafd2081dc87a3b 100644 --- a/general/security/release-manager.md +++ b/general/security/release-manager.md @@ -28,24 +28,17 @@ publicly before we're ready to disclose them. ### Process When working on a security release, it's important that all work happens -**only** on [dev.gitlab.org], so nothing is disclosed publicly before we intend -it. +**only** in the [`gitlab-org/security`][security group] group, so nothing is +disclosed publicly before we intend it. You should run `scripts/security-harness` in the CE, EE, and Omnibus projects in -order to prevent accidental pushes to any remote other than `dev.gitlab.org`. +order to prevent accidental pushes to any remote other than +`gitlab-org/security`. We normally try to avoid releasing security packages to the community on Friday in order to avoid situations where a customer may be exploited during the weekend. -[dev.gitlab.org]: https://dev.gitlab.org/ - -### Security branches - -Developers [work off of security branches](developer.md#branches). As the -release manager, you'll be merging fixes straight into the stable branches -whenever a fix is ready. - ## Critical From a release manager standpoint, a critical security release requires drafting @@ -54,8 +47,8 @@ security release](#non-critical). ### Creating a release plan -When a [Security Engineer] initiates a critical security release, release -managers' first responsibility is creating a release timeline. +When a [Security Engineer] initiates a critical security release, a release +manager's first responsibility is creating a release timeline. It is important to note that "critical" does not mean that the release needs to happen the very moment it's requested. There might be multiple release tasks @@ -125,8 +118,8 @@ teams. 1. Security Release Issue - [Security Engineer] opens the confidential issue for security releases on gitlab.com. - This is a meta issue, each version to be released will have its own issue. + A [Security Engineer] opens the confidential issue for security releases on gitlab.com. + This is a meta issue, each patch version to be released will have its own issue. 1. Merge Request that need to be picked @@ -138,25 +131,12 @@ teams. merge requests: one for `master`, one for the current release and one for each of the two latest releases. More, if there are EE MRs. - *Example:* If the current milestone is 10.8 you should open an MR targeting - 10.8, 10.7 and 10.6 security branches, as well as one targeting `master`. - -1. List the issues and merge requests that need to be included - - For each Merge Request that the Release Manager was assigned to, list the issue and each merge request in the security issue. - It will be helpful when it's time to merge them. - -1. Merge the MRs assigned to the GitLab Release Tools Bot targeting `X-Y-stable[-ee]` branches - - It is the Release Manager responsibility to merge the MRs targeting the last 3 releases. **Do not merge the one targeting master yet** - - If MR has red pipelines, reassign all related MR's to the original author. Inform the point of contact from the security team for the current release - by leaving a comment in the release issue. Edit the issue description to state that the issue is excluded from the release due to failing pipelines. - 1. Create Security Patch Issues in [gitlab-org/release/tasks](https://gitlab.com/gitlab-org/release/tasks) - using the [`prepare:security` task][prepare-security-task-doc]. + using the `release prepare --security` ChatOps command: -1. Link the new issues as related issues to the meta release issue. + ``` + /chatops run release prepare --security + ``` 1. Follow the steps on the template *for each* of the created issues. @@ -209,5 +189,5 @@ The below is able to be accomplished on the next working day [Return to Security Guide](process.md) +[security group]: https://gitlab.com/gitlab-org/security [Security Engineer]: security-engineer.md -[prepare-security-task-doc]: https://gitlab.com/gitlab-org/release-tools/blob/master/doc/rake-tasks.md#preparesecurity