Add latest changes from gitlab-org/gitlab@master

19 files changed, 432 insertions, 33 deletions

diff --git a/data/whats_new/202106220001_14_0.yml b/data/whats_new/202106220001_14_0.yml
new file mode 100644
index 00000000000..fb3775239d4
--- /dev/null
+++ b/data/whats_new/202106220001_14_0.yml
@@ -0,0 +1,161 @@
+- title: Streamlined top navigation menu
+  body: |
+   GitLab 14.0 introduces an all-new, streamlined top navigation menu to help you get where you're going faster and with fewer clicks. This new, consolidated menu offers the combined functionality of the previous Projects, Groups, and More menus. It gives you access to your projects, groups, and instance-level features with a single click. Additionally, all-new responsive views improve the navigation experience on smaller screens.
+  stage: Create
+  self-managed: true
+  gitlab-com: true
+  packages: [Free, Premium, Ultimate]
+  url: https://gitlab.com/gitlab-org/gitlab/-/issues/332635
+  image_url: https://about.gitlab.com/images/14_0/consolidated-top-nav.png
+  published_at: 2021-06-22
+  release: 14.0
+- title: Sidebar navigation redesign
+  body: |
+   GitLab is big. And it's getting bigger. As we've introduced new features and categories, navigating the densely-packed left sidebar has become less intuitive.
+
+   In GitLab 14.0 we've redesigned and restructured the left sidebar for improved usability, consistency, and discoverability. We've moved some links to features around, split up features in the **Operations** menu into three distinct menus, improved visual contrast, and optimized spacing so all the menu items can fit comfortably on a smaller screen. These changes are intended to better match your mental model of the DevOps lifecycle, and provide a more predictable and consistent experience while navigating within your projects and groups.
+  stage: Create
+  self-managed: true
+  gitlab-com: true
+  packages: [Free, Premium, Ultimate]
+  url: https://gitlab.com/gitlab-org/gitlab/-/issues/332635
+  image_url: https://about.gitlab.com/images/14_0/redesigned-left-sidebar.png
+  published_at: 2021-06-22
+  release: 14.0
+- title: Merge request reviews in VS Code
+  body: |
+    As a developer, you often spend a majority of your time working in your local development environment. When you're assigned a merge request for review, this requires you to leave your editor and perform that review inside of GitLab. While performing your review inside GitLab, you might also need to use your local editor to gain more context on the proposed changes.
+
+    [GitLab Workflow](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) version `3.21.0` for Visual Studio Code (VS Code) now supports the complete merge request review process, including threads. Select the GitLab icon in VS Code to open the [sidebar](https://gitlab.com/gitlab-org/gitlab-vscode-extension#sidebar-details) to display **Merge requests I'm reviewing**. Select a merge request overview to view the complete details and discussions of the merge request.
+
+    The sidebar also contains a list of all the changed files in the merge request. Selecting files opens a diff comparison for you to review the changes in VS Code. While viewing the diff, you can read feedback left on the files, and create new comments by selecting a line number and creating your comment. All comments and feedback you provide in VS Code are available in the GitLab web interface, making it easy for you to perform your reviews in VS Code, and other users to participate in GitLab.
+
+    We're really excited about bringing the complete merge request review process to you inside of VS Code. Let us know what you think by [opening an issue](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/new?issue%5Bmilestone_id%5D=) for GitLab Workflow.
+  stage: Create
+  self-managed: true
+  gitlab-com: true
+  packages: [Free, Premium, Ultimate]
+  url: https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/README.md
+  image_url: https://img.youtube.com/vi/F5ypjlOZ4-0/hqdefault.jpg
+  published_at: 2021-06-22
+  release: 14.0
+- title: Track usage of Code Owners
+  body: |
+    Code Owners are an important piece of the code review process in GitLab. When code owners are clearly identified, contributors can see who should review contributions to a file or repository. The Code Owners feature can also be used to establish a merge request approval process. Now, you can track which teams across your organization are using the Code Owners feature in their development workflow.
+
+    If you would like to drive adoption of Code Owners, sort the DevOps Adoption table by the Code Owners column to find teams that haven't yet adopted the feature so you can easily identify which teams need help getting started. Alternatively, find teams that have successfully configured Code Owners and get tips and feedback. The DevOps Adoption table is available at [the group level](https://docs.gitlab.com/ee/user/group/devops_adoption/) and [the instance level](https://docs.gitlab.com/ee/user/admin_area/analytics/dev_ops_report.html#devops-adoption).
+  stage: Manage
+  self-managed: true
+  gitlab-com: true
+  packages: [Ultimate]
+  url: https://docs.gitlab.com/ee/user/admin_area/analytics/dev_ops_report#devops-adoption
+  image_url: https://about.gitlab.com/images/14_0/codeownersadoption.png
+  published_at: 2021-06-22
+  release: 14.0
+- title: Set pronouns on GitLab user profiles
+  body: |
+    Pronouns have been added to GitLab user profiles. The pronouns appear next to user names in the **Profile** tab. You can:
+
+    - Decide whether or not to add pronouns to your profile.
+    - Self-identify and enter whatever pronouns you prefer, without selecting from a predefined list.
+
+    Besides being more inclusive, GitLab wants help people use the correct pronouns when replying to comments to respect people's identity.
+  stage: Manage
+  self-managed: true
+  gitlab-com: true
+  packages: [Free, Premium, Ultimate]
+  url: https://docs.gitlab.com/ee/user/profile/#add-your-gender-pronouns
+  image_url: https://about.gitlab.com/images/14_0/pronouns.png
+  published_at: 2021-06-22
+  release: 14.0
+- title: Container Scanning Integration with Trivy
+  body: |
+    Container scanning in GitLab now uses the Trivy engine by default. This change provides customers with more timely vulnerability intelligence updates, more accurate results, and support for a larger number of operating systems. Users who run container scanning with default settings are switched seamlessly and automatically to the new engine in GitLab 14.0. Users who customize the variables in their container scanning job should review our [migration guide](https://docs.gitlab.com/ee/user/application_security/container_scanning/#change-scanners) and make any necessary updates.
+  stage: Protect
+  self-managed: true
+  gitlab-com: true
+  packages: [Ultimate]
+  url: https://docs.gitlab.com/ee/user/application_security/container_scanning
+  image_url: https://about.gitlab.com/images/14_0/trivy_scanning_engine.png
+  published_at: 2021-06-22
+  release: 14.0
+- title: Aggregate identical DAST vulnerabilities into a single vulnerability
+  body: |
+    In GitLab 13.12 and earlier, all DAST vulnerabilities found in a scan were listed individually for each URL the vulnerability was found on. This could create many vulnerabilities when the fix was a single file or configuration change. For example: an issue with a server header sent with every HTTP response would be reported on every page on the site, rather than reported as a single issue with multiple occurrences.
+
+    To reduce the overhead of managing vulnerabilities, GitLab combines identical vulnerabilities found on multiple pages into a single reported vulnerability in the DAST report. The vulnerability details include a list of all the URLs where the vulnerability was found, rather than individual vulnerabilities being created in the vulnerability list and dashboard for each page.
+
+    This new reporting functionality will not retroactively combine vulnerabilities found in previous scans. It only applies to scans performed in GitLab 14.0 and later.
+  stage: Secure
+  self-managed: true
+  gitlab-com: true
+  packages: [Ultimate]
+  url: https://docs.gitlab.com/ee/user/application_security/dast/#reports
+  image_url: https://about.gitlab.com/images/14_0/dast_aggregated_urls.png
+  published_at: 2021-06-22
+  release: 14.0
+- title: Epic Boards
+  body: |
+    Epic Boards align teams and organizations by communicating the status of epics continuously. Previous versions of GitLab required you to view and sort epics in a list to view the overall status. Keeping epics up to date meant making most changes through an epic's detail page. Epic Boards enable you to visualize and refine all of your epics in one place, using a customizable, drag-and-drop interface that is easy for any teammate to understand and collaborate.
+
+    Epic Boards are also a game-changer for managing and visualizing ideal epic workflows, such as authoring workflow states (Draft, Writing, Done), DevOps workflow states (such as Planned, In Development, and In Production), or any other mutually exclusive states you might model with scoped labels. Visualizing workflows with an Epic Board empowers you to increase predictability and efficiency.
+  stage: Plan
+  self-managed: true
+  gitlab-com: true
+  packages: [Premium, Ultimate]
+  url: https://docs.gitlab.com/ee/user/group/epics/epic_boards.html
+  image_url: https://about.gitlab.com/images/14_0/epic-boards.png
+  published_at: 2021-06-22
+  release: 14.0
+- title: Edit wiki pages with the WYSIWYG Markdown editor
+  body: |
+    Editing wiki content could be so much easier! Many GitLab wikis use Markdown formatting, and for some users, Markdown is a barrier to efficient collaboration. In this release, you now have access to a rich, modern Markdown editing experience in your wiki, so you can edit with confidence.
+
+    Instant feedback and visual editing tools help make wiki editing more intuitive, and remove barriers to collaboration. GitLab saves the changes as Markdown when you're done, so users who want to edit the Markdown directly can do so. You can even type Markdown into the new editor and it will automatically format the text as you type.
+
+    GitLab 14.0 introduces the [Content Editor](https://gitlab.com/groups/gitlab-org/-/epics/5401) into the Wiki with support for most of the basic Markdown content types like headers, bold and italic text, lists, code blocks, and links. [Full support](https://gitlab.com/groups/gitlab-org/-/epics/5438) for the entire [GitLab Flavored Markdown specification](https://docs.gitlab.com/ee/user/markdown.html) will arrive in upcoming releases. We also plan to make the Content Editor available in other areas of GitLab in the future. We welcome input on this early MVC in [this feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/332629).
+  stage: Create
+  self-managed: true
+  gitlab-com: true
+  packages: [Free, Premium, Ultimate]
+  url: https://docs.gitlab.com/ee/user/project/wiki/#content-editor
+  image_url: https://about.gitlab.com/images/14_0/wiki-content-editor-demo.gif
+  published_at: 2021-06-22
+  release: 14.0
+- title: Change an issue's type
+  body: |
+    In some cases, you may wish to change an issue's type. For example, you may want to escalate an issue to an [incident](https://docs.gitlab.com/ee/operations/incident_management/index.html) to ensure that your team handles the problem properly. To change an issue's type, edit the issue and select an issue type from the **Issue type** selector menu.
+  stage: Monitor
+  self-managed: true
+  gitlab-com: true
+  packages: [Free, Premium, Ultimate]
+  url: https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#change-the-issue-type
+  image_url: https://about.gitlab.com/images/14_0/change_type_on_issues.png
+  published_at: 2021-06-22
+  release: 14.0
+- title: Prepopulate the CI/CD pipeline editor with an initial template
+  body: |
+    The pipeline editor in GitLab is your one-stop shop when interacting with CI/CD pipelines. Previously, when writing your first pipeline with the editor, you were presented with a blank configuration. While perfectly useful for experienced pipeline authors, it was a bit of a leap for those just starting out.
+
+    In this release, if a project does not have a pipeline configured, the editor preloads a template showing an example 3-stage pipeline. You can save and run this pipeline right away to see it in action in your project. On top of that, it also has comments that help you understand the syntax, and tips and hints to help you start customizing the template to match your needs. It is now much easier to get your first green pipeline!
+  stage: Verify
+  self-managed: true
+  gitlab-com: true
+  packages: [Free, Premium, Ultimate]
+  url: https://docs.gitlab.com/ee/ci/pipeline_editor/
+  image_url: https://about.gitlab.com/images/14_0/template.png
+  published_at: 2021-06-22
+  release: 14.0
+- title: Terraform module registry built into GitLab
+  body: |
+    Terraform modules play a central role in building standard infrastructure components throughout an organization. Up to GitLab 13.12, GitLab users had to use either a third-party Terraform module registry, local modules, or Git-based modules. While these options work well, they do not help with the distribution of the modules and they lack proper versioning support, which introduces risks for module users. GitLab 14.0 extends our [Infrastructure-as-Code offerings](https://docs.gitlab.com/ee/user/infrastructure/) with a Terraform module registry. Now, you can use the Terraform module registry built into GitLab to discover Terraform modules with semantic versioning support for upgrades and maintenance. Moreover, you can publish modules easily using GitLab CI/CD.
+    
+    While following Terraform's best practices, we recommend developing each Terraform module in a dedicated GitLab project. To simplify the transition to the registry, users can host and publish multiple modules from a single GitLab repository. You can learn more about publishing and consuming a new module [in our documentation](https://docs.gitlab.com/ee/user/packages/terraform_module_registry/index.html).
+  stage: Configure
+  self-managed: true
+  gitlab-com: true
+  packages: [Free, Premium, Ultimate]
+  url: https://docs.gitlab.com/ee/user/packages/terraform_module_registry/index.html
+  image_url: https://about.gitlab.com/images/14_0/terraform-module-registry.png
+  published_at: 2021-06-22
+  release: 14.0
diff --git a/doc/development/profiling.md b/doc/development/profiling.md
index 781138a6ade..a58e1d60cc5 100644
--- a/doc/development/profiling.md
+++ b/doc/development/profiling.md
@@ -135,7 +135,7 @@ starting GitLab. For example:
 ENABLE_BULLET=true bundle exec rails s
 ```
 
-Bullet logs query problems to both the Rails log as well as the Chrome
+Bullet logs query problems to both the Rails log as well as the browser
 console.
 
 As a follow up to finding `N+1` queries with Bullet, consider writing a [QueryRecoder test](query_recorder.md) to prevent a regression.
diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md
index c44e26927fe..e153fa9f334 100644
--- a/doc/development/testing_guide/best_practices.md
+++ b/doc/development/testing_guide/best_practices.md
@@ -513,14 +513,14 @@ Finished in 34.51 seconds (files took 0.76702 seconds to load)
 
 #### Run `:js` spec in a visible browser
 
-Run the spec with `CHROME_HEADLESS=0`, like this:
+Run the spec with `WEBDRIVER_HEADLESS=0`, like this:
 
 ```shell
-CHROME_HEADLESS=0 bin/rspec some_spec.rb
+WEBDRIVER_HEADLESS=0 bin/rspec some_spec.rb
 ```
 
 The test completes quickly, but this gives you an idea of what's happening.
-Using `live_debug` with `CHROME_HEADLESS=0` pauses the open browser, and does not
+Using `live_debug` with `WEBDRIVER_HEADLESS=0` pauses the open browser, and does not
 open the page again. This can be used to debug and inspect elements.
 
 You can also add `byebug` or `binding.pry` to pause execution and [step through](../pry_debugging.md#stepping)
diff --git a/doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md b/doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md
index 859b8f950e3..f200d6c682a 100644
--- a/doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md
+++ b/doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md
@@ -27,7 +27,7 @@ docker run \
 To run the tests from the `/qa` directory:
 
 ```shell
-CHROME_HEADLESS=false bin/qa Test::Instance::All http://localhost -- qa/specs/features/ee/browser_ui/3_create/jenkins/jenkins_build_status_spec.rb
+WEBDRIVER_HEADLESS=false bin/qa Test::Instance::All http://localhost -- qa/specs/features/ee/browser_ui/3_create/jenkins/jenkins_build_status_spec.rb
 ```
 
 The test automatically spins up a Docker container for Jenkins and tear down once the test completes.
@@ -131,7 +131,7 @@ sudo nginx -s reload
 You could then run the tests from the `/qa` directory:
 
 ```shell
-CHROME_HEADLESS=false bin/qa Test::Instance::All http://gitlab-gitaly-cluster.test -- --tag gitaly_cluster
+WEBDRIVER_HEADLESS=false bin/qa Test::Instance::All http://gitlab-gitaly-cluster.test -- --tag gitaly_cluster
 ```
 
 Once you have finished testing you can stop and remove the Docker containers:
@@ -160,13 +160,13 @@ You might see NGINX issues when you run `gdk start` or `gdk restart`. In that ca
 Navigate to the folder in `/your-gdk/gitlab/qa` and issue the command:
 
 ```shell
-QA_DEBUG=true CHROME_HEADLESS=false GITLAB_ADMIN_USERNAME=rootusername GITLAB_ADMIN_PASSWORD=rootpassword GITLAB_QA_ACCESS_TOKEN=your_token_here GITLAB_QA_ADMIN_ACCESS_TOKEN=your_token_here CLUSTER_API_URL=https://kubernetes.docker.internal:6443 bundle exec bin/qa Test::Instance::All https://[YOUR-PORT].qa-tunnel.gitlab.info/ -- qa/specs/features/browser_ui/8_monitor/all_monitor_core_features_spec.rb --tag kubernetes --tag orchestrated --tag requires_admin
+QA_DEBUG=true WEBDRIVER_HEADLESS=false GITLAB_ADMIN_USERNAME=rootusername GITLAB_ADMIN_PASSWORD=rootpassword GITLAB_QA_ACCESS_TOKEN=your_token_here GITLAB_QA_ADMIN_ACCESS_TOKEN=your_token_here CLUSTER_API_URL=https://kubernetes.docker.internal:6443 bundle exec bin/qa Test::Instance::All https://[YOUR-PORT].qa-tunnel.gitlab.info/ -- qa/specs/features/browser_ui/8_monitor/all_monitor_core_features_spec.rb --tag kubernetes --tag orchestrated --tag requires_admin
 ```
 
 The following includes more information on the command:
 
 -`QA_DEBUG` - Set to `true` to verbosely log page object actions.
--`CHROME_HEADLESS` - When running locally, set to `false` to allow Chrome tests to be visible - watch your tests being run.
+-`WEBDRIVER_HEADLESS` - When running locally, set to `false` to allow browser tests to be visible - watch your tests being run.
 -`GITLAB_ADMIN_USERNAME` - Admin username to use when adding a license.
 -`GITLAB_ADMIN_PASSWORD` - Admin password to use when adding a license.
 -`GITLAB_QA_ACCESS_TOKEN` and `GITLAB_QA_ADMIN_ACCESS_TOKEN` - A valid personal access token with the `api` scope. This is used for API access during tests, and is used in the version that staging is currently running. The `ADMIN_ACCESS_TOKEN` is from a user with admin access. Used for API access as an admin during tests.
@@ -279,7 +279,7 @@ Geo end-to-end tests can run locally against a [Geo GDK setup](https://gitlab.co
 Run from the [`qa/` directory](https://gitlab.com/gitlab-org/gitlab/-/blob/f7272b77e80215c39d1ffeaed27794c220dbe03f/qa) with both GDK Geo primary and Geo secondary instances running:
 
 ```shell
-CHROME_HEADLESS=false bundle exec bin/qa QA::EE::Scenario::Test::Geo --primary-address http://localhost:3001 --secondary-address http://localhost:3002 --without-setup
+WEBDRIVER_HEADLESS=false bundle exec bin/qa QA::EE::Scenario::Test::Geo --primary-address http://localhost:3001 --secondary-address http://localhost:3002 --without-setup
 ```
 
 ### Using Geo in Docker
@@ -455,7 +455,7 @@ To run the LDAP tests on your local with TLS enabled, follow these steps:
 1. Run an LDAP test from [`gitlab/qa`](https://gitlab.com/gitlab-org/gitlab/-/tree/d5447ebb5f99d4c72780681ddf4dc25b0738acba/qa) directory:
 
    ```shell
-   GITLAB_LDAP_USERNAME="tanuki" GITLAB_LDAP_PASSWORD="password" QA_DEBUG=true CHROME_HEADLESS=false bin/qa Test::Instance::All https://gitlab.test qa/specs/features/browser_ui/1_manage/login/log_into_gitlab_via_ldap_spec.rb
+   GITLAB_LDAP_USERNAME="tanuki" GITLAB_LDAP_PASSWORD="password" QA_DEBUG=true WEBDRIVER_HEADLESS=false bin/qa Test::Instance::All https://gitlab.test qa/specs/features/browser_ui/1_manage/login/log_into_gitlab_via_ldap_spec.rb
    ```
 
 ### Running LDAP tests with TLS disabled
@@ -483,5 +483,5 @@ To run the LDAP tests on your local with TLS disabled, follow these steps:
 1. Run an LDAP test from [`gitlab/qa`](https://gitlab.com/gitlab-org/gitlab/-/tree/d5447ebb5f99d4c72780681ddf4dc25b0738acba/qa) directory:
 
    ```shell
-   GITLAB_LDAP_USERNAME="tanuki" GITLAB_LDAP_PASSWORD="password" QA_DEBUG=true CHROME_HEADLESS=false bin/qa Test::Instance::All http://localhost qa/specs/features/browser_ui/1_manage/login/log_into_gitlab_via_ldap_spec.rb
+   GITLAB_LDAP_USERNAME="tanuki" GITLAB_LDAP_PASSWORD="password" QA_DEBUG=true WEBDRIVER_HEADLESS=false bin/qa Test::Instance::All http://localhost qa/specs/features/browser_ui/1_manage/login/log_into_gitlab_via_ldap_spec.rb
    ```
diff --git a/doc/development/usage_ping/dictionary.md b/doc/development/usage_ping/dictionary.md
index cdc9688c602..71c087d86cb 100644
--- a/doc/development/usage_ping/dictionary.md
+++ b/doc/development/usage_ping/dictionary.md
@@ -17378,6 +17378,18 @@ Status: `data_available`
 
 Tiers: `free`
 
+### `usage_activity_by_stage.secure.user_api_fuzzing_scans`
+
+Number of users who have run a API Fuzzing scan
+
+[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_all/20210607044126_user_api_fuzzing_scans.yml)
+
+Group: `category::fuzz testing`
+
+Status: `data_available`
+
+Tiers: `ultimate`
+
 ### `usage_activity_by_stage.secure.user_container_scanning_jobs`
 
 Distinct count per user of Container Scanning jobs run
@@ -17390,6 +17402,18 @@ Status: `data_available`
 
 Tiers: `ultimate`
 
+### `usage_activity_by_stage.secure.user_container_scanning_scans`
+
+Number of users who have run a Container Scanning scan
+
+[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_all/20210607043902_user_container_scanning_scans.yml)
+
+Group: `group::composition analysis`
+
+Status: `data_available`
+
+Tiers: `ultimate`
+
 ### `usage_activity_by_stage.secure.user_coverage_fuzzing_jobs`
 
 Missing description
@@ -17402,6 +17426,18 @@ Status: `data_available`
 
 Tiers: `free`
 
+### `usage_activity_by_stage.secure.user_coverage_fuzzing_scans`
+
+Number of users who have run a Coverage Fuzzing scan
+
+[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_all/20210607044040_user_coverage_fuzzing_scans.yml)
+
+Group: `category::fuzz testing`
+
+Status: `data_available`
+
+Tiers: `ultimate`
+
 ### `usage_activity_by_stage.secure.user_dast_jobs`
 
 Count of DAST jobs
@@ -17414,6 +17450,18 @@ Status: `data_available`
 
 Tiers: `free`
 
+### `usage_activity_by_stage.secure.user_dast_scans`
+
+Number of users who have run a DAST scan
+
+[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_all/20210607043109_user_dast_scans.yml)
+
+Group: `group::dynamic analysis`
+
+Status: `data_available`
+
+Tiers: `ultimate`
+
 ### `usage_activity_by_stage.secure.user_dependency_scanning_jobs`
 
 Total number of users running Dependency Scanning jobs
@@ -17426,6 +17474,18 @@ Status: `data_available`
 
 Tiers: `ultimate`
 
+### `usage_activity_by_stage.secure.user_dependency_scanning_scans`
+
+Number of users who have run a Dependency Scanning scan
+
+[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_all/20210607043819_user_dependency_scanning_scans.yml)
+
+Group: `group::composition analysis`
+
+Status: `data_available`
+
+Tiers: `ultimate`
+
 ### `usage_activity_by_stage.secure.user_license_management_jobs`
 
 Total number of users running License Scanning jobs
@@ -17462,6 +17522,18 @@ Status: `data_available`
 
 Tiers: `free`, `premium`, `ultimate`
 
+### `usage_activity_by_stage.secure.user_sast_scans`
+
+Number of users who have run a SAST scan
+
+[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_all/20210607043741_user_sast_scans.yml)
+
+Group: `group::static analysis`
+
+Status: `data_available`
+
+Tiers: `ultimate`
+
 ### `usage_activity_by_stage.secure.user_secret_detection_jobs`
 
 Count of Secret Detection Jobs
@@ -17474,6 +17546,18 @@ Status: `data_available`
 
 Tiers: `free`, `premium`, `ultimate`
 
+### `usage_activity_by_stage.secure.user_secret_detection_scans`
+
+Number of users who have run a Secret Detection scan
+
+[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_all/20210607043957_user_secret_detection_scans.yml)
+
+Group: `group::static analysis`
+
+Status: `data_available`
+
+Tiers: `ultimate`
+
 ### `usage_activity_by_stage.secure.user_unique_users_all_secure_scanners`
 
 Missing description
@@ -19418,6 +19502,18 @@ Status: `data_available`
 
 Tiers: `free`
 
+### `usage_activity_by_stage_monthly.secure.user_api_fuzzing_scans`
+
+Number of users who have run a API Fuzzing scan
+
+[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_28d/20210607043622_user_api_fuzzing_scans.yml)
+
+Group: `category::fuzz testing`
+
+Status: `data_available`
+
+Tiers: `ultimate`
+
 ### `usage_activity_by_stage_monthly.secure.user_container_scanning_jobs`
 
 Distinct count per user of Container Scanning jobs run monthly
@@ -19430,6 +19526,18 @@ Status: `data_available`
 
 Tiers: `ultimate`
 
+### `usage_activity_by_stage_monthly.secure.user_container_scanning_scans`
+
+Number of users who have run a Container Scanning scan
+
+[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_28d/20210607043336_user_container_scanning_scans.yml)
+
+Group: `group::composition analysis`
+
+Status: `data_available`
+
+Tiers: `ultimate`
+
 ### `usage_activity_by_stage_monthly.secure.user_coverage_fuzzing_jobs`
 
 Missing description
@@ -19442,6 +19550,18 @@ Status: `data_available`
 
 Tiers: `free`
 
+### `usage_activity_by_stage_monthly.secure.user_coverage_fuzzing_scans`
+
+Number of users who have run a Coverage Fuzzing scan
+
+[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_28d/20210607043509_user_coverage_fuzzing_scans.yml)
+
+Group: `category::fuzz testing`
+
+Status: `data_available`
+
+Tiers: `ultimate`
+
 ### `usage_activity_by_stage_monthly.secure.user_dast_jobs`
 
 Users who run a DAST job
@@ -19454,6 +19574,18 @@ Status: `data_available`
 
 Tiers: `free`
 
+### `usage_activity_by_stage_monthly.secure.user_dast_scans`
+
+Number of users who have run a DAST scan
+
+[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_28d/20210607041718_user_dast_scans.yml)
+
+Group: `group::dynamic analysis`
+
+Status: `data_available`
+
+Tiers: `ultimate`
+
 ### `usage_activity_by_stage_monthly.secure.user_dependency_scanning_jobs`
 
 Monthly number of users creating Dependency Scanning jobs
@@ -19466,6 +19598,18 @@ Status: `data_available`
 
 Tiers: `ultimate`
 
+### `usage_activity_by_stage_monthly.secure.user_dependency_scanning_scans`
+
+Number of users who have run a Dependency Scanning scan
+
+[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_28d/20210607043301_user_dependency_scanning_scans.yml)
+
+Group: `group::composition analysis`
+
+Status: `data_available`
+
+Tiers: `ultimate`
+
 ### `usage_activity_by_stage_monthly.secure.user_license_management_jobs`
 
 Monthly number of users running License Scanning jobs
@@ -19502,6 +19646,18 @@ Status: `data_available`
 
 Tiers: `free`, `premium`, `ultimate`
 
+### `usage_activity_by_stage_monthly.secure.user_sast_scans`
+
+Number of users who have run a SAST scan
+
+[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_28d/20210607043218_user_sast_scans.yml)
+
+Group: `group::static analysis`
+
+Status: `data_available`
+
+Tiers: `ultimate`
+
 ### `usage_activity_by_stage_monthly.secure.user_secret_detection_jobs`
 
 Users who run a Secret Detection job
@@ -19514,6 +19670,18 @@ Status: `data_available`
 
 Tiers: `free`, `premium`, `ultimate`
 
+### `usage_activity_by_stage_monthly.secure.user_secret_detection_scans`
+
+Number of users who have run a Secret Detection scan
+
+[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_28d/20210607043410_user_secret_detection_scans.yml)
+
+Group: `group::static analysis`
+
+Status: `data_available`
+
+Tiers: `ultimate`
+
 ### `usage_activity_by_stage_monthly.secure.user_unique_users_all_secure_scanners`
 
 Missing description
diff --git a/lib/banzai/filter/upload_link_filter.rb b/lib/banzai/filter/upload_link_filter.rb
index 2572481c8fc..b110c59a4f1 100644
--- a/lib/banzai/filter/upload_link_filter.rb
+++ b/lib/banzai/filter/upload_link_filter.rb
@@ -45,13 +45,15 @@ module Banzai
           return
         end
 
-        html_attr.value =
+        path =
           if context[:only_path]
             path
           else
             Addressable::URI.join(Gitlab.config.gitlab.base_url, path).to_s
           end
 
+        replace_html_attr_value(html_attr, path)
+
         if html_attr.name == 'href'
           html_attr.parent.set_attribute('data-link', 'true')
         end
@@ -59,6 +61,21 @@ module Banzai
         html_attr.parent.add_class('gfm')
       end
 
+      def replace_html_attr_value(html_attr, path)
+        if path != html_attr.value
+          preserve_original_link(html_attr, html_attr.parent)
+        end
+
+        html_attr.value = path
+      end
+
+      def preserve_original_link(html_attr, node)
+        return if html_attr.blank?
+        return if node.value?('data-canonical-src')
+
+        node.set_attribute('data-canonical-src', html_attr.value)
+      end
+
       def group
         context[:group]
       end
diff --git a/lib/banzai/filter/wiki_link_filter.rb b/lib/banzai/filter/wiki_link_filter.rb
index 2b95d87ff8e..0736181d940 100644
--- a/lib/banzai/filter/wiki_link_filter.rb
+++ b/lib/banzai/filter/wiki_link_filter.rb
@@ -36,7 +36,7 @@ module Banzai
       protected
 
       def process_link(link_attr, node)
-        process_link_attr(link_attr)
+        process_link_attr(link_attr, node)
         remove_unsafe_links({ node: node }, remove_invalid_links: false)
       end
 
@@ -44,14 +44,27 @@ module Banzai
         !context[:wiki].nil?
       end
 
-      def process_link_attr(html_attr)
+      def process_link_attr(html_attr, node)
         return if html_attr.blank?
 
-        html_attr.value = apply_rewrite_rules(html_attr.value)
+        rewritten_value = apply_rewrite_rules(html_attr.value)
+
+        if html_attr.value != rewritten_value
+          preserve_original_link(html_attr, node)
+        end
+
+        html_attr.value = rewritten_value
       rescue URI::Error, Addressable::URI::InvalidURIError
         # noop
       end
 
+      def preserve_original_link(html_attr, node)
+        return if html_attr.blank?
+        return if node.value?('data-canonical-src')
+
+        node.set_attribute('data-canonical-src', html_attr.value)
+      end
+
       def apply_rewrite_rules(link_string)
         Rewriter.new(link_string, wiki: context[:wiki], slug: context[:page_slug]).apply_rules
       end
diff --git a/lib/gitlab/utils/sanitize_node_link.rb b/lib/gitlab/utils/sanitize_node_link.rb
index 620d71a7814..ab5d18e9c8a 100644
--- a/lib/gitlab/utils/sanitize_node_link.rb
+++ b/lib/gitlab/utils/sanitize_node_link.rb
@@ -6,7 +6,7 @@ module Gitlab
   module Utils
     module SanitizeNodeLink
       UNSAFE_PROTOCOLS  = %w(data javascript vbscript).freeze
-      ATTRS_TO_SANITIZE = %w(href src data-src).freeze
+      ATTRS_TO_SANITIZE = %w(href src data-src data-canonical-src).freeze
 
       def remove_unsafe_links(env, remove_invalid_links: true)
         node = env[:node]
diff --git a/qa/qa/runtime/browser.rb b/qa/qa/runtime/browser.rb
index 3fe8552c063..09625581718 100644
--- a/qa/qa/runtime/browser.rb
+++ b/qa/qa/runtime/browser.rb
@@ -89,8 +89,8 @@ module QA
             # Chrome won't work properly in a Docker container in sandbox mode
             options.add_argument("no-sandbox")
 
-            # Run headless by default unless CHROME_HEADLESS is false
-            if QA::Runtime::Env.chrome_headless?
+            # Run headless by default unless WEBDRIVER_HEADLESS is false
+            if QA::Runtime::Env.webdriver_headless?
               options.add_argument("headless")
 
               # Chrome documentation says this flag is needed for now
diff --git a/qa/qa/runtime/env.rb b/qa/qa/runtime/env.rb
index ccb87147a6e..d3241143945 100644
--- a/qa/qa/runtime/env.rb
+++ b/qa/qa/runtime/env.rb
@@ -1,5 +1,6 @@
 # frozen_string_literal: true
 
+require 'active_support/deprecation'
 require 'gitlab/qa'
 require 'uri'
 
@@ -64,9 +65,13 @@ module QA
         ENV['QA_LOG_PATH'] || $stdout
       end
 
-      # set to 'false' to have Chrome run visibly instead of headless
-      def chrome_headless?
-        enabled?(ENV['CHROME_HEADLESS'])
+      # set to 'false' to have the browser run visibly instead of headless
+      def webdriver_headless?
+        if ENV.key?('CHROME_HEADLESS')
+          ActiveSupport::Deprecation.warn("CHROME_HEADLESS is deprecated. Use WEBDRIVER_HEADLESS instead.")
+        end
+
+        enabled?(ENV['WEBDRIVER_HEADLESS']) || enabled?(ENV['CHROME_HEADLESS'])
       end
 
       # set to 'true' to have Chrome use a fixed profile directory
diff --git a/qa/spec/runtime/env_spec.rb b/qa/spec/runtime/env_spec.rb
index 8218ab428b0..ab1043842e5 100644
--- a/qa/spec/runtime/env_spec.rb
+++ b/qa/spec/runtime/env_spec.rb
@@ -54,10 +54,15 @@ RSpec.describe QA::Runtime::Env do
       default: false
   end
 
-  describe '.chrome_headless?' do
+  describe '.webdriver_headless?' do
+    before do
+      # We need to set this because we have a fallback for CHROME_HEADLESS
+      stub_env('CHROME_HEADLESS', 'false')
+    end
+
     it_behaves_like 'boolean method',
-      method: :chrome_headless?,
-      env_key: 'CHROME_HEADLESS',
+      method: :webdriver_headless?,
+      env_key: 'WEBDRIVER_HEADLESS',
       default: true
   end
 
diff --git a/spec/features/projects/tree/create_directory_spec.rb b/spec/features/projects/tree/create_directory_spec.rb
index 54b081161e5..e2ae858cb9b 100644
--- a/spec/features/projects/tree/create_directory_spec.rb
+++ b/spec/features/projects/tree/create_directory_spec.rb
@@ -47,7 +47,7 @@ RSpec.describe 'Multi-file editor new directory', :js do
     find('.js-ide-commit-mode').click
 
     # Compact mode depends on the size of window. If it is shorter than MAX_WINDOW_HEIGHT_COMPACT,
-    # (as it is with CHROME_HEADLESS=0), this initial commit button will exist. Otherwise, if it is
+    # (as it is with WEBDRIVER_HEADLESS=0), this initial commit button will exist. Otherwise, if it is
     # taller (as it is by default with chrome headless) then the button will not exist.
     if page.has_css?('.qa-begin-commit-button')
       find('.qa-begin-commit-button').click
diff --git a/spec/features/projects/tree/create_file_spec.rb b/spec/features/projects/tree/create_file_spec.rb
index cefb84e6f5e..956b8898854 100644
--- a/spec/features/projects/tree/create_file_spec.rb
+++ b/spec/features/projects/tree/create_file_spec.rb
@@ -37,7 +37,7 @@ RSpec.describe 'Multi-file editor new file', :js do
     find('.js-ide-commit-mode').click
 
     # Compact mode depends on the size of window. If it is shorter than MAX_WINDOW_HEIGHT_COMPACT,
-    # (as it is with CHROME_HEADLESS=0), this initial commit button will exist. Otherwise, if it is
+    # (as it is with WEBDRIVER_HEADLESS=0), this initial commit button will exist. Otherwise, if it is
     # taller (as it is by default with chrome headless) then the button will not exist.
     if page.has_css?('.qa-begin-commit-button')
       find('.qa-begin-commit-button').click
diff --git a/spec/lib/banzai/filter/upload_link_filter_spec.rb b/spec/lib/banzai/filter/upload_link_filter_spec.rb
index 9ca499be665..eb45a8149c3 100644
--- a/spec/lib/banzai/filter/upload_link_filter_spec.rb
+++ b/spec/lib/banzai/filter/upload_link_filter_spec.rb
@@ -42,6 +42,12 @@ RSpec.describe Banzai::Filter::UploadLinkFilter do
   let(:upload_path) { '/uploads/e90decf88d8f96fe9e1389afc2e4a91f/test.jpg' }
   let(:relative_path) { "/#{project.full_path}#{upload_path}" }
 
+  it 'preserves original url in data-canonical-src attribute' do
+    doc = filter(link(upload_path))
+
+    expect(doc.at_css('a')['data-canonical-src']).to eq(upload_path)
+  end
+
   context 'to a project upload' do
     context 'with an absolute URL' do
       let(:absolute_path) { Gitlab.config.gitlab.url + relative_path }
diff --git a/spec/lib/banzai/filter/wiki_link_filter_spec.rb b/spec/lib/banzai/filter/wiki_link_filter_spec.rb
index b5b5349946b..70c7c3c74fb 100644
--- a/spec/lib/banzai/filter/wiki_link_filter_spec.rb
+++ b/spec/lib/banzai/filter/wiki_link_filter_spec.rb
@@ -22,6 +22,24 @@ RSpec.describe Banzai::Filter::WikiLinkFilter do
     expect(filtered_link.attribute('href').value).to eq('/uploads/a.test')
   end
 
+  describe 'when links are rewritable' do
+    it "stores original url in the data-canonical-src attribute" do
+      original_path = "#{repository_upload_folder}/a.jpg"
+      filtered_elements = filter("<a href='#{original_path}'><img src='#{original_path}'>example</img></a>", wiki: wiki)
+
+      expect(filtered_elements.search('img').first.attribute('data-canonical-src').value).to eq(original_path)
+      expect(filtered_elements.search('a').first.attribute('data-canonical-src').value).to eq(original_path)
+    end
+  end
+
+  describe 'when links are not rewritable' do
+    it "does not store original url in the data-canonical-src attribute" do
+      filtered_link = filter("<a href='/uploads/a.test'>Link</a>", wiki: wiki).children[0]
+
+      expect(filtered_link.value?('data-canonical-src')).to eq(false)
+    end
+  end
+
   describe 'when links point to the relative wiki path' do
     it 'does not rewrite links' do
       path = "#{wiki.wiki_base_path}/#{repository_upload_folder}/a.jpg"
diff --git a/spec/mailers/emails/releases_spec.rb b/spec/mailers/emails/releases_spec.rb
index 287971d35a8..d1d7f5e6d6a 100644
--- a/spec/mailers/emails/releases_spec.rb
+++ b/spec/mailers/emails/releases_spec.rb
@@ -56,7 +56,7 @@ RSpec.describe Emails::Releases do
       let(:release) { create(:release, project: project, description: "Attachment: [Test file](#{upload_path})") }
 
       it 'renders absolute links' do
-        is_expected.to have_body_text(%Q(<a href="#{project.web_url}#{upload_path}" data-link="true" class="gfm">Test file</a>))
+        is_expected.to have_body_text(%Q(<a href="#{project.web_url}#{upload_path}" data-canonical-src="#{upload_path}" data-link="true" class="gfm">Test file</a>))
       end
     end
   end
diff --git a/spec/mailers/emails/service_desk_spec.rb b/spec/mailers/emails/service_desk_spec.rb
index 57fa990d399..28011456a66 100644
--- a/spec/mailers/emails/service_desk_spec.rb
+++ b/spec/mailers/emails/service_desk_spec.rb
@@ -199,7 +199,7 @@ RSpec.describe Emails::ServiceDesk do
         let_it_be(:note) { create(:note_on_issue, noteable: issue, project: project, note: "a new comment with [file](#{upload_path})") }
 
         let(:template_content) { 'some text %{ NOTE_TEXT  }' }
-        let(:expected_body) { %Q(some text a new comment with <a href="#{project.web_url}#{upload_path}" data-link="true" class="gfm">file</a>) }
+        let(:expected_body) { %Q(some text a new comment with <a href="#{project.web_url}#{upload_path}" data-canonical-src="#{upload_path}" data-link="true" class="gfm">file</a>) }
 
         it_behaves_like 'handle template content', 'new_note'
       end
diff --git a/spec/support/capybara.rb b/spec/support/capybara.rb
index e48a7b322ac..a3cabf4c994 100644
--- a/spec/support/capybara.rb
+++ b/spec/support/capybara.rb
@@ -60,8 +60,8 @@ Capybara.register_driver :chrome do |app|
   # Chrome won't work properly in a Docker container in sandbox mode
   options.add_argument("no-sandbox")
 
-  # Run headless by default unless CHROME_HEADLESS specified
-  options.add_argument("headless") unless ENV['CHROME_HEADLESS'] =~ /^(false|no|0)$/i
+  # Run headless by default unless WEBDRIVER_HEADLESS specified
+  options.add_argument("headless") unless ENV['WEBDRIVER_HEADLESS'] =~ /^(false|no|0)$/i || ENV['CHROME_HEADLESS'] =~ /^(false|no|0)$/i
 
   # Disable /dev/shm use in CI. See https://gitlab.com/gitlab-org/gitlab/issues/4252
   options.add_argument("disable-dev-shm-usage") if ENV['CI'] || ENV['CI_SERVER']
diff --git a/spec/support/helpers/live_debugger.rb b/spec/support/helpers/live_debugger.rb
index cdb068760f4..f4199d518a3 100644
--- a/spec/support/helpers/live_debugger.rb
+++ b/spec/support/helpers/live_debugger.rb
@@ -7,8 +7,8 @@ module LiveDebugger
     puts
     puts "Current example is paused for live debugging."
 
-    if ENV['CHROME_HEADLESS'] =~ /^(false|no|0)$/i
-      puts "Switch to the Chrome window that was automatically opened to run the test in order to view current page"
+    if is_headless_disabled?
+      puts "Switch to the browser window that was automatically opened to run the test in order to view current page"
     else
       puts "Opening #{current_url} in your default browser..."
     end
@@ -16,10 +16,16 @@ module LiveDebugger
     puts "The current user credentials are: #{@current_user.username} / #{@current_user.password}" if @current_user
     puts "Press any key to resume the execution of the example!!"
 
-    `open #{current_url}` if ENV['CHROME_HEADLESS'] !~ /^(false|no|0)$/i
+    `open #{current_url}` if is_headless_disabled?
 
     loop until $stdin.getch
 
     puts "Back to the example!"
   end
+
+  def is_headless_disabled?
+    ActiveSupport::Deprecation.warn("CHROME_HEADLESS is deprecated. Use WEBDRIVER_HEADLESS instead.") if ENV.key?('CHROME_HEADLESS')
+
+    ENV['WEBDRIVER_HEADLESS'] =~ /^(false|no|0)$/i || ENV['CHROME_HEADLESS'] =~ /^(false|no|0)$/i
+  end
 end