Explain scan result policy approval scenarios

What does this MR do and why?

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.

doc/user/application_security/policies/scan-result-policies.md

@@ -279,20 +279,23 @@ actions:
   - adalberto.dare
 ```
 
-## Understanding scan result policy approvals 
+## Understanding scan result policy approvals
 
 ### Scope of scan result policy comparison
 
-- To determine when approval is required on a merge request, we compare the latest completed pipelines for each supported pipeline source for the source and target branch (e.g. feature/main). This ensures the most comprehensive evaluation of scan results.
-- We compare findings from the `main tip` of the target branch.
-- Scan result policies consider multiple pipeline sources (based on the [CI_PIPELINE_SOURCE variable](../../../variables/predefined_variables.md)) when comparing results from each branch and determining when a merge request requires approval. Pipeline sources that are supported include: `:unknown`, `:push`, `:web`,`:trigger`, `:schedule`, `:api`, `:external`, `:pipeline`, `:chat`, `:merge_request_event`, `:external_pull_request_event`, `:security_orchestration_policy`.
-- The following pipeline sources are currently unsupported in scan result policies: `:webide`,`parent_pipeline`.
+- To determine when approval is required on a merge request, we compare the latest completed pipelines for each supported pipeline source for the source and target branch (for example, `feature`/`main`). This ensures the most comprehensive evaluation of scan results.
+- We compare findings from the latest completed pipelines that ran on `HEAD` of the source and target branch.
+- Scan result policies considers all supported pipeline sources (based on the [`CI_PIPELINE_SOURCE` variable](../../../ci/variables/predefined_variables.md)) when comparing results from both the source and target branches when determining if a merge request requires approval. Pipeline sources `webide` and `parent_pipeline` are not supported.
 
 ### Accepting risk and ignoring vulnerabilities in future merge requests
 
-For policies that are scoped to `newly_detected` findings, approved merge requests create "exceptions" to the policy for future merge requests. Any findings that violate a policy that are merged into the `default` branch are used in future scan result policy evaluations and therefore are no longer "newly detected".
+For scan result policies that are scoped to `newly_detected` findings, it's important to understand the implications of this vulnerability state. A finding is considered `newly_detected` if it exists on the merge request's branch but not on the default branch. When a merge request whose branch contains `newly_detected` findings is approved and merged, approvers are "accepting the risk" of those vulnerabilities. If one or more of the same vulnerabilities were detected after this time, their status would be `previously_detected` and so not be out of scope of a policy aimed at `newly_detected` findings. For example:
 
-For license approval policies, if a license is approved as an exception, future merge requests will no longer require approval for the same combination of license + dependency/component + project. The component version will not be considered in this case. If a previously approved package gets updated to a new version, approvers will not need to re-approve.
+- A scan result policy is created to block critical SAST findings. If a SAST finding for CVE-1234 is approved, future merge requests with the same violation will not require approval in the project.
+
+When using license approval policies, the combination of project, component (dependency), and license are considered in the evaluation. If a license is approved as an exception, future merge requests don't require approval for the same combination of project, component (dependency), and license. The component's version is not be considered in this case. If a previously approved package is updated to a new version, approvers will not need to re-approve. For example:
+
+- A license approval policy is created to block merge requests with newly detected licenses matching `AGPL-1.0`. A change is made in project `demo` for component `osframework` that violates the policy. If approved and merged, future merge requests to `osframework` in project `demo` with the license `AGPL-1.0` don't require approval.
 
 ### Multiple approvals
 
@@ -314,7 +317,8 @@ There are several situations where the scan result policy requires an additional
 
 ### Known issues
 
-We are identifying common areas of confusion in scan result findings in [this epic](https://gitlab.com/groups/gitlab-org/-/epics/11020) to be addressed. Below are a few of the known issues:
+We have identified in [epic 11020](https://gitlab.com/groups/gitlab-org/-/epics/11020) common areas of confusion in scan result findings that need to be addressed. Below are a few of the known issues:
 
-- When using `newly_detected`, some findings may require approval when they are not introduced by the merge request (such as a new CVE on a related dependency). We currently use `main tip` of the target branch for comparison. In the future, we plan to use `merge base` for `newly_detected` policies (see [epic](https://gitlab.com/gitlab-org/gitlab/-/issues/428518)).
-- Findings or errors that cause approval to be required on a scan result policy may not be evident in the Security MR Widget. By using `merge base` in [this epic](https://gitlab.com/gitlab-org/gitlab/-/issues/428518) some cases will be addressed. We will additionally be [displaying more granular details](https://gitlab.com/groups/gitlab-org/-/epics/11185) about what caused security policy violations.
+- When using `newly_detected`, some findings may require approval when they are not introduced by the merge request (such as a new CVE on a related dependency). We currently use `main tip` of the target branch for comparison. In the future, we plan to use `merge base` for `newly_detected` policies (see [issue 428518](https://gitlab.com/gitlab-org/gitlab/-/issues/428518)).
+- Findings or errors that cause approval to be required on a scan result policy may not be evident in the Security MR Widget. By using `merge base` in [issue 428518](https://gitlab.com/gitlab-org/gitlab/-/issues/428518) some cases will be addressed. We will additionally be [displaying more granular details](https://gitlab.com/groups/gitlab-org/-/epics/11185) about what caused security policy violations.
+- Security policy violations are distinct compared to findings displayed in the MR widgets. Some violations may not be present in the MR widget. We are working to harmonize our features in [epic 11020](https://gitlab.com/groups/gitlab-org/-/epics/11020) and to display policy violations explicitly in merge requests in [epic 11185](https://gitlab.com/groups/gitlab-org/-/epics/11185).