Add latest changes from gitlab-org/gitlab@master

5 files changed, 60 insertions, 48 deletions

diff --git a/doc/development/go_guide/index.md b/doc/development/go_guide/index.md
index 9bf8b7ef89a..184605170b8 100644
--- a/doc/development/go_guide/index.md
+++ b/doc/development/go_guide/index.md
@@ -452,7 +452,7 @@ If the scanner report is small, less than 35 lines, then feel free to [inline th
 
 #### Test Diffs
 
-The [go-cmp]<https://github.com/google/go-cmp> package should be used when comparing large structs in tests. It makes it possible to output a specific diff where the two structs differ, rather than seeing the whole of both structs printed out in the test logs. Here is a small example:
+The [go-cmp](https://github.com/google/go-cmp) package should be used when comparing large structs in tests. It makes it possible to output a specific diff where the two structs differ, rather than seeing the whole of both structs printed out in the test logs. Here is a small example:
 
 ```golang
 package main
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 797a0b2dd72..ef3e0624395 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
@@ -496,12 +496,12 @@ Tests that are tagged with `:mobile` can be run against specified mobile devices
 
 Running directly against an environment like staging is not recommended because Sauce Labs test logs expose credentials. Therefore, it is best practice and the default to use a tunnel.
 
-Tunnel installation instructions are here [https://docs.saucelabs.com/secure-connections/sauce-connect/installation]. To start the tunnel, after following the installation above, copy the run command in Sauce Labs > Tunnels (must be logged in to Sauce Labs with the credentials found in 1Password) and run in terminal.
+For tunnel installation instructions, read [Sauce Connect Proxy Installation](https://docs.saucelabs.com/secure-connections/sauce-connect/installation). To start the tunnel, after following the installation above, copy the run command in Sauce Labs > Tunnels (must be logged in to Sauce Labs with the credentials found in 1Password) and run in terminal.
 
 NOTE:
 It is highly recommended to use `GITLAB_QA_ACCESS_TOKEN` to speed up tests and reduce flakiness.
 
-`QA_REMOTE_MOBILE_DEVICE_NAME` can be any device name listed in [https://saucelabs.com/platform/supported-browsers-devices] under Emulators/simulators and the latest versions of Android or iOS. `QA_BROWSER` must be set to `safari` for iOS devices and `chrome` for Android devices.
+`QA_REMOTE_MOBILE_DEVICE_NAME` can be any device name listed in [Supported browsers and devices](https://saucelabs.com/platform/supported-browsers-devices) under Emulators/simulators and the latest versions of Android or iOS. `QA_BROWSER` must be set to `safari` for iOS devices and `chrome` for Android devices.
 
 1. To test against a local instance with a tunnel running, in `gitlab/qa` run:
 
diff --git a/doc/user/application_security/dependency_scanning/index.md b/doc/user/application_security/dependency_scanning/index.md
index 5d412d89186..75f52808de4 100644
--- a/doc/user/application_security/dependency_scanning/index.md
+++ b/doc/user/application_security/dependency_scanning/index.md
@@ -510,7 +510,7 @@ The following variables allow configuration of global dependency scanning settin
 | `ADDITIONAL_CA_CERT_BUNDLE` | Bundle of CA certs to trust. The bundle of certificates provided here is also used by other tools during the scanning process, such as `git`, `yarn`, or `npm`. See [Using a custom SSL CA certificate authority](#using-a-custom-ssl-ca-certificate-authority) for more details. |
 | `DS_EXCLUDED_ANALYZERS`      | Specify the analyzers (by name) to exclude from Dependency Scanning. For more information, see [Dependency Scanning Analyzers](analyzers.md). |
 | `DS_DEFAULT_ANALYZERS`      | ([**DEPRECATED - use `DS_EXCLUDED_ANALYZERS` instead**](https://gitlab.com/gitlab-org/gitlab/-/issues/287691)) Override the names of the official default images. For more information, see [Dependency Scanning Analyzers](analyzers.md). |
-| `DS_EXCLUDED_PATHS`         | Exclude vulnerabilities from output based on the paths. A comma-separated list of patterns. Patterns can be globs, or file or folder paths (for example, `doc,spec`). Parent directories also match patterns. Default: `"spec, test, tests, tmp"`. |
+| `DS_EXCLUDED_PATHS`         | Exclude files and directories from the scan based on the paths. A comma-separated list of patterns. Patterns can be globs, or file or folder paths (for example, `doc,spec`). Parent directories also match patterns. Default: `"spec, test, tests, tmp"`. |
 | `SECURE_ANALYZERS_PREFIX`   | Override the name of the Docker registry providing the official default images (proxy). Read more about [customizing analyzers](analyzers.md). |
 | `SECURE_LOG_LEVEL`          | Set the minimum logging level. Messages of this logging level or higher are output. From highest to lowest severity, the logging levels are: `fatal`, `error`, `warn`, `info`, `debug`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10880) in GitLab 13.1. Default: `info`. |
 
diff --git a/doc/user/application_security/policies/index.md b/doc/user/application_security/policies/index.md
index 10bd04cbc3f..03eee2ad180 100644
--- a/doc/user/application_security/policies/index.md
+++ b/doc/user/application_security/policies/index.md
@@ -313,9 +313,10 @@ rule in the defined policy are met.
 
 | Field | Type | Possible values | Description |
 |-------|------|-----------------|-------------|
-| `scan` | `string` | `dast`, `secret_detection`, `sast` | The action's type. |
+| `scan` | `string` | `dast`, `secret_detection`, `sast`, `container_scanning`, `cluster_image_scanning` | The action's type. |
 | `site_profile` | `string` | Name of the selected [DAST site profile](../dast/index.md#site-profile). | The DAST site profile to execute the DAST scan. This field should only be set if `scan` type is `dast`. |
 | `scanner_profile` | `string` or `null` | Name of the selected [DAST scanner profile](../dast/index.md#scanner-profile). | The DAST scanner profile to execute the DAST scan. This field should only be set if `scan` type is `dast`.|
+| `variables` | `object` | | Set of variables applied and enforced for the selected scan. The object's key is the variable name with a value provided as a string. |
 
 Note the following:
 
@@ -379,6 +380,9 @@ scan_execution_policy:
     - main
   actions:
   - scan: secret_detection
+  - scan: sast
+    variables:
+      SAST_EXCLUDED_ANALYZERS: brakeman
   - scan: container_scanning
 - name: Enforce Cluster Image Scanning on production-cluster every 24h
   description: This policy enforces Cluster Image Scanning scan to run every 24 hours
@@ -406,7 +410,8 @@ In this example:
   `release/v1.2.1`), DAST scans run with `Scanner Profile A` and `Site Profile B`.
 - DAST and secret detection scans run every 10 minutes. The DAST scan runs with `Scanner Profile C`
   and `Site Profile D`.
-- Secret detection and container scanning scans run for every pipeline executed on the `main` branch.
+- Secret detection, container scanning, and SAST scans run for every pipeline executed on the `main`
+  branch. The SAST scan runs with the `SAST_EXCLUDED_ANALYZER` variable set to `"brakeman"`.
 - Cluster Image Scanning scan runs every 24h. The scan runs on the `production-cluster` cluster and fetches vulnerabilities
   from the container with the name `database` configured for deployment with the name `production-application` in the `production-namespace` namespace.
 
diff --git a/doc/user/project/integrations/bamboo.md b/doc/user/project/integrations/bamboo.md
index 58cfd8c3a2f..38de8d9f1af 100644
--- a/doc/user/project/integrations/bamboo.md
+++ b/doc/user/project/integrations/bamboo.md
@@ -4,59 +4,66 @@ group: Integrations
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# Atlassian Bamboo Service **(FREE)**
+# Atlassian Bamboo integration **(FREE)**
 
-GitLab provides integration with Atlassian Bamboo for continuous integration.
-When configured, pushes to a project trigger a build in Bamboo automatically.
-Merge requests also display CI/CD status showing whether the build is pending,
-failed, or completed successfully. It also provides a link to the Bamboo build
-page for more information.
+You can automatically trigger builds in Atlassian Bamboo when you push changes
+to your project in GitLab.
 
-Bamboo doesn't quite provide the same features as a traditional build system when
-it comes to accepting webhooks and commit data. There are a few things that
-need to be configured in a Bamboo build plan before GitLab can integrate.
+When this integration is configured, merge requests also display the following information:
 
-## Setup
+- A CI/CD status that shows if the build is pending, failed, or has completed successfully.
+- A link to the Bamboo build page for more information.
 
-### Complete these steps in Bamboo
+Bamboo doesn't provide the same features as a traditional build system when
+accepting webhooks and commit data. You must configure a Bamboo
+build plan before you configure the integration in GitLab.
 
-1. Navigate to a Bamboo build plan and choose **Configure plan** from the **Actions**
-   dropdown.
+## Configure Bamboo
+
+1. In Bamboo, go to a build plan and choose **Actions > Configure plan**.
 1. Select the **Triggers** tab.
-1. Click **Add trigger**.
-1. Enter a description such as **GitLab trigger**.
-1. Choose **Repository triggers the build when changes are committed**.
+1. Select **Add trigger**.
+1. Enter a description like `GitLab trigger`.
+1. Select **Repository triggers the build when changes are committed**.
 1. Select the checkbox for one or more repositories.
-1. Enter the GitLab IP address in the **Trigger IP addresses** box. This is a
-   list of IP addresses that are allowed to trigger Bamboo builds.
+1. Enter the GitLab IP address in **Trigger IP addresses**. These IP addresses
+   are allowed to trigger Bamboo builds.
 1. Save the trigger.
-1. In the left pane, select a build stage. If you have multiple build stages
-   you want to select the last stage that contains the Git checkout task.
+1. In the left pane, select a build stage. If you have multiple build stages,
+   select the last stage that contains the Git checkout task.
 1. Select the **Miscellaneous** tab.
-1. Under **Pattern Match Labeling** put `${bamboo.repository.revision.number}`
-   in the **Labels** box.
-1. Save
-
-Bamboo is now ready to accept triggers from GitLab. Next, set up the Bamboo
-service in GitLab.
-
-### Complete these steps in GitLab
-
-1. Navigate to the project you want to configure to trigger builds.
-1. Navigate to the [Integrations page](overview.md#accessing-integrations)
-1. Click **Atlassian Bamboo**.
-1. Ensure that the **Active** toggle is enabled.
-1. Enter the base URL of your Bamboo server. `https://bamboo.example.com`
-1. Enter the build key from your Bamboo build plan. Build keys are typically made
-   up from the Project Key and Plan Key that are set on project/plan creation and
-   separated with a dash (`-`), for example **PROJ-PLAN**. This is a short, all
-   uppercase identifier that is unique. When viewing a plan in Bamboo, the
-   build key is also shown in the browser URL, for example `https://bamboo.example.com/browse/PROJ-PLAN`.
-1. If necessary, enter username and password for a Bamboo user that has
+1. Under **Pattern Match Labeling** enter `${bamboo.repository.revision.number}`
+   in **Labels**.
+1. Select **Save**.
+
+Bamboo is ready to accept triggers from GitLab. Next, set up the Bamboo
+integration in GitLab.
+
+## Configure GitLab
+
+1. On the top bar, select **Menu > Projects** and find your project.
+1. On the left sidebar, select **Settings > Integrations**.
+1. Select **Atlassian Bamboo**.
+1. Ensure the **Active** checkbox is selected.
+1. Enter the base URL of your Bamboo server. For example, `https://bamboo.example.com`.
+1. Enter the [build key](#identify-the-bamboo-build-plan-build-key) from your Bamboo
+   build plan.
+1. If necessary, enter a username and password for a Bamboo user that has
    access to trigger the build plan. Leave these fields blank if you do not require
    authentication.
-1. Save or optionally click **Test Settings**. **Test Settings**
-   actually triggers a build in Bamboo.
+1. Optional. To test the configuration and trigger a build in Bamboo,
+   select **Test Settings**.
+1. Select **Save changes**.
+
+### Identify the Bamboo build plan build key
+
+A build key is a unique identifier typically made up from the project key and
+plan key.
+Build keys are short, all uppercase, and separated with a dash (`-`),
+for example `PROJ-PLAN`.
+
+The build key is included in the browser URL when you view a plan in
+Bamboo. For example, `https://bamboo.example.com/browse/PROJ-PLAN`.
 
 ## Troubleshooting