Add latest changes from gitlab-org/gitlab@master

6 files changed, 98 insertions, 16 deletions

diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index a5efccabd38..c63b1cf0352 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -23401,7 +23401,7 @@ Represents the network policy.
 
 | Name | Type | Description |
 | ---- | ---- | ----------- |
-| <a id="noteauthor"></a>`author` | [`UserCore!`](#usercore) | User who wrote this note. |
+| <a id="noteauthor"></a>`author` | [`UserCore`](#usercore) | User who wrote this note. |
 | <a id="noteauthoriscontributor"></a>`authorIsContributor` | [`Boolean`](#boolean) | Indicates whether the note author is a contributor. |
 | <a id="noteawardemoji"></a>`awardEmoji` | [`AwardEmojiConnection`](#awardemojiconnection) | List of emoji reactions associated with the note. (see [Connections](#connections)) |
 | <a id="notebody"></a>`body` | [`String!`](#string) | Content of the note. |
diff --git a/doc/api/users.md b/doc/api/users.md
index 2908f552a9d..c7282b01285 100644
--- a/doc/api/users.md
+++ b/doc/api/users.md
@@ -2203,9 +2203,9 @@ Example response:
 
 Pre-requisite:
 
-- You must be an administrator.
+- You must be an administrator to view the activity of users with private profiles.
 
-Get the last activity date for all users, sorted from oldest to newest.
+Get the last activity date for users with public profiles, sorted from oldest to newest.
 
 The activities that update the user event timestamps (`last_activity_on` and `current_sign_in_at`) are:
 
@@ -2215,7 +2215,7 @@ The activities that update the user event timestamps (`last_activity_on` and `cu
 - User using the API
 - User using the GraphQL API
 
-By default, it shows the activity for all users in the last 6 months, but this can be
+By default, it shows the activity for users with public profiles in the last 6 months, but this can be
 amended by using the `from` parameter.
 
 ```plaintext
diff --git a/doc/api/vulnerabilities.md b/doc/api/vulnerabilities.md
index 52a92f695bd..e16f9b244a9 100644
--- a/doc/api/vulnerabilities.md
+++ b/doc/api/vulnerabilities.md
@@ -224,7 +224,7 @@ POST /vulnerabilities/:id/revert
 | `id` | integer or string | yes | The ID of a vulnerability to revert to detected state |
 
 ```shell
-curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/vulnerabilities/5/dismiss"
+curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/vulnerabilities/5/revert"
 ```
 
 Example response:
diff --git a/doc/development/cicd/components.md b/doc/development/cicd/components.md
index 916db35e8bd..c2e883b4c87 100644
--- a/doc/development/cicd/components.md
+++ b/doc/development/cicd/components.md
@@ -4,15 +4,15 @@ group: Pipeline Authoring
 info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
 ---
 
-# Development guide for GitLab CI/CD components
+# Development guide for GitLab official CI/CD components
 
-This document explains how to develop [CI/CD components](../../ci/components/index.md) that are maintained by GitLab.
+This document explains how to develop [CI/CD components](../../ci/components/index.md) that are maintained by GitLab, either the official public ones or those for internal use.
 
-The official location for all GitLab-maintained component projects is the [`gitlab.com/components`](https://gitlab.com/components) group.
+The location for all official GitLab component projects is the [`gitlab.com/components`](https://gitlab.com/components) group.
 This group contains all components that are designed to be generic, served to all GitLab users, and maintained by GitLab.
-
+For example: SAST, Secret Detection and Code Quality components.
 A component project can initially be created under a different group (for example `gitlab-org`)
-but they need to be moved into the `components` group before the first version gets published to the catalog.
+but it needs to be moved into the `components` group before the first version gets published to the catalog.
 
 Components that are for GitLab internal use only, for example specific to `gitlab-org/gitlab` project, should be
 implemented under `gitlab-org` group.
@@ -23,7 +23,7 @@ experience with it.
 
 ## Define ownership
 
-GitLab-maintained components are trusted by the community and require a high degree of quality and timely maintenance.
+Official GitLab components are trusted by the community and require a high degree of quality and timely maintenance.
 Components must be kept up to date, monitored for security vulnerabilities, and bugs fixed.
 
 Each component project must have a set of owners and maintainers that are also domain experts.
@@ -40,7 +40,7 @@ they can be contacted by the wider community if needed.
 
 NOTE:
 If a set of project owners cannot be guaranteed or the components cannot be dogfooded, we strongly recommend
-not creating a GitLab-maintained component project and instead let the wider community fulfill the demand
+not creating an official GitLab component project and instead let the wider community fulfill the demand
 in the catalog.
 
 ## Development process
@@ -50,7 +50,6 @@ in the catalog.
 1. Follow the [standard guide for creating components](../../ci/components/index.md).
 1. Add a concise project description that clearly describes the capabilities offered by the component project.
 1. Ensure that the [best practices](../../ci/components/index.md#best-practices) are followed.
-1. Use [semantic versioning](https://semver.org) in the form `MAJOR.MINOR` or `MAJOR.MINOR.PATCH`.
 1. Add a `LICENSE.md` file with the MIT license.
 1. The project must have a `.gitlab-ci.yml` file that:
    - Validates all the components in the project correctly.
@@ -63,9 +62,9 @@ in the catalog.
      - **Variables** (when applicable): The variable names, possible values, and descriptions.
    - **Contribute**: Notes and how to get in touch with the maintainers.
      Usually the contribution process should follow the [official guide](../../ci/components/index.md).
-1. Upload the [official avatar image](img/avatar_component_project.png) to the component project.
+1. For official component projects, upload the [official avatar image](img/avatar_component_project.png) to the component project.
 
-## Review and contribution process
+## Review and contribution process for official components
 
 It's possible that components in the project have a related [CI/CD template](templates.md) in the GitLab codebase.
 In that case we need to cross link the component project and CI/CD template:
@@ -76,5 +75,28 @@ In that case we need to cross link the component project and CI/CD template:
 When changes are applied to these components, check whether we can integrate the changes in the CI/CD template too.
 This might not be possible due to the rigidity of versioning in CI/CD templates.
 
-Ping [`@gitlab-org/maintainers/ci-components`](https://gitlab.com/groups/gitlab-org/maintainers/ci-components/-/group_members?with_inherited_permissions=exclude)
+Ping any of the [maintainers](#default-maintainers-of-gitlab-official-components)
 for reviews to ensure that the components are written in consistent style and follow the best practices.
+
+## Default maintainers of GitLab official components
+
+Each component project under [`gitlab.com/components`](https://gitlab.com/components) group should
+have specific DRIs and maintainers, however the [`@gitlab-org/maintainers/ci-components`](https://gitlab.com/groups/gitlab-org/maintainers/ci-components/-/group_members?with_inherited_permissions=exclude)
+group of maintainers is responsible for managing the `components` group in general.
+
+The responsibilities for this group of maintainers:
+
+- Manage any development and helper resources, such as toolkit components and project templates, to provide the best development experience.
+- Manage any component projects that is missing a clear DRI, or is in the process of being developed, and work to find the right owners long term.
+- Guide and mentor the maintainers of individual component projects, including during code reviews and when troubleshooting issues.
+- Ensure best practices are applied and improved over time.
+
+Requirements for becoming a maintainer:
+
+- Have a an in-depth understanding of the [CI/CD YAML syntax](../../ci/yaml/index.md) and features.
+- Understand how CI components work and demonstrate experience developing them.
+- Have a solid understanding of the components [best practices](../../ci/components/index.md#best-practices).
+
+How to join the `gitlab-components` group of general maintainers:
+
+- Review the [process for becoming a `gitlab-components` maintainer](https://handbook.gitlab.com/handbook/engineering/workflow/code-review/#project-maintainer-process-for-gitlab-components).
diff --git a/doc/update/deprecations.md b/doc/update/deprecations.md
index 7a7cac19740..748556675c0 100644
--- a/doc/update/deprecations.md
+++ b/doc/update/deprecations.md
@@ -402,6 +402,31 @@ To help avoid being impacted by this breaking change, create new access tokens w
 
 <div class="deprecation breaking-change" data-milestone="17.0">
 
+### Dependency Scanning incorrect SBOM metadata properties
+
+<div class="deprecation-notes">
+- Announced in GitLab <span class="milestone">16.9</span>
+- Removal in GitLab <span class="milestone">17.0</span> ([breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change))
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/438779).
+</div>
+
+GitLab 17.0 removes support for the following metadata properties in CycloneDX SBOM reports:
+
+- `gitlab:dependency_scanning:input_file`
+- `gitlab:dependency_scanning:package_manager`
+
+These were added in GitLab 15.7 to the SBOM produced by Dependency Scanning. However, these properties were incorrect and didn't align with the [GitLab CycloneDX property taxonomy](https://docs.gitlab.com/ee/development/sec/cyclonedx_property_taxonomy.html).
+The following correct properties were added in GitLab 15.11 to address this:
+
+- `gitlab:dependency_scanning:input_file:path`
+- `gitlab:dependency_scanning:package_manager:name`
+
+The incorrect properties were kept for backward compatibility. They are now deprecated and will be removed in 17.0.
+
+</div>
+
+<div class="deprecation breaking-change" data-milestone="17.0">
+
 ### Dependency Scanning support for sbt 1.0.X
 
 <div class="deprecation-notes">
@@ -1273,6 +1298,31 @@ automatically from GitLab 16.0 onwards.
 
 <div class="deprecation breaking-change" data-milestone="17.0">
 
+### Support for self-hosted Sentry versions 21.4.1 and earlier
+
+<div class="deprecation-notes">
+- Announced in GitLab <span class="milestone">16.9</span>
+- Removal in GitLab <span class="milestone">17.0</span> ([breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change))
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/435791).
+</div>
+
+Support for self-hosted Sentry versions 21.4.1 and earlier is deprecated and will be removed in GitLab 17.0.
+
+If your self-hosted Sentry version is 21.4.1 or earlier, you may not be able to collect errors from your GitLab instance after upgrading to GitLab 17.0 or later.
+To continue sending errors from your GitLab instance to your Sentry instance, upgrade Sentry to version 21.5.0 or later. For more information,
+see [Sentry documentation](https://develop.sentry.dev/self-hosted/releases/).
+
+NOTE:
+The deprecated support is for
+[GitLab instance error tracking features](https://docs.gitlab.com/omnibus/settings/configuration.html#error-reporting-and-logging-with-sentry)
+for administrators. The deprecated support does not relate to
+[GitLab error tracking](https://docs.gitlab.com/ee/operations/error_tracking.html#sentry-error-tracking) for
+developers' own deployed applications.
+
+</div>
+
+<div class="deprecation breaking-change" data-milestone="17.0">
+
 ### Support for setting custom schema for backup is deprecated
 
 <div class="deprecation-notes">
diff --git a/doc/user/clusters/agent/vulnerabilities.md b/doc/user/clusters/agent/vulnerabilities.md
index 18f46878eb4..a9f7cefff3d 100644
--- a/doc/user/clusters/agent/vulnerabilities.md
+++ b/doc/user/clusters/agent/vulnerabilities.md
@@ -53,6 +53,16 @@ container_scanning:
       - kube-system
 ```
 
+For every target namespace, all images in the following workload resources are scanned:
+
+- Pod
+- ReplicaSet
+- ReplicationController
+- StatefulSet
+- DaemonSet
+- CronJob
+- Job
+
 ### Enable via scan execution policies
 
 To enable scanning of all images within your Kubernetes cluster via scan execution policies, we can use the