Add latest changes from gitlab-org/gitlab@master

4 files changed, 36 insertions, 3 deletions

diff --git a/doc/api/group_protected_environments.md b/doc/api/group_protected_environments.md
index 8ebd0dcd99a..0f1527f8968 100644
--- a/doc/api/group_protected_environments.md
+++ b/doc/api/group_protected_environments.md
@@ -106,7 +106,7 @@ POST /groups/:id/protected_environments
 | `id`      | integer/string | yes | The ID or [URL-encoded path of the group](index.md#namespaced-path-encoding) maintained by the authenticated user. |
 | `name`    | string | yes    | The deployment tier of the protected environment. One of `production`, `staging`, `testing`, `development`, or `other`. Read more about [deployment tiers](../ci/environments/index.md#deployment-tier-of-environments).|
 | `deploy_access_levels`          | array          | yes | Array of access levels allowed to deploy, with each described by a hash. One of `user_id`, `group_id` or `access_level`. They take the form of `{user_id: integer}`, `{group_id: integer}` or `{access_level: integer}` respectively. |
-| `required_approval_count` | integer        | no       | The number of approvals required to deploy to this environment. This is part of Deployment Approvals, which isn't yet available for use. For details, see [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/343864). |
+| `required_approval_count` | integer        | no       | The number of approvals required to deploy to this environment. |
 | `approval_rules`                | array          | no  | Array of access levels allowed to approve, with each described by a hash. One of `user_id`, `group_id` or `access_level`. They take the form of `{user_id: integer}`, `{group_id: integer}` or `{access_level: integer}` respectively. You can also specify the number of required approvals from the specified entity with `required_approvals` field. See [Multiple approval rules](../ci/environments/deployment_approvals.md#multiple-approval-rules) for more information. |
 
 The assignable `user_id` are the users who belong to the given group with the Maintainer role (or above).
diff --git a/doc/integration/saml.md b/doc/integration/saml.md
index 6dd9f6e72c5..0c517d07f41 100644
--- a/doc/integration/saml.md
+++ b/doc/integration/saml.md
@@ -709,7 +709,6 @@ args: {
   security: {
     authn_requests_signed: true,  # enable signature on AuthNRequest
     want_assertions_signed: true,  # enable the requirement of signed assertion
-    embed_sign: true,  # embedded signature or HTTP GET parameter signature
     metadata_signed: false,  # enable signature on Metadata
     signature_method: 'http://www.w3.org/2001/04/xmldsig-more#rsa-sha256',
     digest_method: 'http://www.w3.org/2001/04/xmlenc#sha256',
diff --git a/doc/user/application_security/dependency_scanning/index.md b/doc/user/application_security/dependency_scanning/index.md
index 532698d28e3..c4672e61c99 100644
--- a/doc/user/application_security/dependency_scanning/index.md
+++ b/doc/user/application_security/dependency_scanning/index.md
@@ -601,7 +601,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`      | This feature was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/287691) in GitLab 14.0 and [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/333299) in 15.0. Use `DS_EXCLUDED_ANALYZERS` instead. |
-| `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"`. |
+| `DS_EXCLUDED_PATHS`         | Exclude files and directories from the scan based on the paths. A comma-separated list of patterns. Patterns can be globs (see [`doublestar.Match`](https://pkg.go.dev/github.com/bmatcuk/doublestar/v4@v4.0.2#Match) for supported patterns), or file or folder paths (for example, `doc,spec`). Parent directories also match patterns. Default: `"spec, test, tests, tmp"`. |
 | `DS_IMAGE_SUFFIX`           | Suffix added to the image name. ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/354796) in GitLab 14.10.) Automatically set to `"-fips"` when FIPS mode is enabled. ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/357922) in GitLab 15.0.) |
 | `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/get-started-security.md b/doc/user/application_security/get-started-security.md
new file mode 100644
index 00000000000..4c2b971b5fa
--- /dev/null
+++ b/doc/user/application_security/get-started-security.md
@@ -0,0 +1,34 @@
+---
+stage: DevSecOps
+group: Technical writing
+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
+---
+
+# Get started with GitLab application security **(ULTIMATE)**
+
+Complete the following steps to get the most from GitLab application security tools.
+
+1. Enable [Secret Detection](secret_detection/index.md) scanning for your default branch.
+1. Enable [Dependency Scanning](dependency_scanning/index.md) for your default branch so you can start identifying existing
+   vulnerable packages in your codebase.
+1. Add security scans to feature branch pipelines. The same scans should be enabled as are running
+   on your default branch. Subsequent scans will show only new vulnerabilities by comparing the feature branch to the default branch results.
+1. Let your team get comfortable with [vulnerability reports](vulnerability_report/index.md) and
+   establish a vulnerability triage workflow.
+1. Consider creating [labels](../project/labels.md) and [issue boards](../project/issue_board.md) to
+   help manage issues created from vulnerabilities. Issue boards allow all stakeholders to have a
+   common view of all issues.
+1. Create a [scan result policy](policies/index.md) to limit new vulnerabilities from being merged
+   into your default branch.
+1. Monitor the [Security Dashboard](security_dashboard/index.md) trends to gauge success in
+   remediating existing vulnerabilities and preventing the introduction of new ones.
+1. Enable other scan types such as [SAST](sast/index.md), [DAST](dast/index.md),
+   [Fuzz testing](coverage_fuzzing/index.md), or [Container Scanning](container_scanning/index.md).
+   Be sure to add the same scan types to both feature pipelines and default branch pipelines.
+1. Use [Compliance Pipelines](../../user/project/settings/index.md#compliance-pipeline-configuration)
+   or [Scan Execution Policies](policies/scan-execution-policies.md) to enforce required scan types
+   and ensure separation of duties between security and engineering.
+1. Consider enabling [Review Apps](../../development/testing_guide/review_apps.md) to allow for DAST
+   and [Web API fuzzing](api_fuzzing/index.md) on ephemeral test environments.
+1. Enable [operational container scanning](../../user/clusters/agent/vulnerabilities.md) to scan
+   container images in your production cluster for security vulnerabilities.