Add latest changes from gitlab-org/gitlab@master

17 files changed, 440 insertions, 102 deletions

diff --git a/app/assets/javascripts/alerts_service_settings/components/alerts_service_form.vue b/app/assets/javascripts/alerts_service_settings/components/alerts_service_form.vue
index 1c7a181e3e6..785598142fe 100644
--- a/app/assets/javascripts/alerts_service_settings/components/alerts_service_form.vue
+++ b/app/assets/javascripts/alerts_service_settings/components/alerts_service_form.vue
@@ -6,7 +6,7 @@ import {
   GlModal,
   GlModalDirective,
 } from '@gitlab/ui';
-import _ from 'underscore';
+import { escape as esc } from 'lodash';
 import ClipboardButton from '~/vue_shared/components/clipboard_button.vue';
 import ToggleButton from '~/vue_shared/components/toggle_button.vue';
 import axios from '~/lib/utils/axios_utils';
@@ -65,7 +65,7 @@ export default {
           'AlertService|%{linkStart}Learn more%{linkEnd} about configuring this endpoint to receive alerts.',
         ),
         {
-          linkStart: `<a href="${_.escape(
+          linkStart: `<a href="${esc(
             this.learnMoreUrl,
           )}" target="_blank" rel="noopener noreferrer">`,
           linkEnd: '</a>',
