Add latest changes from gitlab-org/security/gitlab@16-2-stable-ee

2 files changed, 6 insertions, 1 deletions

diff --git a/doc/user/application_security/policies/index.md b/doc/user/application_security/policies/index.md
index 4e610d64ec9..aba3696d536 100644
--- a/doc/user/application_security/policies/index.md
+++ b/doc/user/application_security/policies/index.md
@@ -147,7 +147,8 @@ The workaround is to amend your group or instance push rules to allow branches f
 - Scan result policies created at the group or sub-group level can take some time to apply to all the merge requests in the group.
 - Scheduled scan execution policies run with a minimum 15 minute cadence. Learn more [about the schedule rule type](../policies/scan-execution-policies.md#schedule-rule-type).
 - When scheduling pipelines, keep in mind that CRON scheduling is based on UTC on GitLab SaaS and is based on your server time for self managed instances. When testing new policies, it may appear pipelines are not running properly when in fact they are scheduled in your server's timezone.
-- When enforcing scan execution policies, the target project's pipeline is triggered by the user who last updated the security policy project's `policy.yml` file. The user must have permission to trigger the pipeline in the project for the policy to be enforced, and the pipeline to run. Work to address this is being tracked in [issue 394958](https://gitlab.com/gitlab-org/gitlab/-/issues/394958).
+- When enforcing scan execution policies, security policies creates a bot in the target project that will trigger scheduled pipelines to ensure enforcement. If the bot is
+deleted or missing, the target project's pipeline will not be executed. To recreate a security policy bot user unlink and link the security policy project again.
 - You should not link a security policy project to a development project and to the group or sub-group the development project belongs to at the same time. Linking this way will result in approval rules from the Scan Result Policy not being applied to merge requests in the development project.
 - When creating a Scan Result Policy, neither the array `severity_levels` nor the array `vulnerability_states` in the [scan_finding rule](../policies/scan-result-policies.md#scan_finding-rule-type) can be left empty; for a working rule, at least one entry must exist.
 
diff --git a/doc/user/application_security/policies/scan-execution-policies.md b/doc/user/application_security/policies/scan-execution-policies.md
index b84d4d2e49e..effc7b8be38 100644
--- a/doc/user/application_security/policies/scan-execution-policies.md
+++ b/doc/user/application_security/policies/scan-execution-policies.md
@@ -127,6 +127,10 @@ This rule enforces the defined actions and schedules a scan on the provided date
 
 1. You must specify only one of `branches`, `branch_type`, or `agents`.
 
+Scheduled scan pipelines are triggered by a security policy bot user that is a guest member of the project with elevated permissions for users of type `security_policy_bot` so it may carry out this task. Security policy bot users are automatically created when the security policy project is linked, and removed when the security policy project is unlinked.
+
+If the project does not have a security policy bot user, the scheduled scan pipeline will not be triggered. To recreate a security policy bot user unlink and link the security policy project again.
+
 GitLab supports the following types of CRON syntax for the `cadence` field:
 
 - A daily cadence of once per hour at a specified hour, for example: `0 18 * * *`