Add latest changes from gitlab-org/gitlab@master

20 files changed, 374 insertions, 153 deletions

diff --git a/app/controllers/projects/artifacts_controller.rb b/app/controllers/projects/artifacts_controller.rb
index 85bdeb07b00..c675e4bb61c 100644
--- a/app/controllers/projects/artifacts_controller.rb
+++ b/app/controllers/projects/artifacts_controller.rb
@@ -39,6 +39,8 @@ class Projects::ArtifactsController < Projects::ApplicationController
     return render_404 unless artifact_file
 
     log_artifacts_filesize(artifact_file.model)
+    audit_download(build, artifact_file.filename)
+
     send_upload(artifact_file, attachment: artifact_file.filename, proxy: params[:proxy])
   end
 
@@ -106,6 +108,10 @@ class Projects::ArtifactsController < Projects::ApplicationController
 
   private
 
+  def audit_download(build, filename)
+    # overridden in EE
+  end
+
   def extract_ref_name_and_path
     return unless params[:ref_name_and_path]
 
@@ -184,3 +190,5 @@ class Projects::ArtifactsController < Projects::ApplicationController
     return access_denied! unless can?(current_user, :read_job_artifacts, job_artifact)
   end
 end
+
+Projects::ArtifactsController.prepend_mod
diff --git a/config/feature_flags/beta/vulnerability_report_advanced_filtering.yml b/config/feature_flags/beta/vulnerability_report_advanced_filtering.yml
new file mode 100644
index 00000000000..5a06832b64a
--- /dev/null
+++ b/config/feature_flags/beta/vulnerability_report_advanced_filtering.yml
@@ -0,0 +1,9 @@
+---
+name: vulnerability_report_advanced_filtering
+feature_issue_url: https://gitlab.com/groups/gitlab-org/-/epics/3429
+introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/140984
+rollout_issue_url: https://gitlab.com/gitlab-com/gl-infra/production/-/issues/17353
+milestone: '16.9'
+group: group::threat insights
+type: beta
+default_enabled: false
diff --git a/config/initializers/1_settings.rb b/config/initializers/1_settings.rb
index 7007e6329e7..619263bb8db 100644
--- a/config/initializers/1_settings.rb
+++ b/config/initializers/1_settings.rb
@@ -908,7 +908,7 @@ Gitlab.ee do
     Settings.cron_jobs['click_house_event_authors_consistency_cron_worker']['job_class'] = 'ClickHouse::EventAuthorsConsistencyCronWorker'
     Settings.cron_jobs['click_house_event_namespace_paths_consistency_cron_worker'] ||= {}
     Settings.cron_jobs['click_house_event_namespace_paths_consistency_cron_worker']['cron'] ||= "*/45 * * * *"
-    Settings.cron_jobs['click_house_event_namespace_paths_consistency_cron_worker']['job_class'] = 'ClickHouse::EventNamespacePathsConsistencyCronWorker'
+    Settings.cron_jobs['click_house_event_namespace_paths_consistency_cron_worker']['job_class'] = 'ClickHouse::EventPathsConsistencyCronWorker'
     Settings.cron_jobs['vertex_ai_refresh_access_token_worker'] ||= {}
     Settings.cron_jobs['vertex_ai_refresh_access_token_worker']['cron'] ||= '*/50 * * * *'
     Settings.cron_jobs['vertex_ai_refresh_access_token_worker']['job_class'] = 'Llm::VertexAiAccessTokenRefreshWorker'