diff --git a/app/assets/javascripts/create_item_dropdown.js b/app/assets/javascripts/create_item_dropdown.js
index 95b890b04c1..523e5592fd0 100644
--- a/app/assets/javascripts/create_item_dropdown.js
+++ b/app/assets/javascripts/create_item_dropdown.js
@@ -1,4 +1,4 @@
-import _ from 'underscore';
+import { escape as esc } from 'lodash';
 import '~/gl_dropdown';
 
 export default class CreateItemDropdown {
@@ -37,14 +37,14 @@ export default class CreateItemDropdown {
       },
       selectable: true,
       toggleLabel(selected) {
-        return selected && 'id' in selected ? _.escape(selected.title) : this.defaultToggleLabel;
+        return selected && 'id' in selected ? esc(selected.title) : this.defaultToggleLabel;
       },
       fieldName: this.fieldName,
       text(item) {
-        return _.escape(item.text);
+        return esc(item.text);
       },
       id(item) {
-        return _.escape(item.id);
+        return esc(item.id);
       },
       onFilter: this.toggleCreateNewButton.bind(this),
       clicked: options => {
diff --git a/app/assets/stylesheets/components/dashboard_skeleton.scss b/app/assets/stylesheets/components/dashboard_skeleton.scss
index a104d035a9a..2e2c1fefc79 100644
--- a/app/assets/stylesheets/components/dashboard_skeleton.scss
+++ b/app/assets/stylesheets/components/dashboard_skeleton.scss
@@ -4,6 +4,8 @@
 }
 
 .dashboard-card {
+  @include gl-cursor-grab;
+
   &-header {
     &-warning {
       background-color: $orange-100;
diff --git a/changelogs/unreleased/37001.yml b/changelogs/unreleased/37001.yml
new file mode 100644
index 00000000000..7fdddb1edb4
--- /dev/null
+++ b/changelogs/unreleased/37001.yml
@@ -0,0 +1,5 @@
+---
+title: Add grab cursor for operations dashboard cards
+merge_request: 28868
+author:
+type: changed
diff --git a/doc/api/merge_requests.md b/doc/api/merge_requests.md
index 454d4a2b35b..adb5b00085e 100644
--- a/doc/api/merge_requests.md
+++ b/doc/api/merge_requests.md
@@ -904,7 +904,7 @@ The new pipeline can be:
 
 - A detached merge request pipeline.
 - A [pipeline for merged results](../ci/merge_request_pipelines/pipelines_for_merged_results/index.md)
-  if the [project setting is enabled](../ci/merge_request_pipelines/pipelines_for_merged_results/index.md#enabling-pipelines-for-merged-results).
+  if the [project setting is enabled](../ci/merge_request_pipelines/pipelines_for_merged_results/index.md#enable-pipelines-for-merged-results).
 
 ```plaintext
 POST /projects/:id/merge_requests/:merge_request_iid/pipelines
diff --git a/doc/ci/merge_request_pipelines/index.md b/doc/ci/merge_request_pipelines/index.md
index 315d552e5d2..b57340347d2 100644
--- a/doc/ci/merge_request_pipelines/index.md
+++ b/doc/ci/merge_request_pipelines/index.md
@@ -7,9 +7,8 @@ last_update: 2019-07-03
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/15310) in GitLab 11.6.
 
-In a [basic configuration](../pipelines/pipeline_architectures.md), GitLab runs a pipeline each time
-changes are pushed to a branch. The settings in the [`.gitlab-ci.yml`](../yaml/README.md)
-file, including `rules`, `only`, and `except`, determine which jobs are added to a pipeline.
+In a [basic configuration](../pipelines/pipeline_architectures.md#basic-pipelines), GitLab runs a pipeline each time
+changes are pushed to a branch.
 
 If you want the pipeline to run jobs **only** when merge requests are created or updated,
 you can use *pipelines for merge requests*.
@@ -28,7 +27,7 @@ A few notes:
 
 ## Configuring pipelines for merge requests
 
-To configure pipelines for merge requests, configure your CI yaml file.
+To configure pipelines for merge requests, configure your [CI/CD configuration file](../yaml/README.md).
 There are a few different ways to do this.
 
 ### Enable pipelines for merge requests for all jobs
diff --git a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md
index 5a732248ec1..fb5c7830ac2 100644
--- a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md
+++ b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md
@@ -36,31 +36,41 @@ again run against the merged results.
 
 ## Requirements and limitations
 
-Pipelines for merged results require a [GitLab Runner][runner] 11.9 or newer.
-
-[runner]: https://gitlab.com/gitlab-org/gitlab-runner
-
-In addition, pipelines for merged results have the following limitations:
+Pipelines for merged results have the following requirements and limitations:
 
+- Pipelines for merged results require [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner) 11.9 or newer.
 - Forking/cross-repo workflows are not currently supported. To follow progress,
   see [#11934](https://gitlab.com/gitlab-org/gitlab/issues/11934).
 - This feature is not available for
   [fast forward merges](../../../user/project/merge_requests/fast_forward_merge.md) yet.
   To follow progress, see [#58226](https://gitlab.com/gitlab-org/gitlab/-/issues/26996).
 
-## Enabling Pipelines for Merged Results
+## Enable pipelines for merged results
 
-To enable pipelines on merged results at the project level:
+To enable pipelines for merged results for your project:
 
+1. [Configure your CI/CD configuration file](../index.md#configuring-pipelines-for-merge-requests)
+   so that the pipeline or individual jobs run for merge requests.
 1. Visit your project's **Settings > General** and expand **Merge requests**.
 1. Check **Merge pipelines will try to validate the post-merge result prior to merging**.
-1. Click **Save changes** button.
+1. Click **Save changes**.
+
+CAUTION: **Caution:**
+If you select the check box but don't configure your CI/CD to use
+pipelines for merge requests, your merge requests may become stuck in an
+unresolved state or your pipelines may be dropped.
+
+## Using Merge Trains
 
-![Merge request pipeline config](img/merge_request_pipeline_config.png)
+When you enable [Pipelines for merged results](#pipelines-for-merged-results-premium),
+GitLab [automatically displays](merge_trains/index.md#add-a-merge-request-to-a-merge-train)
+a **Start/Add Merge Train button**.
 
-CAUTION: **Warning:**
-Make sure your `gitlab-ci.yml` file is [configured properly for pipelines for merge requests](../index.md#configuring-pipelines-for-merge-requests),
-otherwise pipelines for merged results won't run and your merge requests will be stuck in an unresolved state.
+Generally, this is a safer option than merging merge requests immediately, because your
+merge request will be evaluated with an expected post-merge result before the actual
+merge happens.
+
+For more information, read the [documentation on Merge Trains](merge_trains/index.md).
 
 ## Automatic pipeline cancelation
 
@@ -118,15 +128,3 @@ which indicates that the checkout-SHA is not found in the merge ref.
 
 This behavior was improved at GitLab 12.4 by introducing [Persistent pipeline refs](../../pipelines/index.md#troubleshooting-fatal-reference-is-not-a-tree).
 You should be able to create pipelines at any timings without concerning the error.
-
-## Using Merge Trains **(PREMIUM)**
-
-By enabling [Pipelines for merged results](#pipelines-for-merged-results-premium),
-GitLab will [automatically display](merge_trains/index.md#how-to-add-a-merge-request-to-a-merge-train)
-a **Start/Add Merge Train button** as the most recommended merge strategy.
-
-Generally, this is a safer option than merging merge requests immediately as your
-merge request will be evaluated with an expected post-merge result before the actual
-merge happens.
-
-For more information, read the [documentation on Merge Trains](merge_trains/index.md).
diff --git a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/img/merge_train_immediate_merge_confirmation_dialog_v12_6.png b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/img/merge_train_immediate_merge_confirmation_dialog_v12_6.png
deleted file mode 100644
index 241f837a748..00000000000
--- a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/img/merge_train_immediate_merge_confirmation_dialog_v12_6.png
+++ /dev/null
diff --git a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/img/merge_train_immediate_merge_v12_6.png b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/img/merge_train_immediate_merge_v12_6.png
index b46522395e0..de5897c271b 100644
--- a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/img/merge_train_immediate_merge_v12_6.png
+++ b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/img/merge_train_immediate_merge_v12_6.png
diff --git a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md
index 1859328247b..b6706c2a272 100644
--- a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md
+++ b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md
@@ -19,21 +19,18 @@ Merging now could introduce breaking changes.
 *Merge trains* can prevent this from happening. A merge train is a queued list of merge
 requests, each waiting to be merged into the target branch.
 
-Each merge request on the train runs the merged results pipeline immediately before its
-changes are merged into the target branch. If the pipeline fails, the breaking changes are
-not merged, and the target branch is unaffected.
+Many merge requests can be added to the train. Each merge request runs its own merged results pipeline,
+which includes the changes from all of the other merge requests in *front* of it on the train.
+All the pipelines run in parallel, to save time.
 
-Many merge requests can be added to the train. Each is trying to merge into the target branch.
-Each request runs its own merged results pipeline, which includes the changes from
-all of the other merge requests in *front* of it on the train. All the pipelines run
-in parallel, to save time.
+If the pipeline for a merge request fails, the breaking changes are not merged, and the target
+branch is unaffected. The merge request is removed from the train, and all pipelines behind it restart.
 
 If the pipeline for the merge request at the front of the train completes successfully,
-the changes are merged into the target branch, and the other pipelines will continue to
+the changes are merged into the target branch, and the other pipelines continue to
 run.
 
-If one of the pipelines fails, it is removed from the train, and all pipelines behind
-it restart, but without the changes that were removed.
+## Merge train example
 
 Three merge requests (`A`, `B` and `C`) are added to a merge train in order, which
 creates three merged results pipelines that run in parallel:
@@ -50,85 +47,99 @@ to run. If more merge requests are added to the train, they will now include the
 changes that are included in the target branch, and the `C` changes that are from
 the merge request already in the train.
 
-Learn more about
+Read more about
 [how merge trains keep your master green](https://about.gitlab.com/blog/2020/01/30/all-aboard-merge-trains/).
 
+<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
+Watch this video for a demonstration on [how parallel execution
+of Merge Trains can prevent commits from breaking the default
+branch](https://www.youtube.com/watch?v=D4qCqXgZkHQ).
+
 ## Requirements and limitations
 
 Merge trains have the following requirements and limitations:
 
+- Merge trains require [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner) 11.9 or newer.
 - GitLab 12.0 and later requires [Redis](https://redis.io/) 3.2 or higher.
-- [Pipelines for merged results](../index.md#pipelines-for-merged-results-premium) must be
-  **configured properly**.
 - Each merge train can run a maximum of **twenty** pipelines in parallel.
   If more than twenty merge requests are added to the merge train, the merge requests
   will be queued until a slot in the merge train is free. There is no limit to the
   number of merge requests that can be queued.
 
-<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
-Watch this video for a demonstration on [how parallel execution
-of Merge Trains can prevent commits from breaking the default
-branch](https://www.youtube.com/watch?v=D4qCqXgZkHQ).
+## Enable merge trains
 
-## How to add a merge request to a merge train
+To enable merge trains for your project:
 
-To add a merge request to a merge train:
+1. If you are on a self-managed GitLab instance, ensure the [feature flag](#merge-trains-feature-flag-premium-only) is set correctly.
+1. [Configure your CI/CD configuration file](../../index.md#configuring-pipelines-for-merge-requests)
+   so that the pipeline or individual jobs run for merge requests.
+1. Visit your project's **Settings > General** and expand **Merge requests**.
+1. Check **Merge pipelines will try to validate the post-merge result prior to merging**.
+1. Click **Save changes**.
+
+CAUTION: **Caution:**
+If you select the check box but don't configure your CI/CD to use
+pipelines for merge requests, your merge requests may become stuck in an
+unresolved state or your pipelines may be dropped.
+
+## Start a merge train
+
+To start a merge train:
 
 1. Visit a merge request.
-1. Click the **Start/Add to merge train** button.
+1. Click the **Start merge train** button.
 
 ![Start merge train](img/merge_train_start_v12_0.png)
 
-## How to remove a merge request from a merge train
+Other merge requests can now be added to the train.
+
+## Add a merge request to a merge train
+
+To add a merge request to a merge train:
 
 1. Visit a merge request.
-1. Click the **Remove from merge train** button.
+1. Click the **Add to merge train** button.
 
-![Cancel merge train](img/merge_train_cancel_v12_0.png)
+If pipelines are already running for the merge request, you cannot add the merge request
+to the train. Instead, you can schedule to add the merge request to a merge train **when the latest
+pipeline succeeds**.
 
-## How to view a merge request's current position on the merge train
+![Add to merge train when pipeline succeeds](img/merge_train_start_when_pipeline_succeeds_v12_0.png)
 
-After a merge request has been added to the merge train, the merge request's
-current position will be displayed under the pipeline widget:
+## Remove a merge request from a merge train
 
-![Merge train position indicator](img/merge_train_position_v12_0.png)
+1. Visit a merge request.
+1. Click the **Remove from merge train** button.
 
-## Start/Add to merge train when pipeline succeeds
+![Cancel merge train](img/merge_train_cancel_v12_0.png)
 
-You can add a merge request to a merge train only when the latest pipeline in the
-merge request is finished. While the pipeline is running or pending, you cannot add
-the merge request to a train because the current change of the merge request may
-be broken thus it could affect the following merge requests.
+If you want to add the merge request to a merge train again later, you can.
 
-In this case, you can schedule to add the merge request to a merge train **when the latest
-pipeline succeeds** (This pipeline is [Pipelines for merged results](../index.md), not Pipelines for merge train).
-You can see the following button instead of the regular **Start/Add to merge train**
-button while the latest pipeline is running.
+## View a merge request's current position on the merge train
 
-![Add to merge train when pipeline succeeds](img/merge_train_start_when_pipeline_succeeds_v12_0.png)
+After a merge request has been added to the merge train, the merge request's
+current position is displayed under the pipeline widget:
+
+![Merge train position indicator](img/merge_train_position_v12_0.png)
 
 ## Immediately merge a merge request with a merge train
 
-In the case where you have a high-priority merge request (for example, a critical patch) to be merged urgently,
-you can use **Merge Immediately** option for bypassing the merge train.
+If you have a high-priority merge request (for example, a critical patch) that must
+be merged urgently, you can bypass the merge train by using the **Merge Immediately** option.
 This is the fastest option to get the change merged into the target branch.
 
 ![Merge Immediately](img/merge_train_immediate_merge_v12_6.png)
 
-However, every time you merge a merge request immediately, it could affect the
-existing merge train to be reconstructed, specifically, it regenerates expected
-merge commits and pipelines. This means, merging immediately essentially wastes
-CI resources. Because of these downsides, you will be asked to confirm before
-the merge is initiated:
-
-![Merge immediately confirmation dialog](img/merge_train_immediate_merge_confirmation_dialog_v12_6.png)
+CAUTION: **Caution:**
+Each time you merge a merge request immediately, the current merge train
+is recreated and all pipelines restart.
 
 ## Troubleshooting
 
 ### Merge request dropped from the merge train immediately
 
 If a merge request is not mergeable (for example, it's WIP, there is a merge
-conflict, etc), your merge request will be dropped from the merge train automatically.
+conflict, etc.), your merge request will be dropped from the merge train automatically.
 
 In these cases, the reason for dropping the merge request is in the **system notes**.
 
@@ -146,35 +157,30 @@ To check the reason:
 ### Merge When Pipeline Succeeds cannot be chosen
 
 [Merge When Pipeline Succeeds](../../../../user/project/merge_requests/merge_when_pipeline_succeeds.md)
-is unavailable when
-[Pipelines for Merged Results is enabled](../index.md#enabling-pipelines-for-merged-results).
+is currently unavailable when Merge Trains are enabled.
 
-Follow [this issue](https://gitlab.com/gitlab-org/gitlab/issues/12267) to
-track progress on this issue.
+See [the related issue](https://gitlab.com/gitlab-org/gitlab/issues/12267)
+for more information.
 
 ### Merge Train Pipeline cannot be retried
 
 A Merge Train pipeline cannot be retried because the merge request is dropped from the merge train upon failure. For this reason, the retry button does not appear next to the pipeline icon.
 
-In the case of pipeline failure, you should [re-enqueue](#how-to-add-a-merge-request-to-a-merge-train) the merge request to the merge train, which will then initiate a new pipeline.
-
-### Merge Train disturbs your workflow
+In the case of pipeline failure, you should [re-enqueue](#add-a-merge-request-to-a-merge-train) the merge request to the merge train, which will then initiate a new pipeline.
 
-First of all, please check if [merge immediately](#immediately-merge-a-merge-request-with-a-merge-train)
-is available as a workaround in your workflow. This is the most recommended
-workaround you'd be able to take immediately. If it's not available or acceptable,
-please read through this section.
+### Merge Trains feature flag **(PREMIUM ONLY)**
 
-Merge train is enabled by default when you enable [Pipelines for merged results](../index.md),
-however, you can disable this feature by setting the `:disable_merge_trains` feature flag to `enable`.
-When you disable this feature, all existing merge trains are aborted and
-the **Start/Add Merge Train** button no longer appears in merge requests.
+To enable and disable the Merge Trains feature, use the `:disable_merge_trains` feature flag.
 
 To check if the feature flag is enabled on your GitLab instance,
-please ask an administrator to execute the following commands **(CORE ONLY)**:
+ask an administrator to execute the following commands:
 
 ```shell
 > sudo gitlab-rails console                         # Login to Rails console of GitLab instance.
 > Feature.enabled?(:disable_merge_trains)           # Check if it's disabled or not.
 > Feature.enable(:disable_merge_trains)             # Disable Merge Trains.
+> Feature.disable(:disable_merge_trains)            # Enable Merge Trains.
 ```
+
+When you disable this feature, all existing merge trains are cancelled and
+the **Start/Add to Merge Train** button no longer appears in merge requests.
diff --git a/doc/development/README.md b/doc/development/README.md
index 0620c96ba21..b505fa38618 100644
--- a/doc/development/README.md
+++ b/doc/development/README.md
@@ -34,7 +34,7 @@ description: 'Learn how to contribute to GitLab.'
 
 - [Code review guidelines](code_review.md) for reviewing code and having code reviewed
 - [Database review guidelines](database_review.md) for reviewing database-related changes and complex SQL queries, and having them reviewed
-- [Secure coding guidelines](https://gitlab.com/gitlab-com/gl-security/security-guidelines)
+- [Secure coding guidelines](secure_coding_guidelines.md)
 - [Pipelines for the GitLab project](pipelines.md)
 
 Complementary reads:
diff --git a/doc/development/api_graphql_styleguide.md b/doc/development/api_graphql_styleguide.md
index ea58b71a804..036eddd7c37 100644
--- a/doc/development/api_graphql_styleguide.md
+++ b/doc/development/api_graphql_styleguide.md
@@ -211,6 +211,15 @@ To ensure that we get consistent ordering, we will append an ordering on the pri
 key, in descending order. This is usually `id`, so basically we will add `order(id: :desc)`
 to the end of the relation. A primary key _must_ be available on the underlying table.
 
+#### Shortcut fields
+
+Sometimes it can seem easy to implement a "shortcut field", having the resolver return the first of a collection if no parameters are passed.
+These "shortcut fields" are discouraged because they create maintenance overhead.
+They need to be kept in sync with their canonical field, and deprecated or modified if their canonical field changes.
+Use the functionality the framework provides unless there is a compelling reason to do otherwise.
+
+For example, instead of `latest_pipeline`, use `pipelines(last: 1)`.
+
 ### Exposing permissions for a type
 
 To expose permissions the current user has on a resource, you can call
diff --git a/doc/development/secure_coding_guidelines.md b/doc/development/secure_coding_guidelines.md
new file mode 100644
index 00000000000..0367db8939a
--- /dev/null
+++ b/doc/development/secure_coding_guidelines.md
@@ -0,0 +1,306 @@
+# Security Guidelines
+
+This document contains descriptions and guidelines for addressing security
+vulnerabilities commonly identified in the GitLab codebase. They are intended
+to help developers identify potential security vulnerabilities early, with the
+goal of reducing the number of vulnerabilities released over time.
+
+**Contributing**
+
+If you would like to contribute to one of the existing documents, or add
+guidelines for a new vulnerability type, please open an MR! Please try to
+include links to examples of the vulnerability found, and link to any resources
+used in defined mitigations. If you have questions or when ready for a review,
+please ping `gitlab-com/gl-security/appsec`.
+
+## Permissions
+
+### Description
+
+Application permissions are used to determine who can access what and what actions they can perform.
+For more information about the permission model at GitLab, please see [the GitLab permissions guide](permissions.md) or the [EE docs on permissions](../../ee/user/permissions.md).
+
+### Impact
+
+Improper permission handling can have significant impacts on the security of an application.
+Some situations may reveal [sensitive data](https://gitlab.com/gitlab-com/gl-infra/production/issues/477) or allow a malicious actor to perform [harmful actions](https://gitlab.com/gitlab-org/gitlab/issues/8180).
+The overall impact depends heavily on what resources can be accessed or modified improperly.
+
+A common vulnerability when permission checks are missing is called [IDOR](https://www.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_(OTG-AUTHZ-004)) for Insecure Direct Object References.
+
+### When to Consider
+
+Each time you implement a new feature/endpoint, whether it is at UI, API or GraphQL level.
+
+### Mitigations
+
+**Start by writing tests** around permissions: unit and feature specs should both include tests based around permissions
+
+- Fine-grained, nitty-gritty specs for permissions are good: it is ok to be verbose here
+  - Make assertions based on the actors and objects involved: can a user or group or XYZ perform this action on this object?
+  - Consider defining them upfront with stakeholders, particularly for the edge cases
+- Do not forget **abuse cases**: write specs that **make sure certain things can't happen**
+  - A lot of specs are making sure things do happen and coverage percentage doesn't take into account permissions as same piece of code is used.
+  - Make assertions that certain actors cannot perform actions
+- Naming convention to ease auditability: to be defined, e.g. a subfolder containing those specific permission tests or a `#permissions` block
+
+Be careful to **also test [visibility levels](https://gitlab.com/gitlab-org/gitlab-foss/-/blob/master/doc/development/permissions.md#feature-specific-permissions)** and not only project access rights.
+
+Some example of well implemented access controls and tests:
+
+1. [example1](https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/710/diffs?diff_id=13750#af40ef0eaae3c1e018809e1d88086e32bccaca40_43_43)
+1. [example2](https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2511/diffs#ed3aaab1510f43b032ce345909a887e5b167e196_142_155)
+1. [example3](https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3170/diffs?diff_id=17494)
+
+**NB:** any input from development team is welcome, e.g. about rubocop rules.
+
+## Regular Expressions guidelines
+
+### Anchors / Multi line
+
+Unlike other programming languages (e.g. Perl or Python) Regular Expressions are matching multi-line by default in Ruby. Consider the following example in Python:
+
+```python
+import re
+text = "foo\nbar"
+matches = re.findall("^bar$",text)
+print(matches)
+```
+
+The Python example will output an emtpy array (`[]`) as the matcher considers the whole string `foo\nbar` including the newline (`\n`). In contrast Ruby's Regular Expression engine acts differently:
+
+```ruby
+text = "foo\nbar"
+p text.match /^bar$/
+```
+
+The output of this example is `#<MatchData "bar">`, as Ruby treats the input `text` line by line. In order to match the whole __string__ the Regex anchors `\A` and `\z` should be used according to [Rubular](https://rubular.com/).
+
+#### Impact
+
+This Ruby Regex speciality can have security impact, as often regular expressions are used for validations or to impose restrictions on user-input.
+
+#### Examples
+
+GitLab specific examples can be found [here](https://gitlab.com/gitlab-org/gitlab/issues/36029#note_251262187) and [there](https://gitlab.com/gitlab-org/gitlab/issues/33569).
+
+Another example would be this fictional Ruby On Rails controller:
+
+```ruby
+class PingController < ApplicationController
+  def ping
+    if params[:ip] =~ /^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}$/
+      render :text => `ping -c 4 #{params[:ip]}`
+    else
+      render :text => "Invalid IP"
+    end
+  end
+end
+```
+
+Here `params[:ip]` should not contain anything else but numbers and dots. However this restriction can be easily bypassed as the Regex anchors `^` and `$` are being used. Ultimately this leads to a shell command injection in `ping -c 4 #{params[:ip]}` by using newlines in `params[:ip]`.
+
+#### Mitigation
+
+In most cases the anchors `\A` for beginning of text and `\z` for end of text should be used instead of `^` and `$`.
+
+### Further Links
+
+- [Rubular](https://rubular.com/) is a nice online tool to fiddle with Ruby Regexps.
+
+## Server Side Request Forgery (SSRF)
+
+### Description
+
+A [Server-side Request Forgery (SSRF)][1] is an attack in which an attacker
+is able coerce a application into making an outbound request to an unintended
+resource. This resource is usually internal. In GitLab, the connection most
+commonly uses HTTP, but an SSRF can be performed with any protocol, such as
+Redis or SSH.
+
+With an SSRF attack, the UI may or may not show the response. The latter is
+called a Blind SSRF. While the impact is reduced, it can still be useful for
+attackers, especially for mapping internal network services as part of recon.
+
+[1]: https://www.hackerone.com/blog-How-To-Server-Side-Request-Forgery-SSRF
+
+### Impact
+
+The impact of an SSRF can vary, depending on what the application server
+can communicate with, how much the attacker can control of the payload, and
+if the response is returned back to the attacker. Examples of impact that
+have been reported to GitLab include:
+
+- Network mapping of internal services
+  - This can help an attacker gather information about internal services
+  that could be used in further attacks. [More details](https://gitlab.com/gitlab-org/gitlab-foss/issues/51327).
+- Reading internal services, including cloud service metadata.
+  - The latter can be a serious problem, because an attacker can obtain keys that allow control of the victim's cloud infrastructure. (This is also a good reason
+  to give only necessary privileges to the token.). [More details](https://gitlab.com/gitlab-org/gitlab-foss/issues/51490).
+- When combined with CRLF vulnerability, remote code execution. [More details](https://gitlab.com/gitlab-org/gitlab-foss/issues/41293)
+
+### When to Consider
+
+- When the application makes any outbound connection
+
+### Mitigations
+
+In order to mitigate SSRF vulnerabilities, it is necessary to validate the destination of the outgoing request, especially if it includes user-supplied information.
+
+The preferred SSRF mitigations within GitLab are:
+
+1. Only connect to known, trusted domains/IP addresses.
+1. Use the [GitLab::HTTP](#gitlab-http-library) library
+1. Implement [feature-specific mitigations](#feature-specific-mitigations)
+
+#### GitLab HTTP Library
+
+The [GitLab::HTTP][2] wrapper library has grown to include mitigations for all of the GitLab-known SSRF vectors. It is also configured to respect the
+`Outbound requests` options that allow instance administrators to block all internal connections, or limit the networks to which connections can be made.
+
+In some cases, it has been possible to configure GitLab::HTTP as the HTTP
+connection library for 3rd-party gems. This is preferrable over re-implementing
+the mitigations for a new feature.
+
+- [More details](https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2530/diffs)
+
+[2]: https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/http.rb
+
+#### Feature-specific Mitigations
+
+For situtions in which a whitelist or GitLab:HTTP cannot be used, it will be necessary to implement mitigations directly in the feature. It is best to validate the destination IP addresses themselves, not just domain names, as DNS can be controlled by the attacker. Below are a list of mitigations that should be implemented.
+
+**Important Note:** There are many tricks to bypass common SSRF validations. If feature-specific mitigations are necessary, they should be reviewed by the AppSec team, or a developer who has worked on SSRF mitigations previously.
+
+- Block connections to all localhost addresses
+  - `127.0.0.1/8` (IPv4 - note the subnet mask)
+  - `::1` (IPv6)
+- Block connections to networks with private addressing (RFC 1918)
+  - `10.0.0.0/8`
+  - `172.16.0.0/12`
+  - `192.168.0.0/24`
+- Block connections to link-local addresses (RFC 3927)
+  - `169.254.0.0/16`
+  - In particular, for GCP: `metadata.google.internal` -> `169.254.169.254`
+- For HTTP connections: Disable redirects or validate the redirect destination
+- To mitigate DNS rebinding attacks, validate and use the first IP address received
+
+See [url_blocker_spec.rb][3] for examples of SSRF payloads
+
+[3]: https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/lib/gitlab/url_blocker_spec.rb
+
+## XSS guidelines
+
+### Description
+
+Cross site scripting (XSS) is an issue where malicious JavaScript code gets injected into a trusted web application and executed in a client's browser. The input is intended to be data, but instead gets treated as code by the browser.
+
+XSS issues are commonly classified in three categories, by their delivery method:
+
+- [Persistent XSS](https://owasp.org/www-community/Types_of_Cross-Site_Scripting#stored-xss-aka-persistent-or-type-i)
+- [Reflected XSS](https://owasp.org/www-community/Types_of_Cross-Site_Scripting#reflected-xss-aka-non-persistent-or-type-ii)
+- [DOM XSS](https://owasp.org/www-community/Types_of_Cross-Site_Scripting#dom-based-xss-aka-type-0)
+
+### Impact
+
+The injected client-side code is executed on the victim's browser in the context of their current session. This means the attacker could perform any same action the victim would normally be able to do through a browser. The attacker would also have the ability to:
+
+- [log victim keystrokes](https://youtu.be/2VFavqfDS6w?t=1367)
+- launch a network scan from the victim's browser
+- potentially [obtain the victim's session tokens](https://youtu.be/2VFavqfDS6w?t=739)
+- perform actions that lead to data loss/theft or account takeover
+
+Much of the impact is contingent upon the function of the application and the capabilities of the victim's session. For further impact possibilities, please check out [the beef project](https://beefproject.com/).
+
+### When to consider?
+
+When user submitted data is included in responses to end users, which is just about anywhere.
+
+### Mitigation
+
+In most situations, a two-step solution can be utilized: input validation and output encoding in the appropriate context.
+
+#### Input validation
+
+- [Input Validation](https://youtu.be/2VFavqfDS6w?t=7489)
+
+##### Setting expectations
+
+For any and all input fields, ensure to define expectations on the type/format of input, the contents, [size limits](https://youtu.be/2VFavqfDS6w?t=7582), the context in which it will be output. It's important to work with both security and product teams to determine what is considered acceptable input.
+
+##### Validate input
+
+- Treat all user input as untrusted.
+- Based on the expectations you [defined above](#setting-expectations):
+  - Validate the [input size limits](https://youtu.be/2VFavqfDS6w?t=7582).
+  - Validate the input using a [whitelist approach](https://youtu.be/2VFavqfDS6w?t=7816) to only allow characters through which you are expecting to receive for the field.
+    - Input which fails validation should be **rejected**, and not sanitized.
+
+Note that blacklists should be avoided, as it is near impossible to block all [variations of XSS](https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet).
+
+#### Output encoding
+
+Once you've [determined when and where](#setting-expectations) the user submitted data will be output, it's important to encode it based on the appropriate context. For example:
+
+- Content placed inside HTML elements need to be [HTML entity encoded](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html#rule-1---html-escape-before-inserting-untrusted-data-into-html-element-content).
+- Content placed into a JSON response needs to be [JSON encoded](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html#rule-31---html-escape-json-values-in-an-html-context-and-read-the-data-with-jsonparse).
+- Content placed inside [HTML URL GET parameters](https://youtu.be/2VFavqfDS6w?t=3494) need to be [URL-encoded](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html#rule-5---url-escape-before-inserting-untrusted-data-into-html-url-parameter-values)
+- [Additional contexts may require context-specific encoding](https://youtu.be/2VFavqfDS6w?t=2341).
+
+### Additional info
+
+#### Mitigating XSS in Rails
+
+- [XSS Defense in Rails](https://youtu.be/2VFavqfDS6w?t=2442)
+- [XSS Defense with HAML](https://youtu.be/2VFavqfDS6w?t=2796)
+- [Validating Untrusted URLs in Ruby](https://youtu.be/2VFavqfDS6w?t=3936)
+- [RoR Model Validators](https://youtu.be/2VFavqfDS6w?t=7636)
+
+#### GitLab specific libraries for mitigating XSS
+
+##### Vue
+
+- [isSafeURL](https://gitlab.com/gitlab-org/gitlab/-/blob/v12.7.5-ee/app/assets/javascripts/lib/utils/url_utility.js#L190-207)
+
+#### Content Security Policy
+
+- [Content Security Policy](https://www.youtube.com/watch?v=2VFavqfDS6w&t=12991s)
+- [Use nonce-based Content Security Policy for inline JavaScript](https://gitlab.com/gitlab-org/gitlab-foss/issues/65330)
+
+#### Free form input fields
+
+##### Sanitization
+
+- [HTML Sanitization](https://youtu.be/2VFavqfDS6w?t=5075)
+- [DOMPurify](https://youtu.be/2VFavqfDS6w?t=5381)
+
+##### `iframe` sandboxes
+
+- [iframe sandboxing](https://youtu.be/2VFavqfDS6w?t=7043)
+
+### Select examples of past XSS issues affecting GitLab
+
+- [Stored XSS in user status](https://gitlab.com/gitlab-org/gitlab-foss/issues/55320)
+
+### Developer Training
+
+- [Introduction to XSS](https://www.youtube.com/watch?v=PXR8PTojHmc&t=7785s)
+- [Reflected XSS](https://youtu.be/2VFavqfDS6w?t=603s)
+- [Persistent XSS](https://youtu.be/2VFavqfDS6w?t=643)
+- [DOM XSS](https://youtu.be/2VFavqfDS6w?t=5871)
+- [XSS in depth](https://www.youtube.com/watch?v=2VFavqfDS6w&t=111s)
+- [XSS Defense](https://youtu.be/2VFavqfDS6w?t=1685)
+- [XSS Defense in Rails](https://youtu.be/2VFavqfDS6w?t=2442)
+- [XSS Defense with HAML](https://youtu.be/2VFavqfDS6w?t=2796)
+- [JavaScript URLs](https://youtu.be/2VFavqfDS6w?t=3274)
+- [URL encoding context](https://youtu.be/2VFavqfDS6w?t=3494)
+- [Validating Untrusted URLs in Ruby](https://youtu.be/2VFavqfDS6w?t=3936)
+- [HTML Sanitization](https://youtu.be/2VFavqfDS6w?t=5075)
+- [DOMPurify](https://youtu.be/2VFavqfDS6w?t=5381)
+- [Safe Client-side JSON Handling](https://youtu.be/2VFavqfDS6w?t=6334)
+- [iframe sandboxing](https://youtu.be/2VFavqfDS6w?t=7043)
+- [Input Validation](https://youtu.be/2VFavqfDS6w?t=7489)
+- [Validate size limits](https://youtu.be/2VFavqfDS6w?t=7582)
+- [RoR model validators](https://youtu.be/2VFavqfDS6w?t=7636)
+- [Whitelist input validation](https://youtu.be/2VFavqfDS6w?t=7816)
+- [Content Security Policy](https://www.youtube.com/watch?v=2VFavqfDS6w&t=12991s)
diff --git a/doc/development/testing_guide/end_to_end/feature_flags.md b/doc/development/testing_guide/end_to_end/feature_flags.md
index bf1e70be9cb..3bd07f17207 100644
--- a/doc/development/testing_guide/end_to_end/feature_flags.md
+++ b/doc/development/testing_guide/end_to_end/feature_flags.md
@@ -1,11 +1,13 @@
 # Testing with feature flags
 
-To run a specific test with a feature flag enabled you can use the `QA::Runtime::Feature` class to enabled and disable feature flags ([via the API](../../../api/features.md)).
+To run a specific test with a feature flag enabled you can use the `QA::Runtime::Feature` class to enable and disable feature flags ([via the API](../../../api/features.md)).
 
 Note that administrator authorization is required to change feature flags. `QA::Runtime::Feature` will automatically authenticate as an administrator as long as you provide an appropriate access token via `GITLAB_QA_ADMIN_ACCESS_TOKEN` (recommended), or provide `GITLAB_ADMIN_USERNAME` and `GITLAB_ADMIN_PASSWORD`.
 
+Please be sure to include the tag `:requires_admin` so that the test can be skipped in environments where admin access is not available.
+
 ```ruby
-context "with feature flag enabled" do
+context "with feature flag enabled", :requires_admin do
   before do
     Runtime::Feature.enable('feature_flag_name')
   end
diff --git a/doc/topics/autodevops/stages.md b/doc/topics/autodevops/stages.md
index 265a117ced1..72fa3870abd 100644
--- a/doc/topics/autodevops/stages.md
+++ b/doc/topics/autodevops/stages.md
@@ -533,6 +533,11 @@ The metrics include:
 - **Response Metrics:** latency, throughput, error rate
 - **System Metrics:** CPU utilization, memory utilization
 
+GitLab provides some initial alerts for you after you install Prometheus:
+
+- Ingress status code `500` > 0.1%
+- NGINX status code `500` > 0.1%
+
 To make use of Auto Monitoring:
 
 1. [Install and configure the requirements](index.md#requirements).
diff --git a/doc/university/README.md b/doc/university/README.md
index 5c51dcc87a2..84e3b84139b 100644
--- a/doc/university/README.md
+++ b/doc/university/README.md
@@ -7,7 +7,7 @@ type: index
 
 GitLab University is a great place to start when learning about version control with Git and GitLab, as well as other GitLab features.
 
-If you're looking for a GitLab subscription for _your university_, see our [Education](https://about.gitlab.com/solutions/education/) page.
+If you're looking for a GitLab subscription for _your university_, see our [GitLab for Education](https://about.gitlab.com/solutions/education/) page.
 
 CAUTION: **Caution:**
 Some of the content in GitLab University may be out of date and we plan to
diff --git a/locale/gitlab.pot b/locale/gitlab.pot
index 14fc1487b5e..ab06c98a297 100644
--- a/locale/gitlab.pot
+++ b/locale/gitlab.pot
@@ -17184,6 +17184,12 @@ msgstr ""
 msgid "Requirements"
 msgstr ""
 
+msgid "Requirements allow you to create criteria to check your products against."
+msgstr ""
+
+msgid "Requirements can be based on users, stakeholders, system, software or anything else you find important to capture."
+msgstr ""
+
 msgid "Requires approval from %{names}."
 msgid_plural "Requires %{count} more approvals from %{names}."
 msgstr[0] ""