Initial draft of security policies vs compliance pipelines docs

doc/user/application_security/index.md

@@ -441,6 +441,46 @@ When customizing the configuration:
   version contains the most recent changes, but may have significant changes between minor GitLab versions.
 - Only override values in the template as needed. All other values are inherited from the template.
 
+### Enforce scan execution
+
+Security and compliance teams must ensure that security scans:
+
+- Run on a regular basis for all projects.
+- Can't be disabled by developers.
+
+GitLab provides two methods of accomplishing this, each with advantages and disadvantages.
+
+- [Compliance framework pipelines](../project/settings/#compliance-pipeline-configuration)
+  are recommended when:
+
+  - Scan execution enforcement is required for SAST IaC, Container Scanning, Dependency Scanning,
+    License Compliance, API Fuzzing, or Coverage-guided Fuzzing.
+  - Scan execution enforcement of SAST or Secret Detection when customization of the default scan
+    variables is required.
+  - Scan execution enforcement is required for scanners external to GitLab.
+  - Enforced execution is required for custom jobs other than security scans.
+
+- [Scan execution policies](policies/#scan-execution-policies)
+  are recommended when:
+
+  - Scan execution enforcement is required for DAST.
+  - Scan execution enforcement is required for SAST or Secret Detection with the default scan
+    variables.
+  - Scans are required to run on a regular, scheduled cadence.
+
+Additional details about the differences between the two solutions are outlined below:
+
+| | Compliance Framework Pipelines | Scan Execution Policies |
+| ------ | ------ | ------ |
+| **Flexibility** | Supports anything that can be done in a CI file. | Limited to only the items for which GitLab has explicitly added support. DAST, SAST, and Secret Detection scans are supported. |
+| **Usability** | Requires knowledge of CI YAML. | Follows a `rules` and `actions`-based YAML structure. |
+| **Inclusion in CI pipeline** | The compliance pipeline is executed instead of the project's `gitlab-ci.yml` file. To include the project's `gitlab-ci.yml` file, use an `include` statement. Defined variables aren't allowed to be overwritten by the included project's YAML file. | Forced inclusion of a new job into the CI pipeline. DAST jobs that must be customized on a per-project basis can have project-level Site Profiles and Scan Profiles defined. To ensure separation of duties, these profiles are immutable when referenced in a scan execution policy. |
+| **Schedulable** | Can be scheduled through a scheduled pipeline on the group. | Can be scheduled natively through the policy configuration itself. |
+| **Separation of Duties** | Only group owners can create compliance framework labels. Only project owners can apply compliance framework labels to projects. The ability to make or approve changes to the compliance pipeline definition is limited to individuals who are explicitly given access to the project that contains the compliance pipeline. | Only project owners can define a linked security policy project. The ability to make or approve changes to security policies is limited to individuals who are explicitly given access to the security policy project. |
+| **Ability to apply one standard to multiple projects** | The same compliance framework label can be applied to multiple projects inside a group. | The same security policy project can be used for multiple projects across GitLab with no requirement of being located in the same group. |
+
+Feedback is welcome on our vision for [unifying the user experience for these two features](https://gitlab.com/groups/gitlab-org/-/epics/7312)
+
 ## Troubleshooting
 
 ### Secure job failing with exit code 1

doc/user/application_security/policies/index.md

@@ -236,6 +236,18 @@ Project owners can unlink Security Policy projects from development projects. To
 the steps described in [Security Policy project selection](#security-policy-project-selection),
 but select the trash can icon in the modal.
 
+## Scan execution policies
+
+Project owners can use scan execution policies to require that security scans run on a specified
+schedule or with the project pipeline. Required scans are injected into the CI pipeline as new jobs
+with a long, random job name. In the unlikely event of a job name collision, the security policy job
+overwrites any pre-existing job in the pipeline.
+
+This feature has some overlap with [compliance framework pipelines](../../project/settings/#compliance-pipeline-configuration),
+as we have not [unified the user experience for these two features](https://gitlab.com/groups/gitlab-org/-/epics/7312).
+For details on the similarities and differences between these features, see
+[Enforce scan execution](../#enforce-scan-execution).
+
 ### Scan Execution Policy editor
 
 NOTE:

doc/user/project/settings/index.md

@@ -86,12 +86,17 @@ read-only view to discourage this behavior.
 > - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/300324) in GitLab 13.11.
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/331231) in GitLab 14.2.
 
-Group owners can use compliance pipeline configuration to add additional pipeline configuration to
-projects to define compliance requirements such as scans or tests.
-
-[Compliance frameworks](#compliance-frameworks) allow group owners to specify the location of
-compliance pipeline configuration stored and managed in dedicated projects, separate from regular
-projects.
+Compliance framework pipelines allow group owners to define
+a compliance pipeline in a separate repository that gets
+executed in place of the local project's `gitlab-ci.yml` file. As part of this pipeline, an
+`include` statement can reference the local project's `gitlab-ci.yml` file. This way, the two CI
+files are merged together any time the pipeline runs. Jobs and variables defined in the compliance
+pipeline can't be changed by variables in the local project's `gitlab-ci.yml` file.
+
+When used to enforce scan execution, this feature has some overlap with [scan execution policies](../../application_security/policies/#scan-execution-policies),
+as we have not [unified the user experience for these two features](https://gitlab.com/groups/gitlab-org/-/epics/7312).
+For details on the similarities and differences between these features, see
+[Enforce scan execution](../../application_security/#enforce-scan-execution).
 
 When you set up the compliance framework, use the **Compliance pipeline configuration** box to link
 the compliance framework to specific CI/CD configuration. Use the