diff --git a/doc/administration/audit_event_streaming/audit_event_types.md b/doc/administration/audit_event_streaming/audit_event_types.md
index ff99fc1f6c6..d89b0587e9e 100644
--- a/doc/administration/audit_event_streaming/audit_event_types.md
+++ b/doc/administration/audit_event_streaming/audit_event_types.md
@@ -64,6 +64,12 @@ Audit event types belong to the following product categories.
 | [`update_event_streaming_destination`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/74632) | Event triggered when an external audit event destination is updated| **{check-circle}** Yes | **{check-circle}** Yes | GitLab [14.6](https://gitlab.com/gitlab-org/gitlab/-/issues/344664) |
 | [`update_instance_event_streaming_destination`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/125846) | Event triggered when an instance level external audit event destination is updated| **{check-circle}** Yes | **{check-circle}** Yes | GitLab [16.2](https://gitlab.com/gitlab-org/gitlab/-/issues/404730) |
 
+### Build artifacts
+
+| Name | Description | Saved to database | Streamed | Introduced in |
+|:-----|:------------|:------------------|:---------|:--------------|
+| [`job_artifact_downloaded`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/129608) | Triggered when a user download a job artifact from a project| **{dotted-circle}** No | **{check-circle}** Yes | GitLab [16.8](https://gitlab.com/gitlab-org/gitlab/-/issues/250663) |
+
 ### Code review
 
 | Name | Description | Saved to database | Streamed | Introduced in |
diff --git a/doc/api/instance_level_ci_variables.md b/doc/api/instance_level_ci_variables.md
index 466479e0cdb..ad78b192543 100644
--- a/doc/api/instance_level_ci_variables.md
+++ b/doc/api/instance_level_ci_variables.md
@@ -8,6 +8,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 ## List all instance variables
 
+> `description` parameter [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/418331) in GitLab 16.8.
+
 Get the list of all instance-level variables.
 
 ```plaintext
@@ -43,6 +45,8 @@ curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/a
 
 ## Show instance variable details
 
+> `description` parameter [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/418331) in GitLab 16.8.
+
 Get the details of a specific instance-level variable.
 
 ```plaintext
@@ -71,6 +75,8 @@ curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/a
 
 ## Create instance variable
 
+> `description` parameter [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/418331) in GitLab 16.8.
+
 Create a new instance-level variable.
 
 The [maximum number of instance-level variables](../administration/instance_limits.md#number-of-instance-level-variables) can be changed.
@@ -81,12 +87,13 @@ POST /admin/ci/variables
 
 | Attribute       | Type    | Required | Description |
 |-----------------|---------|----------|-------------|
-| `key`           | string  | Yes      | The `key` of a variable. Maximum of 255 characters, only `A-Z`, `a-z`, `0-9`, and `_` are allowed. |
-| `value`         | string  | Yes      | The `value` of a variable. Maximum of 10,000 characters. |
-| `variable_type` | string  | No       | The type of a variable. Available types are: `env_var` (default) and `file`. |
-| `protected`     | boolean | No       | Whether the variable is protected. |
+| `key`           | string  | Yes      | The `key` of the variable. Maximum of 255 characters, only `A-Z`, `a-z`, `0-9`, and `_` are allowed. |
+| `value`         | string  | Yes      | The `value` of the variable. Maximum of 10,000 characters. |
+| `description`   | string  | No       | The description of the variable. Maximum of 255 characters. |
 | `masked`        | boolean | No       | Whether the variable is masked. |
+| `protected`     | boolean | No       | Whether the variable is protected. |
 | `raw`           | boolean | No       | Whether the variable is expandable. |
+| `variable_type` | string  | No       | The type of the variable. Available types are: `env_var` (default) and `file`. |
 
 ```shell
 curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
@@ -107,6 +114,8 @@ curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
 
 ## Update instance variable
 
+> `description` parameter [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/418331) in GitLab 16.8.
+
 Update an instance-level variable.
 
 ```plaintext
@@ -115,12 +124,13 @@ PUT /admin/ci/variables/:key
 
 | Attribute       | Type    | Required | Description |
 |-----------------|---------|----------|-------------|
-| `key`           | string  | Yes      | The `key` of a variable. Maximum of 255 characters, only `A-Z`, `a-z`, `0-9`, and `_` are allowed. |
-| `value`         | string  | Yes      | The `value` of a variable. Maximum of 10,000 characters. |
-| `variable_type` | string  | No       | The type of a variable. Available types are: `env_var` (default) and `file`. |
-| `protected`     | boolean | No       | Whether the variable is protected. |
+| `description`   | string  | No       | The description of the variable. Maximum of 255 characters. |
+| `key`           | string  | Yes      | The `key` of the variable. Maximum of 255 characters, only `A-Z`, `a-z`, `0-9`, and `_` are allowed. |
 | `masked`        | boolean | No       | Whether the variable is masked. |
+| `protected`     | boolean | No       | Whether the variable is protected. |
 | `raw`           | boolean | No       | Whether the variable is expandable. |
+| `value`         | string  | Yes      | The `value` of the variable. Maximum of 10,000 characters. |
+| `variable_type` | string  | No       | The type of the variable. Available types are: `env_var` (default) and `file`. |
 
 ```shell
 curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" \
diff --git a/doc/development/documentation/styleguide/index.md b/doc/development/documentation/styleguide/index.md
index a18b376a1cc..6442059ebbe 100644
--- a/doc/development/documentation/styleguide/index.md
+++ b/doc/development/documentation/styleguide/index.md
@@ -735,6 +735,10 @@ For example:
 ```
 
 For the footnotes below the table, use the HTML tags `<small>`, `<ol>` and `<li>`.
+
+NOTE:
+To format text in footnotes (for example, to use emphasis or links), you must use HTML rather than Markdown.
+
 For example:
 
 ```html
diff --git a/doc/development/documentation/styleguide/word_list.md b/doc/development/documentation/styleguide/word_list.md
index fed295b8ec9..2160c01247d 100644
--- a/doc/development/documentation/styleguide/word_list.md
+++ b/doc/development/documentation/styleguide/word_list.md
@@ -434,6 +434,12 @@ Use:
 Do not use **currently** when talking about the product or its features. The documentation describes the product as it is today.
 ([Vale](../testing.md#vale) rule: [`CurrentStatus.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/CurrentStatus.yml))
 
+## custom role
+
+Use **custom role** when referring to a role created with specific customized permissions.
+
+When referring to a non-custom role, use [**default role**](#default-role).
+
 ## data
 
 Use **data** as a singular noun.
@@ -448,6 +454,20 @@ Instead of:
 - Data are collected.
 - The data show a performance increase.
 
+## default role
+
+Use **default role** when referring to the following predefined roles that have
+no customized permissions added:
+
+- Guest
+- Reporter
+- Developer
+- Maintainer
+- Owner
+- Minimal Access
+
+Do not use **static role**, **built-in role**, or **predefined role**.
+
 ## delete
 
 Use **delete** when an object is completely deleted. **Delete** is the opposite of **create**.
@@ -1523,6 +1543,8 @@ Use lowercase for **review app**.
 
 Do not use **roles** and [**permissions**](#permissions) interchangeably. Each user is assigned a role. Each role includes a set of permissions.
 
+There are two types of roles: [custom](#custom-role) and [default](#default-role).
+
 Roles are not the same as [**access levels**](#access-level).
 
 ## Root cause analysis
diff --git a/doc/security/responding_to_security_incidents.md b/doc/security/responding_to_security_incidents.md
index 24a9aaa597a..6a7ff884449 100644
--- a/doc/security/responding_to_security_incidents.md
+++ b/doc/security/responding_to_security_incidents.md
@@ -4,60 +4,136 @@ group: Authentication
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Responding to security incidents **(FREE SELF)**
+# Responding to security incidents **(FREE ALL)**
 
-When a security incident occurs, you should follow the processes defined by your organization. However, you might consider some
-additional steps. These suggestions are intended to supplement existing security incident response processes within your organization.
+When a security incident occurs, you should follow the processes defined by your organization. The GitLab SIRT team created this guide:
 
-Administrators can choose to
-[provide public security contact information](../administration/settings/security_contact_information.md)
-to support receiving reports of security issues from security researchers.
+- For administrators and maintainers of self-managed GitLab instances and groups on GitLab.com.
+- To provide additional information and best practices on how to respond to various security incidents related to GitLab services.
+- As a supplement to the processes defined by your organization to handle security incidents. It is **not a replacement**.
 
-## Suspected compromised user account
+Using this guide, you should feel confident in handling security incidents related to GitLab. Where necessary, the guide links to other parts of GitLab documentation.
 
-If you suspect that a user account or bot account has been compromised, consider taking the following steps:
+WARNING:
+Use the suggestions/recommendations mentioned in this guide at your own risk.
+
+## Common breach scenarios
+
+### Credential exposure to public internet **(FREE SELF)**
+
+This scenario refers to security events where sensitive authentication or authorization information has been exposed to the Internet due to misconfigurations or human errors. Such information might include:
+
+- Passwords.
+- Personal access tokens.
+- Project access tokens.
+- Runner tokens.
+- Pipeline trigger tokens.
+- SSH keys.
+
+This scenario might also include the exposure of sensitive information about third-party credentials through GitLab services. The exposure could occur through accidental commits to public GitLab projects or misconfiguration of CI/CD settings. For more information, see:
+
+- [Overview of GitLab tokens](token_overview.md)
+- [GitLab CI/CD variable security](../ci/variables/index.md#cicd-variable-security)
+
+#### Response
+
+Security incidents related to credentials exposure can vary in severity from low to critical, depending on the type of token and its associated permissions. When responding to such incidents, you should:
+
+- Determine the type and scope of the token.
+- Identify the token owner and the relevant team based on the token information.
+- Revoke the token after you have assessed its scope and potential impact. Revoking a production token might cause service interruption while not revoking an admin token, can cause harm, too, so only revoke the token if you are:
+  - Confident in the potential impact.
+  - Following your company's security incident response guidelines.
+- Document the time of credential exposure and the time when you revoked the credentials.
+- Review GitLab audit logs to identify any unauthorized activity associated with the exposed token. Depending on the scope and type of token, search for audit events related to newly created users, tokens, run malicious pipelines,changes to code and changes to project settings.
+
+#### Event types **(PREMIUM SELF)**
+
+- Review the available [audit events](../administration/audit_events.md) for your group or namespace.
+- Adversaries may attempt to create tokens, SSH keys, or user accounts to maintain persistence. Look for [audit events](../administration/audit_event_streaming/audit_event_types.md) related to these activities.
+- Focus on CI-related [audit events](../administration/audit_event_streaming/audit_event_types.md#continuous-integration) to identify any modifications to CI/CD variables.
+- Review [job logs](../administration/job_logs.md) for any pipelines ran by an adversary
+
+### Suspected compromised user account **(FREE SELF)**
+
+#### Response
+
+If you suspect that a user account or bot account has been compromised, you should:
 
 - [Block the user](../administration/moderate_users.md#block-a-user) to mitigate any current risk.
-- [Review the audit events](../administration/audit_events.md) available to you to identify any suspicious account behavior. For
-  example:
-  - Suspicious sign-in events.
-  - Creation or deletion of personal access tokens, project access tokens, and group access tokens.
-  - Creation or deletion of SSH or GPG keys.
-  - Creation, modification, or deletion of two-factor authentication.
-  - Changes to repositories.
-  - Changes to group or project configurations.
-  - Addition or modification of runners.
-  - Addition or modification of webhooks or Git hooks.
-- Reset any credentials the user might have had access to. For example, users with at least the Maintainer role can view protected
-  [CI/CD variables](../ci/variables/index.md) and [runner registration tokens](token_overview.md#runner-registration-tokens-deprecated).
-- [Reset the user's password](reset_user_password.md).
-- Get the user to [enable two factor authentication](../user/profile/account/two_factor_authentication.md) (2FA), and consider [enforcing 2FA at the instance or group level](two_factor_authentication.md)
+- Reset any credentials the user might have had access to. For example, users with at least the Maintainer role can view protected [CI/CD variables](../ci/variables/index.md) and [runner registration tokens](../security/token_overview.md#runner-registration-tokens-deprecated).
+- [Reset the user's password](../security/reset_user_password.md).
+- Get the user to [enable two factor authentication](../user/profile/account/two_factor_authentication.md) (2FA), and consider [enforcing 2FA at the instance or group level](two_factor_authentication.md).
 - After completing an investigation and mitigating impacts, unblock the user.
 
-## Suspected compromised instance **(FREE SELF)**
+#### Event types **(PREMIUM SELF)**
 
-Self-managed GitLab customers and administrators are responsible for:
+Review the [audit events](../administration/audit_events.md) available to you to identify any suspicious account behavior. For example:
 
-- The security of their underlying hosts.
-- Keeping GitLab itself up to date.
+- Suspicious sign-in events.
+- Creation or deletion of personal, project, and group access tokens.
+- Creation or deletion of SSH or GPG keys.
+- Creation, modification, or deletion of two-factor authentication.
+- Changes to repositories.
+- Changes to group or project configurations.
+- Addition or modification of runners.
+- Addition or modification of webhooks or Git hooks.
+- Addition or modification of authorized OAuth applications.
+- Changes to connected SAML identity providers.
+- Changes to email addresses or notifications.
 
-It is important to [regularly update GitLab](../policy/maintenance.md), update your operating system and its software, and harden your
-hosts in accordance with vendor guidance.
+### CI/CD-related security incidents **(FREE ALL)**
 
-If you suspect that your GitLab instance has been compromised, consider taking the following steps:
+CI/CD workflows are an integral part of modern day software development and primarily used by developers and SREs to build, test and deploy code to production. Because these workflows are attached to the production environments, they often require access to sensitive secrets within the CI/CD pipelines. Security incidents related to CI/CD might vary based on your setup, but they can be broadly classified as follows:
 
-- [Review the audit events](../administration/audit_events.md) available to you for suspicious account behavior.
-- [Review all users](../administration/moderate_users.md) (including the Administrative root user), and follow the steps in [Suspected compromised user account](#suspected-compromised-user-account) if necessary.
-- Review the [Credentials Inventory](../administration/credentials_inventory.md), if available to you.
-- Change any sensitive credentials, variables, tokens, and secrets. For example, those located in instance configuration, database,
-  CI/CD pipelines, or elsewhere.
-- Update to the latest version of GitLab and adopt a plan to update after every security patch release.
+- Security incidents related to exposed GitLab CI/CD job tokens.
+- Secrets exposed through misconfigured GitLab CI/CD.
 
-In addition, the suggestions below are common steps taken in incident response plans when servers are compromised by malicious actors.
+#### Response
 
-WARNING:
-Use these suggestions at your own risk.
+##### Exposed GitLab CI/CD job token
+
+When a pipeline job is about to run, GitLab generates a unique token and injects it as the `CI_JOB_TOKEN` [predefined variable](../ci/variables/predefined_variables.md). You can use a GitLab CI/CD job token to authenticate with specific API endpoints. This token has the same permissions to access the API as the user that caused the job to run. The token is valid only while the pipeline job runs. After the job finishes, the token expires and can no longer be used.
+
+Under normal circumstances, the `CI_JOB_TOKEN` is not displayed in the job logs. However, enabling verbose logging in a pipeline, running commands that echo shell environment variables to the console, or failing to properly secure runner infrastructure can expose this data unintentionally. In such instances, you should:
+
+- Check if there are any recent modifications to the source code in the repo. You can check the commit history of the modified file to determine the actor who made the changes. If you suspect suspicious edits, investigate the user activity using the [suspected compromised user account guide](#suspected-compromised-user-account).
+- Any suspicious modification to any code that is called by that file can cause issues and should be investigated and may lead to exposed secrets.
+- Consider rotating the exposed secrets after determining the production impact of revocation.
+- Review [audit logs](../administration/audit_events.md) available to you for any suspicious modifications to user and project settings.
+
+##### Secrets exposed through misconfigured GitLab CI/CD
+
+When secrets stored as CI variables are not [masked](../ci/variables/index.md#mask-a-cicd-variable), they might be exposed in the job logs. For example, echoing environment variables or encountering a verbose error message. Depending on the project visibility, the job logs might be accessible within your company or over the Internet if your project is public. To mitigate this type of security incident, you should:
+
+- Revoke exposed secrets by following the [exposed secrets guide](#credential-exposure-to-public-internet).
+- Consider masking the variables. This will prevent them from being directly reflected within the job logs. However, masking is not full-proof. For example, a masked variable may still be written to an artifact file or sent to a remote system.
+- Consider protecting the variables. This will ensure they are available only in protected branches.
+- Consider disabling public pipelines to prevent public access to job logs and artifacts.
+- Review artifact retention and expiration polices.
+- Follow the CI/CD [jobs token security guide](../ci/jobs/ci_job_token.md#gitlab-cicd-job-token-security) for more information around best practices.
+- Review audit logs for the exposed secrets systems such as CloudTrail logs for AWS or CloudAudit Logs for GCP to determine if any suspicious changes were made at the time of exposure.
+- Review audit logs available to you for any suspicious modifications to user and project settings.
+
+### Suspected compromised instance **(FREE ALL)**
 
+Self-managed GitLab customers and administrators are responsible for:
+
+- The security of their underlying infrastructure.
+- Keeping GitLab itself up to date.
+
+It is important to [regularly update GitLab](../policy/maintenance.md), update your operating system and its software, and harden your hosts in accordance with vendor guidance.
+
+#### Response
+
+If you suspect that your GitLab instance has been compromised, you should:
+
+- Review the [audit events](../administration/audit_events.md) available to you for suspicious account behavior.
+- Review [all users](../administration/moderate_users.md) (including the Administrative root user), and follow the steps in the [suspected compromised user account guide](#suspected-compromised-user-account) if necessary.
+- Review the Credentials Inventory, if available to you.
+- Change any sensitive credentials, variables, tokens, and secrets. For example, those located in instance configuration, database, CI/CD pipelines, or elsewhere.
+- Update to the latest version of GitLab and adopt a plan to update after every security patch release.
+- In addition, the following suggestions are common steps taken in incident response plans when servers are compromised by malicious actors.
 - Save any server state and logs to a write-once location, for later investigation.
 - Look for unrecognized background processes.
 - Check for open ports on the system.
@@ -66,3 +142,44 @@ Use these suggestions at your own risk.
 - Establish network monitoring and network-level controls.
 - Restrict inbound and outbound network access to authorized users and servers only.
 - Ensure all logs are routed to an independent write-only datastore.
+
+#### Event types **(PREMIUM SELF)**
+
+Review [system access audit events](../administration/audit_event_streaming/audit_event_types.md#system-access) to determine any changes related to system settings, user permissions and user login events.
+
+### Misconfigured project or group settings **(ULTIMATE PREMIUM)**
+
+Security incidents can occur as a result of improperly configured project or group settings, potentially leading to unauthorized access to sensitive or proprietary data. These incidents may include but are not limited to:
+
+- Changes in project visibility.
+- Modifications to MR approval settings.
+- Project deletions.
+- Addition of suspicious webhooks to projects.
+- Changes in protected branch settings.
+
+#### Response
+
+If you suspect unauthorized modifications to project settings, consider taking the following steps:
+
+- Begin by reviewing the available [audit events](../administration/audit_events.md) to identify the user responsible for the action.
+- If the user account appears suspicious, follow the steps outlined in the [suspected compromised user account guide](#suspected-compromised-user-account).
+- Consider reverting the settings to their original state by referring to the audit events and consulting the project owners and maintainers for guidance.
+
+#### Event types **(PREMIUM SELF)**
+
+- Audit logs can be filtered based on the `target_type` field. Based on the security incident context, apply a filter to this field to narrow down the scope.
+- Look for specific audit events of [compliance management](../administration/audit_event_streaming/audit_event_types.md#compliance-management) and [audit events of groups and projects](../administration/audit_event_streaming/audit_event_types.md#groups-and-projects).
+
+### Engaging GitLab for assistance with a security incident
+
+Before you ask GitLab for help, search the [GitLab documentation](https://docs.gitlab.com/). You should engage support once you have performed the preliminary investigation on your end and have additional questions or need of assistance. Eligibility for assistance from GitLab Support is [determined by your license](https://about.gitlab.com/support/#gitlab-support-service-levels).
+
+### Security Best Practices
+
+Review the [GitLab Security documentation](index.md) for what suggestions will work best for your environment and needs.
+
+### Detections
+
+GitLab SIRT maintains an active repository of useful detections in the GitLab SIRT public project(`https://gitlab.com/gitlab-com/gl-security/security-operations/gitlab-sirt-public/automated-incident-response/-/tree/main/detections?ref_type=heads`).
+
+The detections in this repository are based on the audit events and in the general Sigma rule format. You can use sigma rule converter to get the rules in your desired format. Please refer to the repo for more information about Sigma format and tools related to it . Make sure you have GitLab audit logs ingested to your SIEM. You should follow the [audit event streaming guide](../administration/audit_event_streaming/index.md) to stream audit events to your desired destination.
diff --git a/doc/tutorials/agile_sprint/index.md b/doc/tutorials/agile_sprint/index.md
index 4c35182269b..da4ae9fef0d 100644
--- a/doc/tutorials/agile_sprint/index.md
+++ b/doc/tutorials/agile_sprint/index.md
@@ -45,7 +45,7 @@ on your issues.
 
 When creating an iteration cadence, you can decide whether to automatically manage the iterations or
 disable the automated scheduling to
-[manually manage the iterations](../../user/group/iterations/index.md#manual-iteration-management).
+[manually manage the iterations](../../user/group/iterations/index.md#create-an-iteration-manually).
 
 Similar to membership, iterations cascade down your group, subgroup, and project hierarchy. If your team has multiple groups and projects, create the iteration cadence in the top-most shared group:
 
diff --git a/doc/user/group/iterations/index.md b/doc/user/group/iterations/index.md
index bfbba8cc0da..90ccf2ae456 100644
--- a/doc/user/group/iterations/index.md
+++ b/doc/user/group/iterations/index.md
@@ -12,8 +12,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/221047) in GitLab 14.6. [Feature flag `group_iterations`](https://gitlab.com/gitlab-org/gitlab/-/issues/221047) removed.
 
 Iterations are a way to track issues over a period of time. This allows teams
-to track velocity and volatility metrics. For tracking over different time periods, you can use iterations [milestones](../../project/milestones/index.md).
-You can create and manage various [iteration cadences](#iteration-cadences).
+to track velocity and volatility metrics. For tracking the same item over multiple concurrent periods, you can use iterations with [milestones](../../project/milestones/index.md).
+Create and manage various [iteration cadences](#iteration-cadences) in a group.
 
 For example, you can use:
 
@@ -53,19 +53,20 @@ To create an iteration cadence:
 1. Select **Plan > Iterations**.
 1. Select **New iteration cadence**.
 1. Enter the title and description of the iteration cadence.
-1. To manually manage the iteration cadence, clear the **Enable automatic scheduling** checkbox and skip the next step.
+
+   To manually manage the iteration cadence, clear the **Enable automatic scheduling** checkbox and skip the next step.
 1. Complete the required fields to use automatic scheduling.
    - Select the automation start date of the iteration cadence. Iterations are scheduled to
      begin on the same day of the week as the day of the week of the start date.
    - From the **Duration** dropdown list, select how many weeks each iteration should last.
    - From the **Upcoming iterations** dropdown list, select how many upcoming iterations should be
      created and maintained by GitLab.
-   - Optional. To move incomplete issues to the next iteration, select **Roll over issues**.
+   - Optional. To move incomplete issues to the next iteration, select the **Enable roll over** checkbox.
      At the end of the current iteration, all open issues are added to the next iteration.
      Issues are moved at midnight in the instance time zone (UTC by default). Administrators can change the instance time zone.
 1. Select **Create cadence**. The cadence list page opens.
 
-If you want to manually manage the created cadence, read [Manual Iteration Management](#manual-iteration-management).
+To manually manage the created cadence, see [Create an iteration manually](#create-an-iteration-manually).
 
 ### View the iterations list
 
@@ -80,54 +81,53 @@ If a project has issue tracking
 [turned off](../../project/settings/project_features_permissions.md#configure-project-features-and-permissions),
 to view the iterations list, enter its URL. To do so, add: `/-/cadences` to your project or group URL.
 For example `https://gitlab.com/gitlab-org/sample-data-templates/sample-gitlab-project/-/cadences`.
-This is tracked in [issue 339009](https://gitlab.com/gitlab-org/gitlab/-/issues/339009).
+[Issue 339009](https://gitlab.com/gitlab-org/gitlab/-/issues/339009) tracks improving this.
 
 ### Edit an iteration cadence
 
 Prerequisites:
 
-- You must have at least the Developer role for a group.
+- You must have at least the Reporter role for a group.
 
 To edit an iteration cadence:
 
 1. On the left sidebar, select **Search or go to** and find your group.
 1. Select **Plan > Iterations**.
-1. Select **Edit iteration cadence**.
-
-When you use automatic scheduling and edit the **Automation start date** field,
-you must set a new start date that doesn't overlap with the existing
-current or past iterations.
-
-Editing **Upcoming iterations** is a non-destructive action.
-If ten upcoming iterations already exist, changing the number under **Upcoming iterations** to `2`
-doesn't delete the eight existing upcoming iterations.
+1. To the right of the cadence you want to edit, select the vertical ellipsis (**{ellipsis_v}**) and
+   then select **Edit cadence**.
+1. Edit the fields.
+   - When you use automatic scheduling and edit the **Automation start date** field,
+     you must set a new start date that doesn't overlap with the existing
+     current or past iterations.
+   - Editing **Upcoming iterations** is a non-destructive action.
+     For example, if ten upcoming iterations already exist, changing the number under **Upcoming iterations** to `2`
+     doesn't delete the eight existing upcoming iterations.
+1. Select **Save changes**.
 
 #### Turn on and off automatic scheduling for an iteration cadence
 
 1. On the left sidebar, select **Search or go to** and find your group.
 1. Select **Plan > Iterations**.
-1. Next to the cadence for which you want to turn on or off automatic scheduling, select the
-   three-dot menu (**{ellipsis_v}**) **> Edit cadence**.
+1. To the right of the cadence for which you want to turn on or off automatic scheduling, select the
+   vertical ellipsis (**{ellipsis_v}**) and then select **Edit cadence**.
 1. Select or clear the **Enable automatic scheduling** checkbox.
 1. If you're turning on automatic scheduling,
-   complete the required fields **Duration**, **Upcoming iterations**, and **Automation start date**.
-
-   For **Automation start date**, you can select any date that doesn't overlap with the existing open iterations.
-   If you have upcoming iterations, the automatic scheduling adjusts them appropriately to fit
-   your chosen duration.
+   complete the required fields **Automation start date**, **Duration**, and **Upcoming iterations**.
+   - For **Automation start date**, you can select any date that doesn't overlap with the existing open iterations.
+     If you have upcoming iterations, the automatic scheduling adjusts them appropriately to fit
+     your chosen duration.
 1. Select **Save changes**.
 
-#### Example of turning on automatic scheduling for a manual iteration cadence
+#### Example: Turn on automatic scheduling for a manual iteration cadence
 
-Suppose it's Friday, April 15, and you have three iteration in a manual iteration cadence:
+Suppose it's Friday, April 15, and you have three iterations in a manual iteration cadence:
 
 - Monday, April 4 - Friday, April 8 (closed)
 - Tuesday, April 12 - Friday, April 15 (ongoing)
 - Tuesday, May 3 - Friday, May 6 (upcoming)
 
-The earliest possible **Automation start date** you can choose
-is Saturday, April 16 in this scenario, because April 15 overlaps with
-the ongoing iteration.
+The earliest possible **Automation start date** you can choose in this scenario
+is Saturday, April 16, because April 15 overlaps with the ongoing iteration.
 
 If you select Monday, April 18 as the automation start date to
 automate scheduling iterations every week up to two upcoming iterations,
@@ -152,50 +152,56 @@ Prerequisites:
 
 - You must have at least the Reporter role for a group.
 
-Deleting an iteration cadence also deletes all iterations within that cadence.
+Deleting an iteration cadence also deletes all iterations in that cadence.
 
 To delete an iteration cadence:
 
 1. On the left sidebar, select **Search or go to** and find your group.
 1. Select **Plan > Iterations**.
-1. Select the three-dot menu (**{ellipsis_v}**) > **Delete cadence** for the cadence you want to delete.
+1. To the right of the cadence you want to delete, select the vertical ellipsis (**{ellipsis_v}**) and then select **Delete cadence**.
 1. Select **Delete cadence**.
 
-## Manual iteration management
-
-If you don't want your iterations to be scheduled by iteration cadences,
-you can also create and manage them manually.
-
-### Create an iteration
+## Create an iteration manually
 
 > [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/343889) the minimum user role from Developer to Reporter in GitLab 15.0.
 
+When an iteration cadence has automatic scheduling enabled, iterations are created on schedule.
+If you disable that option, you can create iterations manually.
+
 Prerequisites:
 
 - You must have at least the Reporter role for a group.
-- [Automatic scheduling must be disabled](#turn-on-and-off-automatic-scheduling-for-an-iteration-cadence) for the iteration cadence.
+- There must be at least one iteration cadence in the group and
+  [automatic scheduling must be disabled](#turn-on-and-off-automatic-scheduling-for-an-iteration-cadence) for the iteration cadence.
 
 To create an iteration:
 
 1. On the left sidebar, select **Search or go to** and find your group.
-1. Select **Plan > Iterations** and select an iteration cadence.
-1. Select **New iteration**.
-1. Enter the title, a description (optional), a start date, and a due date.
+1. Select **Plan > Iterations**.
+1. To the right of the cadence in which you want create an iteration, select the vertical ellipsis
+   (**{ellipsis_v}**) and then select **Add iteration**.
+1. Complete the fields.
 1. Select **Create iteration**. The iteration details page opens.
 
-### Edit an iteration
+## Edit an iteration
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/218277) in GitLab 13.2.
-> - [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/343889) the minimum user role from Developer to Reporter in GitLab 15.0.
+> [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/343889) the minimum user role from Developer to Reporter in GitLab 15.0.
 
 Prerequisites:
 
 - You must have at least the Reporter role for a group.
-- [Automatic scheduling must be disabled](#turn-on-and-off-automatic-scheduling-for-an-iteration-cadence) for the iteration cadence.
 
-To edit an iteration, select the three-dot menu (**{ellipsis_v}**) > **Edit**.
+To edit an iteration:
 
-### Delete an iteration
+1. On the left sidebar, select **Search or go to** and find your group.
+1. Select **Plan > Iterations** and select an iteration cadence.
+1. Select the iteration you want edit. The iteration details page opens.
+1. In the upper-right corner, select the vertical ellipsis (**{ellipsis_v}**) and then select **Edit**.
+1. Edit the fields:
+   - You can edit **Title**, **Start date**, and **Due date** only if [automatic scheduling is disabled](#turn-on-and-off-automatic-scheduling-for-an-iteration-cadence) for the iteration cadence.
+1. Select **Save changes**.
+
+## Delete an iteration
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/292268) in GitLab 14.3.
 > - [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/343889) the minimum user role from Developer to Reporter in GitLab 15.0.
@@ -205,18 +211,15 @@ Prerequisites:
 - You must have at least the Reporter role for a group.
 - [Automatic scheduling must be disabled](#turn-on-and-off-automatic-scheduling-for-an-iteration-cadence) for the iteration cadence.
 
-To delete an iteration, select the three-dot menu (**{ellipsis_v}**) > **Delete**.
-
-### Add an issue to an iteration
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/216158) in GitLab 13.2.
+To delete an iteration:
 
-To learn how to add an issue to an iteration, see the steps in
-[Managing issues](../../project/issues/managing_issues.md#add-an-issue-to-an-iteration).
-
-## View an iteration report
+1. On the left sidebar, select **Search or go to** and find your group.
+1. Select **Plan > Iterations** and select an iteration cadence.
+1. Select the iteration you want edit. The iteration details page opens.
+1. In the upper-right corner, select the vertical ellipsis (**{ellipsis_v}**) and then select **Delete**.
+1. Select **Delete**.
 
-> Viewing iteration reports in projects [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/222763) in GitLab 13.5.
+## Iteration report
 
 You can track the progress of an iteration by reviewing iteration reports.
 An iteration report displays a list of all the issues assigned to an iteration and their status.
@@ -225,25 +228,29 @@ The report also shows a breakdown of total issues in an iteration.
 Open iteration reports show a summary of completed, unstarted, and in-progress issues.
 Closed iteration reports show the total number of issues completed by the due date.
 
-To view an iteration report, go to the iterations list page and select an iteration's period.
+### View an iteration report
+
+To view an iteration report:
+
+1. On the left sidebar, select **Search or go to** and find your group.
+1. Select **Plan > Iterations** and select an iteration cadence.
+1. Select an iteration.
 
 ### Iteration burndown and burnup charts
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/222750) in GitLab 13.6.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/269972) in GitLab 13.7.
-> - Scoped burnup and burndown charts in subgroups and projects [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/326029) in GitLab 14.9.
+> Scoped burnup and burndown charts in subgroups and projects [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/326029) in GitLab 14.9.
 
 The iteration report includes [burndown and burnup charts](../../project/milestones/burndown_and_burnup_charts.md),
-similar to how they appear when viewing a [milestone](../../project/milestones/index.md).
+similar to how they appear when viewing a [milestone](../../project/milestones/index.md):
 
-Burndown charts help track completion progress of total scope, and burnup charts track the daily
-total count and weight of issues added to and completed in a given timebox.
+- Burndown charts help track completion progress of total scope.
+- Burnup charts track the daily total count and weight of issues added to and completed in a given timebox.
 
-#### Iteration charts scoped to subgroups or projects
+#### View iteration charts scoped to subgroups or projects
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/326029) in GitLab 14.9.
 
-You can view burndown and burnup charts for iterations created for a group in any of its
+View burndown and burnup charts for iterations created for a group in any of its
 subgroups or projects.
 When you do this, the charts only count the issues that belong to the subgroup or project.
 
@@ -268,18 +275,19 @@ An iteration report generated for `Project 1` shows only issues that belong to t
 
 ### Group issues by label
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/225500) in GitLab 13.8.
-
-You can group the list of issues by label.
-This can help you view issues that have your team's label,
-and get a more accurate understanding of scope attributable to each label.
+Group the list of issues by label to view issues that belong to your team, and get a more accurate
+understanding of scope attributable to each label.
 
 To group issues by label:
 
 1. On the left sidebar, select **Search or go to** and find your group.
-1. Select **Plan > Iterations**.
-1. In the **Group by** dropdown list, select **Label**.
-1. Select the **Filter by label** dropdown list.
-1. Select the labels you want to group by in the labels dropdown list.
-   You can also search for labels by typing in the search input.
+1. Select **Plan > Iterations** and select an iteration cadence.
+1. Select an iteration.
+1. From the **Group by** dropdown list, select **Label**.
+1. From the **Filter by label** dropdown list, select the labels you want to group by.
 1. Select any area outside the label dropdown list. The page is now grouped by the selected labels.
+
+## Related topics
+
+- [Add an issue to an iteration](../../project/issues/managing_issues.md#add-an-issue-to-an-iteration)
+- [Tutorial: Use GitLab to run an Agile iteration](../../../tutorials/agile_sprint/index.md)
diff --git a/doc/user/project/issues/managing_issues.md b/doc/user/project/issues/managing_issues.md
index b80db3887bf..62d108d3540 100644
--- a/doc/user/project/issues/managing_issues.md
+++ b/doc/user/project/issues/managing_issues.md
@@ -414,15 +414,12 @@ You can use the `/promote_to_incident` [quick action](../quick_actions.md) to pr
 
 ## Add an issue to an iteration **(PREMIUM ALL)**
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/216158) in GitLab 13.2.
-> - Moved to GitLab Premium in 13.9.
-
 To add an issue to an [iteration](../../group/iterations/index.md):
 
 1. On the left sidebar, select **Search or go to** and find your project.
 1. Select **Plan > Issues**, then select your issue to view it.
 1. On the right sidebar, in the **Iteration** section, select **Edit**.
-1. From the dropdown list, select the iteration to associate this issue with.
+1. From the dropdown list, select the iteration to add this issue to.
 1. Select any area outside the dropdown list.
 
 Alternatively, you can use the `/iteration` [quick action](../quick_actions.md#issues-merge-requests-and-epics).
diff --git a/lib/api/ci/helpers/runner.rb b/lib/api/ci/helpers/runner.rb
index 382528c814c..02a0e6bd722 100644
--- a/lib/api/ci/helpers/runner.rb
+++ b/lib/api/ci/helpers/runner.rb
@@ -140,6 +140,10 @@ module API
           # noop: overridden in EE
         end
 
+        def audit_download(build, filename)
+          # noop: overridden in EE
+        end
+
         def check_if_backoff_required!
           return unless Gitlab::Database::Migrations::RunnerBackoff::Communicator.backoff_runner?
 
diff --git a/lib/api/ci/job_artifacts.rb b/lib/api/ci/job_artifacts.rb
index 3788f5bec41..cdc31889408 100644
--- a/lib/api/ci/job_artifacts.rb
+++ b/lib/api/ci/job_artifacts.rb
@@ -14,6 +14,8 @@ module API
         def authorize_download_artifacts!
           authorize_read_builds!
         end
+
+        def audit_download(build, filename); end
       end
 
       params do
@@ -44,7 +46,7 @@ module API
 
           latest_build = user_project.latest_successful_build_for_ref!(params[:job], params[:ref_name])
           authorize_read_job_artifacts!(latest_build)
-
+          audit_download(latest_build, latest_build.artifacts_file.filename)
           present_artifacts_file!(latest_build.artifacts_file)
         end
 
@@ -104,7 +106,7 @@ module API
 
           build = find_build!(params[:job_id])
           authorize_read_job_artifacts!(build)
-
+          audit_download(build, build.artifacts_file&.filename) if build.artifacts_file
           present_artifacts_file!(build.artifacts_file)
         end
 
diff --git a/lib/api/ci/runner.rb b/lib/api/ci/runner.rb
index 585e9f962a3..1ea62e03fba 100644
--- a/lib/api/ci/runner.rb
+++ b/lib/api/ci/runner.rb
@@ -386,6 +386,7 @@ module API
         get '/:id/artifacts', feature_category: :build_artifacts do
           authenticate_job_via_dependent_job!
 
+          audit_download(current_job, current_job.artifacts_file&.filename) if current_job.artifacts_file
           present_artifacts_file!(current_job.artifacts_file, supports_direct_download: params[:direct_download])
         end
       end
diff --git a/locale/gitlab.pot b/locale/gitlab.pot
index e191e928bb0..ba62ccd2a5f 100644
--- a/locale/gitlab.pot
+++ b/locale/gitlab.pot
@@ -35832,6 +35832,12 @@ msgstr ""
 msgid "PipelineSubscriptions|Add new"
 msgstr ""
 
+msgid "PipelineSubscriptions|Add new pipeline subscription"
+msgstr ""
+
+msgid "PipelineSubscriptions|An error occurred while adding a new pipeline subscription."
+msgstr ""
+
 msgid "PipelineSubscriptions|An error occurred while deleting this pipeline subscription."
 msgstr ""
 
@@ -35853,6 +35859,9 @@ msgstr ""
 msgid "PipelineSubscriptions|Subscription for this project will be removed. Do you want to continue?"
 msgstr ""
 
+msgid "PipelineSubscriptions|Subscription successfully added."
+msgstr ""
+
 msgid "PipelineSubscriptions|Subscription successfully deleted."
 msgstr ""
 
@@ -54676,6 +54685,9 @@ msgstr ""
 msgid "Vulnerability|Scanner:"
 msgstr ""
 
+msgid "Vulnerability|Search or filter vulnerabilities..."
+msgstr ""
+
 msgid "Vulnerability|Security Audit"
 msgstr ""
 
diff --git a/qa/Gemfile.lock b/qa/Gemfile.lock
index 831332727a7..456ca113379 100644
--- a/qa/Gemfile.lock
+++ b/qa/Gemfile.lock
@@ -21,7 +21,7 @@ GEM
       i18n (>= 1.6, < 2)
       minitest (>= 5.1)
       tzinfo (~> 2.0)
-    addressable (2.8.1)
+    addressable (2.8.6)
       public_suffix (>= 2.0.2, < 6.0)
     airborne (0.3.7)
       activesupport
@@ -67,15 +67,14 @@ GEM
       chemlab (~> 0.4)
     coderay (1.1.2)
     colorize (0.8.1)
-    concurrent-ruby (1.2.2)
+    concurrent-ruby (1.2.3)
     crass (1.0.6)
     debug_inspector (1.1.0)
     declarative (0.0.20)
     deprecation_toolkit (2.0.4)
       activesupport (>= 5.2)
     diff-lcs (1.3)
-    domain_name (0.5.20190701)
-      unf (>= 0.0.5, < 1.0.0)
+    domain_name (0.6.20240107)
     erubi (1.12.0)
     excon (0.92.4)
     factory_bot (6.3.0)
@@ -88,7 +87,7 @@ GEM
     faraday-net_http (3.0.0)
     faraday-retry (2.2.0)
       faraday (~> 2.0)
-    ffi (1.15.5)
+    ffi (1.16.3)
     ffi-compiler (1.0.1)
       ffi (>= 1.0.0)
       rake
@@ -119,8 +118,8 @@ GEM
     gitlab (4.19.0)
       httparty (~> 0.20)
       terminal-table (>= 1.5.1)
-    gitlab-qa (13.1.0)
-      activesupport (>= 6.1, < 7.1)
+    gitlab-qa (13.2.1)
+      activesupport (>= 6.1, < 7.2)
       gitlab (~> 4.19)
       http (~> 5.0)
       nokogiri (~> 1.10)
@@ -183,7 +182,7 @@ GEM
       mini_mime (>= 1.0.0)
       multi_xml (>= 0.5.2)
     httpclient (2.8.3)
-    i18n (1.12.0)
+    i18n (1.14.1)
       concurrent-ruby (~> 1.0)
     influxdb-client (3.0.0)
     jwt (2.5.0)
@@ -205,9 +204,9 @@ GEM
     mime-types (3.4.1)
       mime-types-data (~> 3.2015)
     mime-types-data (3.2023.0218.1)
-    mini_mime (1.1.0)
-    mini_portile2 (2.8.2)
-    minitest (5.20.0)
+    mini_mime (1.1.5)
+    mini_portile2 (2.8.5)
+    minitest (5.21.1)
     mize (0.4.1)
       protocol (~> 2.0)
     multi_json (1.15.0)
@@ -237,8 +236,8 @@ GEM
     pry-byebug (3.10.1)
       byebug (~> 11.0)
       pry (>= 0.13, < 0.15)
-    public_suffix (5.0.1)
-    racc (1.7.1)
+    public_suffix (5.0.4)
+    racc (1.7.3)
     rack (2.2.3.1)
     rack-test (1.1.0)
       rack (>= 1.0, < 3)
@@ -322,10 +321,7 @@ GEM
     tzinfo (2.0.6)
       concurrent-ruby (~> 1.0)
     uber (0.1.0)
-    unf (0.1.4)
-      unf_ext
-    unf_ext (0.0.8.2)
-    unicode-display_width (2.4.2)
+    unicode-display_width (2.5.0)
     unparser (0.6.5)
       diff-lcs (~> 1.3)
       parser (>= 3.1.0)
diff --git a/qa/qa.rb b/qa/qa.rb
index cfa2c68a3cd..4ccfa571803 100644
--- a/qa/qa.rb
+++ b/qa/qa.rb
@@ -101,3 +101,23 @@ Warning.process do |warning|
 end
 
 Warning.ignore(/already initialized constant Chemlab::Vendor|previous definition of Vendor was here/)
+
+# TODO: Temporary monkeypatch for broadcast logging
+# Remove once activesupport is upgraded to 7.1
+module Gitlab
+  module QA
+    class TestLogger
+      # Combined logger instance
+      #
+      # @param [<Symbol, String>] level
+      # @param [String] source
+      # @return [ActiveSupport::Logger]
+      def self.logger(level: :info, source: 'Gitlab QA', path: 'tmp')
+        console_log = console_logger(level: level, source: source)
+        file_log = file_logger(source: source, path: path)
+
+        console_log.extend(ActiveSupport::Logger.broadcast(file_log))
+      end
+    end
+  end
+end
diff --git a/qa/qa/vendor/github/page/login.rb b/qa/qa/vendor/github/page/login.rb
index ce71fc5f11e..1482ca4b498 100644
--- a/qa/qa/vendor/github/page/login.rb
+++ b/qa/qa/vendor/github/page/login.rb
@@ -15,7 +15,7 @@ module QA
             fill_in 'app_otp', with: current_otp
 
             if has_text?('Two-factor authentication failed', wait: 2)
-              new_otp = OnePassword::CLI.instance.new_otp(otp)
+              new_otp = OnePassword::CLI.instance.new_otp(current_otp)
 
               fill_in 'app_otp', with: new_otp
             end
diff --git a/spec/controllers/projects/artifacts_controller_spec.rb b/spec/controllers/projects/artifacts_controller_spec.rb
index a0548e847a0..78cd32de560 100644
--- a/spec/controllers/projects/artifacts_controller_spec.rb
+++ b/spec/controllers/projects/artifacts_controller_spec.rb
@@ -104,7 +104,8 @@ RSpec.describe Projects::ArtifactsController, feature_category: :build_artifacts
 
         download_artifact
 
-        expect(response.headers['Content-Disposition']).to eq(%(attachment; filename="#{filename}"; filename*=UTF-8''#{filename}))
+        expect(response.headers['Content-Disposition'])
+          .to eq(%(attachment; filename="#{filename}"; filename*=UTF-8''#{filename}))
       end
     end
 
@@ -135,7 +136,8 @@ RSpec.describe Projects::ArtifactsController, feature_category: :build_artifacts
           download_artifact(file_type: 'archive')
 
           expect(response).to have_gitlab_http_status(:ok)
-          expect(response.headers['Content-Disposition']).to eq(%(attachment; filename="#{filename}"; filename*=UTF-8''#{filename}))
+          expect(response.headers['Content-Disposition'])
+            .to eq(%(attachment; filename="#{filename}"; filename*=UTF-8''#{filename}))
         end
       end
     end
@@ -168,7 +170,8 @@ RSpec.describe Projects::ArtifactsController, feature_category: :build_artifacts
 
             download_artifact(file_type: file_type)
 
-            expect(response.headers['Content-Disposition']).to eq(%(attachment; filename="#{filename}"; filename*=UTF-8''#{filename}))
+            expect(response.headers['Content-Disposition'])
+              .to eq(%(attachment; filename="#{filename}"; filename*=UTF-8''#{filename}))
           end
         end
 
@@ -182,7 +185,8 @@ RSpec.describe Projects::ArtifactsController, feature_category: :build_artifacts
           end
 
           it 'sends the codequality report' do
-            expect(Gitlab::ApplicationContext).to receive(:push).with(artifact: an_instance_of(Ci::JobArtifact)).and_call_original
+            expect(Gitlab::ApplicationContext)
+              .to receive(:push).with(artifact: an_instance_of(Ci::JobArtifact)).and_call_original
 
             expect(controller).to receive(:redirect_to).and_call_original
 
@@ -212,7 +216,8 @@ RSpec.describe Projects::ArtifactsController, feature_category: :build_artifacts
             end
 
             it 'redirects to a Google CDN request' do
-              expect(Gitlab::ApplicationContext).to receive(:push).with(artifact: an_instance_of(Ci::JobArtifact)).and_call_original
+              expect(Gitlab::ApplicationContext)
+                .to receive(:push).with(artifact: an_instance_of(Ci::JobArtifact)).and_call_original
               expect(Gitlab::ApplicationContext).to receive(:push).with(artifact_used_cdn: true).and_call_original
 
               download_artifact(file_type: file_type)
diff --git a/spec/lib/api/ci/helpers/runner_spec.rb b/spec/lib/api/ci/helpers/runner_spec.rb
index ee0a58a4e53..2e4551f5eb9 100644
--- a/spec/lib/api/ci/helpers/runner_spec.rb
+++ b/spec/lib/api/ci/helpers/runner_spec.rb
@@ -2,7 +2,7 @@
 
 require 'spec_helper'
 
-RSpec.describe API::Ci::Helpers::Runner do
+RSpec.describe API::Ci::Helpers::Runner, feature_category: :runner do
   let(:helper) do
     Class.new do
       include API::Ci::Helpers::Runner