Add latest changes from gitlab-org/gitlab@master

2 files changed, 30 insertions, 1 deletions

diff --git a/doc/architecture/blueprints/cells/cells-feature-user-profile.md b/doc/architecture/blueprints/cells/cells-feature-user-profile.md
index ca555074248..855df497c1e 100644
--- a/doc/architecture/blueprints/cells/cells-feature-user-profile.md
+++ b/doc/architecture/blueprints/cells/cells-feature-user-profile.md
@@ -15,16 +15,36 @@ we can document the reasons for not choosing this approach.
 
 # Cells: User Profile
 
-> TL;DR
+The existing User Profiles will initially be scoped to an Organization. Long-term, we should consider aggregating parts of the User activity across Organizations to enable Users a global view of their contributions.
 
 ## 1. Definition
 
+Each GitLab account has a [User Profile](../../../user/profile/index.md), which contains information about the User and their GitLab activity.
+
 ## 2. Data flow
 
 ## 3. Proposal
 
+User Profiles will be scoped to an Organization.
+
+- Users can set a Home Organization as their main Organization.
+- Users who do not exist in the database at all display a 404 not found error when trying to access their User Profile.
+- User who haven't contributed to an Organization display their User Profile with an empty state.
+- When displaying a User Profile empty state, if the profile has a Home Organization set to another Organization, we display a call-to-action allowing navigation to the main Organization.
+
+See [issue #411931](https://gitlab.com/gitlab-org/gitlab/-/issues/411931) for design proposals.
+
 ## 4. Evaluation
 
+We expect the [majority of Users to perform most of their activity in one single Organization](../organization/index.md#data-exploration).
+This is why we deem it acceptable to scope the User Profile to an Organization at first.
+More discovery is necessary to understand which aspects of the current User Profile are relevant to showcase contributions in a global context.
+
 ## 4.1. Pros
 
+- Viewing a User Profile scoped to an Organization allows you to focus on contributions that are most relevant to your Organization, filtering out the User's other activities.
+- Existing User Profile URLs do not break.
+
 ## 4.2. Cons
+
+- Users will lose the ability to display their entire activity, which may lessen the effectiveness of using their User Profile as a resume of achievements when working across multiple Organizations.
diff --git a/doc/user/application_security/policies/scan-execution-policies.md b/doc/user/application_security/policies/scan-execution-policies.md
index b84d4d2e49e..6c0023d027c 100644
--- a/doc/user/application_security/policies/scan-execution-policies.md
+++ b/doc/user/application_security/policies/scan-execution-policies.md
@@ -113,6 +113,11 @@ This rule enforces the defined actions whenever the pipeline runs for a selected
 
 > - The `branch_type` field was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/404774) in GitLab 16.1 [with a flag](../../../administration/feature_flags.md) named `security_policies_branch_type`. Disabled by default.
 > - The `branch_type` field was [enabled on GitLab.com and self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/413062) in GitLab 16.2.
+> - The security policy bot users were [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/394958) in GitLab 16.3 [with flags](../../../administration/feature_flags.md) named `scan_execution_group_bot_users` and `scan_execution_bot_users`. Enabled by default.
+
+FLAG:
+On self-managed GitLab, security policy bot users are available. To hide the feature, an administrator can [disable the feature flags](../../../administration/feature_flags.md) named `scan_execution_group_bot_users` and `scan_execution_bot_users`.
+On GitLab.com, this feature is available.
 
 This rule enforces the defined actions and schedules a scan on the provided date/time.
 
@@ -127,6 +132,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. 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 is triggered by the user that modified the security policy project last.
+
 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 * * *`