GitLab.org/GitLab: Release v14.9.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 14.9
Released: 2022-03-22
License: MIT
Release Assets:
[Filter group members by provisioned users](https://docs.gitlab.com/ee/user/group/#filter-a-group) (SaaS only):
> Prior to this release, you could have a mix of provisioned and non-provisioned users in groups, but there is no way to filter by this status to easily locate them. We have now added the ability to filter by the enterprise badge which is available to group owners.
>
> You can now filter by the [Enterprise user](https://docs.gitlab.com/ee/user/group/saml_sso/scim_setup.html#user-access-and-linking-setup) badge, making it easy to allocate the provisioned users in groups and projects with many members.
Authentication and Authorization, User Profile[Artifact sizes are being recalculated](https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html) (SaaS only):
> Because of previous statistics calculations, the total artifact sizes shown in usage quotas might be incorrect. To ensure artifacts sizes are
> reporting accurately, we have added a background script on GitLab.com to automatically recalculate sizes.
>
> You may notice artifact statistics will fluctuate to `0` at times while the script is recalculating. After recalculation, statistics will return
> to normal.
Build Artifacts[Streaming audit events for MR approvals](https://docs.gitlab.com/ee/administration/audit_event_streaming.html#audit-event-streaming-on-merge-request-approval-actions):
> You can now monitor merge request approval activity that happens on the merge requests in your groups and projects. You
> can see which merge requests are being approved and by whom, if you need to refer back to that later.
>
> Because of the volume of data we expect to be generated by these events, they are only
> available as [streaming audit events](https://docs.gitlab.com/ee/administration/audit_event_streaming.html).
Audit Events[Parent-child support for compliance pipelines](https://docs.gitlab.com/ee/user/project/settings/index.html#compliance-pipeline-configuration):
> In GitLab 14.8 (released February 22nd, 2022), we added support for compliance pipelines to use the `trigger:` keyword to initiate a child pipeline. This change will help organizations who choose to organize their jobs with parent-child pipelines.
Compliance Management, Pipeline Authoring[Project Level Time to restore service API](https://docs.gitlab.com/ee/api/dora/metrics.html):
>
> In this release, we added API support for Time to Restore Service. This is the 3rd of the 4 [DORA Metrics](https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html#devops-research-and-assessment-dora-key-metrics). This data helps teams continuously improve in their stability metrics.
Continuous Delivery, Value Stream Management[Link an epic to another epic](https://docs.gitlab.com/ee/user/group/epics/linked_epics.html):
> GitLab now supports linking epics using "related", "blocking," or "blocked" relationships. This feature enables teams to better track and manage epic dependencies across GitLab groups. Effective dependency management is a key component of reducing variability and increasing predictability in value delivery.
Portfolio Management[Dependency Scanning outputs CycloneDX documents](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#cyclonedx-software-bill-of-materials):
> In order to align with a popular Software Bill of Materials (SBOM) industry format standard, Dependency Scanning's gemnasium analyzers will now output a CycloneDX SBOM for each supported lock or build file detected. These CycloneDX SBOMs are named `cyclonedx-Dependency Scanning[Dependency Scanning adds support for Java 17](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#supported-languages-and-package-managers):
> We have added support for Java 17 to Dependency Scanning. Thank you to community contributors [@rpandini_wh](https://gitlab.com/rpandini_wh) and [@gliDom](https://gitlab.com/gliDom) for their assistance. If you are using the latest, or latest major (2), version of the container you do not need to do anything to receive this update. If you have pinned your container to a minor or specific version please update to at least 2.26.0 receive this update.
Dependency Scanning[Integrated security training](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#enable-security-training-for-vulnerabilities):
> GitLab provides a comprehensive set of [security scanning tools](https://docs.gitlab.com/ee/user/application_security/#security-scanning-tools)
> that can identify all manner of security issues. Scanner findings are presented
> in merge requests, pipelines, and in a dedicated Vulnerability Report. When
> available, a recommended solution is given. However, this is not possible for
> all findings. Presenting security findings without guidance on how to fix identified
> problems or explaining the problem’s potential impact can be challenging for
> anyone not familiar with the specific security issue identified. This increases
> the time and friction involved in assessing and ultimately fixing security issues — especially
> in developer workflows.
>
> We’re pleased to announce the launch of our new
> integrated security training functionality. Two new partners are providing the
> training content. GitLab is already where many developers are working, so we
> designed a solution to provide context-aware security training options from
> inside the GitLab experience.
>
> Simply enable security training for your projects, select your preferred content sources, and view the results from a security scan. In the vulnerability finding, you'll find a direct link to the security training that most closely matches the particular security issue, and the specific language or framework in which it was detected. Now developers can spend a few quick minutes reviewing targeted, context-relevant training to address security issues as part of their
> normal development workflow.
Vulnerability Management[UI option to enable Container Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/#enable-container-scanning-through-an-automatic-merge-request):
> GitLab 14.9 now supports Container Scanning on the Security Configuration page. [Security is a team effort](https://about.gitlab.com/direction/secure/#security-is-a-team-effort) and this configuration experience makes it easier for non-CI experts to get started with GitLab Container Scanning. The tool helps a user create a merge request to enable Container Scanning, while leveraging best configuration practices like using the GitLab-managed [`Container-Scanning.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml) template. The Configuration tool can create a new `.gitlab-ci.yml` file if one does not exist, or update existing simple GitLab CI files. You can therefore use the tool with projects that already have GitLab CI set up. To get started, navigate to **Security & Compliance > Configuration** and visit the Container Scanning section.
Container Scanning[Rule mode for scan result policies](https://docs.gitlab.com/ee/user/application_security/policies/#policy-editor):
> With the GitLab 14.9 release, users can now use rule mode to design and edit scan result policies without needing to edit the policy's YAML directly. This new UI editor makes it easier for users who want to create and manage MR approval rules that are triggered when a given threshold of vulnerabilities are detected in the MR.
>
> To get started with this new rule mode, navigate to **Security & Compliance > Policies** and create a new Scan Result policy.
Security Orchestration[Code Search for archived projects that are not indexed by Advanced Search](https://docs.gitlab.com/ee/user/search/#code-search):
> Previously, code from archived projects was not searchable by default if Advanced Search was enabled. Now, code search for archived projects falls back to basic search. For this to work, however, you must either search within the project or first select the project from the search results page.
Global Search[Geo's admin area supports secondary-specific actions when using unified URLs](https://docs.gitlab.com/ee/administration/geo/) (self-managed only):
> When Geo is configured with [a unified URL](https://docs.gitlab.com/ee/administration/geo/secondary_proxy/#set-up-a-unified-url-for-geo-sites), system administrators would not be able to directly access secondary site specific replication details or perform actions in Geo's administrator area. This was only possible when using the IP address of a secondary site directly or by setting up another domain name.
>
> In 14.9, Geo supports viewing replication details and performing actions directly in the admin area without the need for a workaround. This change excludes Projects and Designs, which will be supported in a future iteration.
Geo-replication, Disaster Recovery[Geo accelerates static assets when using a unified URL](https://docs.gitlab.com/ee/administration/geo/) (self-managed only):
> When Geo is configured to use [a unified URL](https://docs.gitlab.com/ee/administration/geo/secondary_proxy/#set-up-a-unified-url-for-geo-sites), secondary sites proxy requests back to the primary site when they can't serve those requests locally.
>
> In this release, static assets such as images are served directly by the secondary sites and are no longer proxied to the primary site. This may result in faster page load times for Geo users in remote locations.
Geo-replication, Disaster Recovery[Searching for issues across groups is now twice as fast](https://docs.gitlab.com/ee/user/search/advanced_search.html):
> It could be slow to search across groups with many projects using Advanced Search. The slowness was caused by a lookup for each project in the group. Groups with many projects would take a long time to return results.
> We now use inheritance, which makes [these searches perform twice as fast](https://gitlab.com/gitlab-org/gitlab/-/issues/335825#note_673548605).
Global Search[New audit events](https://docs.gitlab.com/ee/administration/audit_events.html):
> The GitLab 14.9 release adds support for auditing the following activities:
> - Creating a new merge request approval rule.
> - Deleting a merge request approval rule.
> - Approving a merge request. (Supported as streaming audit events only.)
> - Creating, deleting, or revoking a project or group deploy token.
> - Failed attempts to create a project or group deploy token.
> - Authenticated `git push` or `git pull` commands to a private repository performed over either SSH or HTTPS (Supported as streaming audit events only.)
Audit Events[Users can recover projects pending deletion](https://docs.gitlab.com/ee/user/project/working_with_projects.html#projects-pending-deletion):
> In previous versions of GitLab, only Administrators could see projects that were pending deletion.
>
> With GitLab 14.9, all users can now view the **Pending deletion** tab. Project and group owners can view and recover projects that were accidentally deleted and
> have not yet been permanently removed from disk. This means users can recover their own accidentally deleted projects without needing to direct all recovery
> requests to an Administrator. To see the tab, on the top bar, select **Menu > Projects > Pending deletion**.
Compliance Management[Display total time scatterplot on each value stream stage](https://docs.gitlab.com/ee/user/group/value_stream_analytics/#total-time-chart):
> In value stream analytics for groups, the **Days to completion** chart has been renamed to **Total time**. Instead of using the dropdown to view **Total time** data for a stage, you now select the stage from the top of the page.
Value Stream Management[Add comment when approving/rejecting a deployment](https://docs.gitlab.com/ee/ci/environments/deployment_approvals.html#approve-or-reject-a-deployment):
> In this release, we have introduced an enhancement to deployment approvals. You can now leave an optional comment when reviewing a deployment, providing more context as to why the deployment was approved or rejected. This functionality is also useful for organizations in highly regulated industries that need to audit release events.
Environment Management[Deployment Approval on the Environments page](https://docs.gitlab.com/ee/ci/environments/deployment_approvals.html#approve-or-reject-a-deployment):
> We are excited to introduce the Deployment Approval capability in the GitLab interface. In GitLab 14.8, we introduced the ability to approve deployments via the [API](https://docs.gitlab.com/ee/ci/environments/deployment_approvals.html#using-the-api). Now, deployment approvers can view a pending deployment and approve or reject it conveniently directly in the Environments page. This update continues our work to enable teams to create workflows for approving software to go to production or other protected environments. With this update, we are now upgrading the feature to beta.
Environment Management[Add text and links for incident metric images](https://docs.gitlab.com/ee/operations/incident_management/incidents.html#metrics):
> During an incident, it can be challenging to capture and organize metrics. Starting in this release, users can add links and text to images of incident metrics. This makes it easier to reference metrics throughout the incident.
Incident Management[ARM support for the GitLab agent for Kubernetes](https://docs.gitlab.com/ee/user/clusters/agent/install/)
> The GitLab agent for Kubernetes now supports ARM32 and ARM64 architecture. This is an important step to provide support for cluster connections running on Apple M1 chips or in low powered environments like the Raspberry PI.
[Provision a Kubernetes cluster from GitLab with Terraform](https://docs.gitlab.com/ee/user/clusters/create/index.html):
> GitLab has deep integrations with Kubernetes for deployments and security. However, some users struggle with setting up an initial cluster with GitLab. The UI-based solution for this integration had several shortcomings and the configuration options were very limited.
>
> You can now use an example project and related documentation to help set up a Kubernetes cluster using Terraform as the Infrastructure-as-Code methodology. This solution uses the GitLab agent for Kubernetes as the component that connects GitLab to your cluster. Using this example, you can create your own project and fully customize it for your needs. The example project provisions a cluster to Amazon Elastic Kubernetes Service (EKS) or Google Kubernetes Engine (GKE).
Infrastructure as Code[View GitLab agent for Kubernetes version in the UI](https://docs.gitlab.com/ee/user/clusters/agent/repository.html#view-your-agents):
> If you use the GitLab agent for Kubernetes, you must ensure that the `agentk` version installed in your cluster is compatible with the GitLab version. While the compatibility between the GitLab installation and `agentk` versions [is documented](https://docs.gitlab.com/ee/user/clusters/agent/install/#upgrades-and-version-compatibility), until now it was not very intuitive to figure out compatibility issues. To support you in your upgrades, GitLab now shows the `agentk` version installed on the agent listing page and highlights if an `agentk` upgrade is recommended.
Kubernetes Management[Simplified migration to agent-based connections](https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_tunnel.html#environments-with-both-certificate-based-and-agent-based-connections):
> If you have a certificate-based cluster that's connected with GitLab, you can now use an agent-based connection at the same time. Previously, to migrate from a certificate-based connection to an agent-based setup, you had to complete additional steps, and the process was especially difficult for group and instance-level clusters. By presetting both Kubernetes contexts, migration is largely simplified. You can now select the context provided by the agent, instead of the default context that's provided by the certificate-based connection.
Kubernetes Management[Rate limiting added to Global Search](https://docs.gitlab.com/ee/api/settings.html):
> Some of the processes in Global Search conduct up to 10 queries per search. When there is a sudden rush of searches, this can slow performance and impact other parts of GitLab. To improve the overall stability of GitLab, we have added rate limits for Global Search. These rate limits are automatically enabled and are preset to the [configurations](https://docs.gitlab.com/ee/administration/instance_limits.html#search-rate-limit) used by GitLab.com.
> The new `search_rate_limit` replaces the rate limit for `user_email_lookup_limit`. Consult the [Important notes on upgrading to GitLab 14.9](#upgrade) section for details.
Global Search[GitLab chart improvements](https://docs.gitlab.com/charts) (self-managed only):
> - GitLab [Spamcheck is now available in the GitLab Helm chart](https://gitlab.com/gitlab-org/charts/gitlab/-/merge_requests/2241). Spamcheck started as a GitLab internal project, however, it became clear that the community could benefit from these efforts, and the decision was made to strive towards making much of it public. Spamcheck allows users to [detect, and mitigate the effects of spam](https://about.gitlab.com/blog/2021/08/19/introducing-spamcheck-data-driven-anti-abuse/).
> - GitLab 14.9 introduces the ability to use Prometheus [`ServiceMonitor` or `PodMonitor` objects instead of annotations on each of the GitLab components](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/2525) which expose Prometheus metrics. This change allows the usage of the Prometheus Operator to monitor a GitLab instance without supplemental configuration outside of the GitLab chart. A result of this change is that we now expose metrics on dedicated ports of the Webservice chart, removing access via the primary service port.
Cloud Native Installation[Omnibus improvements](https://docs.gitlab.com/omnibus) (self-managed only):
> - GitLab 14.9 includes [Mattermost 6.4](https://mattermost.com/blog/mattermost-v6-4-is-now-available/), with unlimited playbooks, and multiple Boards enhancements including standard templates, template previews, new archive format with image support, card badges, and GIF support. This version also includes [security updates](https://mattermost.com/security-updates/) and upgrade from earlier versions is recommended.
> - GitLab [Spamcheck is now available in the Omnibus package](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6259). Spamcheck started as a GitLab internal project, however, it became clear that the community could benefit from these efforts, and the decision was made to strive towards making much of it public. Spamcheck allows users to [detect, and mitigate the effects of spam](https://about.gitlab.com/blog/2021/08/19/introducing-spamcheck-data-driven-anti-abuse/).
Omnibus Package[API endpoint to delete project topics](https://docs.gitlab.com/ee/api/topics.html#delete-a-project-topic):
> In a previous release, we added the ability to create and manage project topics that are used to categorize projects and find similar new projects. However, we did not create a way to delete them. In this release, thanks to [Timo Furrer](https://gitlab.com/tuxtimo)'s contribution, we added an API endpoint to delete project topics to make topic management more neat and efficient.
Projects[New API endpoints for keys and tokens](https://docs.gitlab.com/ee/api/users.html):
> GitLab 14.9 delivers new REST API endpoints:
>
> - Return a single SSH key for a specified user. This is useful to enable GitLab SSH keys to be a
> [Terraform-managed resource](https://docs.gitlab.com/ee/user/infrastructure/iac/#the-gitlab-terraform-provider).
> - Return a single project's deploy token by ID. This allows for a simple request to return a deploy token instead of
> returning and sorting through pages deploy tokens with the API.
> - Return a single group access token or project access token.
>
> Thank you [Timo Furrer](https://gitlab.com/tuxtimo) for your contribution!
Authentication and Authorization[API for Security & Compliance menu visibility](https://docs.gitlab.com/ee/api/projects.html#edit-project):
> Previously, the **Security & Compliance** menu could only be enabled or disabled using the GitLab UI.
>
> Thanks to a community contribution, GitLab now provides an API to allow users to enable or disable the **Security & Compliance** menu. To get started, see the
> [API documentation](https://docs.gitlab.com/ee/api/projects.html#edit-project).
Compliance Management[Special characters not permitted in new project names](https://docs.gitlab.com/ee/user/project/working_with_projects.html#create-a-blank-project):
> Project and Group names that have a leading or trailing special character breaks the container registry. As of this release, you can no longer use special characters as the first or last characters of **new** project or group names. You can still use special characters in any other part in the name. This ensures proper functionality within all stages at GitLab, and enhances the experience of our single platform tool.
Projects[Notifications for new PATs and email addresses](https://docs.gitlab.com/ee/user/profile/notifications.html#notification-events):
>
> Users want to be aware when new personal access tokens are created for and new email address are added to their account. In GitLab 14.9,
> a user's primary email address is sent a notification when:
>
> - A new personal access tokens is created for their account.
> - A new email address is added to their account.
>
> This acts as an extra layer of security and can serve as a warning of suspicious activity.
>
> Thank you [Riccardo Padovani](https://gitlab.com/rpadovani) for your contribution!
Authentication and Authorization[Persistent Volumes in Auto DevOps](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/blob/master/assets/auto-deploy-app/README.md):
> Previously, when you [deployed](https://docs.gitlab.com/ee/topics/autodevops/stages.html#auto-deploy) an application via Auto DevOps that requires [Persistent Volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/), you had to create a [custom chart repository](https://docs.gitlab.com/ee/topics/autodevops/customize.html#custom-helm-chart). However, it was cumbersome to host a chart repository on your own due to the maintenance burden. In GitLab 14.9, you can create Persistent Volumes by specifying the `persistence` keyword in the [configuration file](https://docs.gitlab.com/ee/topics/autodevops/customize.html#customize-values-for-helm-chart).
>
> Thank you [Frank Brooks](https://gitlab.com/fcbrooks) for your contribution!
Continuous Delivery[Permanent link to the latest version of a release](https://docs.gitlab.com/ee/user/project/releases/#permanent-link-to-latest-release):
> Prior to this update, to refer to the latest release of a project, users needed to know the exact version number. We have now added a link to the latest [release](https://docs.gitlab.com/ee/user/project/releases/) for a project. This makes it much easier and more efficient to navigate to the latest release.
Build Artifacts, Release Orchestration[New design for the Environments Page](https://docs.gitlab.com/ee/ci/environments/#view-environments-and-deployments):
> Previously, the Environments page enabled you to operate and understand deployments but the design hid some important information and was difficult to read. In GitLab 14.9, we made a comprehensive update to the page so that you can answer key questions about your environments and deployments. Now, you can easily see the status of the latest deployment, the status for various environments, and which commits have been deployed.
Environment Management[Shortcut to open related issue](https://docs.gitlab.com/ee/user/project/issues/create_issues.html#from-another-issue-or-incident):
> When creating a new issue from another issue, an option to mark the two issues as related is selected by default. This handy shortcut enables you to create one or more related issues without having to remember or copy-pasting issue IDs.
>
> Thanks for the contribution [Steve](https://gitlab.com/smokris)!
Team Planning[Review previously merged commits in merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/commits.html#view-merge-request-commits-in-context):
> The best code reviews take into account the broader context and impact of changes, including previously merged commits. But it can be challenging to bring that context into merge requests, so that everyone can discuss how the proposed changes align with older changes.
>
> You can now stack previously merged commits onto the proposed changes in your merge request, to help you and everyone else understand the full context of the changes.
>
> Thanks to [Paulo Vitor Magacho](https://gitlab.com/pvmagacho), [Anwar Sadath](https://gitlab.com/asadath1395) and [Abhishek Kumar](https://gitlab.com/akumar1503) for all working to contribute this!
Code Review[Render pasted Markdown in the wiki WYSIWYG editor](https://docs.gitlab.com/ee/user/project/wiki/#content-editor):
> Markdown content destined for your GitLab wiki is sometimes created outside of GitLab. In the "classic" wiki editor, you can paste valid Markdown with no problem, because you are working with the raw source. The page only renders when you submit the content. In the wiki WYSIWYG editor, however, your clipboard's content might have been pasted in as plain text, forcing you to manually reformat every line to remove Markdown syntax and re-format it using the WYSIWYG tools.
>
> In GitLab 14.9, the Markdown content you paste into the WYSIWYG editor using Command / Control + V is parsed and rendered as rich text. You can still force the content to paste as plain text using Command / Control + Shift + V.
Wiki[Specify variables when running manual jobs via the API](https://docs.gitlab.com/ee/api/jobs.html#run-a-job):
> When running a manual job, it can be useful to input CI/CD variables to overwrite the existing variables, or to add new ones. Previously, the only way to do this, was to do it through the UI. In this release we've added the ability to specify variables when running a job by using the REST API, which will give you more options for automating your CI/CD pipelines.
Pipeline Authoring[Include the same CI/CD template multiple times](https://docs.gitlab.com/ee/ci/yaml/includes.html#use-nested-includes-with-duplicate-includes-entries):
> Previously, trying to have standard CI/CD templates that you reuse in many places was complicated because each template could only be included in a pipeline once. We dropped this limitation in this release, so you can include the same configuration file as many times as you like. This makes your CI/CD configuration more flexible as you can define identical includes in multiple nested configurations, and rest assured that there will be no conflicts or duplication.
Pipeline Authoring[GitLab Runner 14.9](https://docs.gitlab.com/runner):
> We're also releasing GitLab Runner 14.9 today! GitLab Runner is the lightweight, highly-scalable agent that runs your build jobs and sends the results back to a GitLab instance. GitLab Runner works in conjunction with GitLab CI/CD, the open-source continuous integration service included with GitLab.
>
> #### What's new:
>
> - [GitLab Runner Operator for OpenShift: IBM POWER9 architecture ppc64le](https://gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator/-/issues/38)
>
> #### Bug Fixes:
>
> - [GitLab Runner 14.8 breaks artifacts and caches when `FF_USE_FASTZIP` feature flag is set to `true`](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/28903)
> - [GitLab Runner `pwsh` shell runs jobs as the root user on Linux OS](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27751)
> - [Fix misleading error during cache restoration](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6216)
>
> The list of all changes is in the GitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/14-9-stable/CHANGELOG.md).
GitLab Runner[Static Analysis analyzer updates](https://docs.gitlab.com/ee/user/application_security/sast/analyzers):
> GitLab Static Analysis includes [many security analyzers](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) that the GitLab Static Analysis team actively manages, maintains, and updates. The following analyzer updates were published during the 14.9 release milestone. These updates bring additional coverage, bug fixes, and improvements.
>
> - Bandit analyzer updated to version 1.7.4. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/bandit/-/blob/master/CHANGELOG.md#v2124) for details.
> - Brakeman analyzer updated to version 5.2.1. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/brakeman/-/blob/master/CHANGELOG.md#v2230) for details.
> - Add initial Rails 7 support
> - Fix issues with rules
> - Add checks for unsupported Ruby and Rails versions
> - ESLint analyzer updated to version 7.29.3 of `eslint-plugin-react` and new versions of various dependencies. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/eslint/-/blob/master/CHANGELOG.md#v2251) for details.
> - Add, fix, and update various rules
> - Kics analyzer updated to version 1.5.3. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/kics/-/blob/main/CHANGELOG.md#v140) for details.
> - Fix various rules
> - Improve IAM Policy evaluation
> - Expand coverage of privileged-container Kubernetes rule
> - MobSF analyzer updated to version 3.5.0. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/mobsf/-/blob/master/CHANGELOG.md#v2151) for details.
> - Reduce severity of some existing rules
> - PMD analyzer updated to version 6.43.0. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/pmd-apex/-/blob/master/CHANGELOG.md#v21213) for details.
> - Secrets analyzer updated. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/blob/master/CHANGELOG.md#v3254) for details.
> - Fix issues with invalid commit ranges and merge commits
> - Fix rule for [GitLab Personal Access Tokens](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html)
> - Add detection rule for [GitLab Runner Registration Tokens](https://docs.gitlab.com/runner/register/#requirements)
> - Semgrep analyzer updated to version 0.84.0. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/blob/main/CHANGELOG.md#v2190) for details.
> - Improve handling of global constants and Go raw string literals
> - SpotBugs analyzer updated to version 4.6.0. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs/-/blob/master/CHANGELOG.md#v2302) for details.
>
> If you [include the GitLab-managed SAST template](https://docs.gitlab.com/ee/user/application_security/sast/#configure-sast-in-your-cicd-yaml) ([`SAST.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml)), you don't need to do anything to receive these updates. However, if you override or customize your own CI/CD template, you need to update your CI/CD configurations. To remain on a specific version of any analyzer, you can [pin to a minor version of an analyzer](https://docs.gitlab.com/ee/user/application_security/sast/#pinning-to-minor-image-version). Pinning to a previous version prevents you from receiving automatic analyzer updates and requires you to manually bump your analyzer version in your CI/CD template.
SAST, Secret Detection