GitLab.org/GitLab: Release v15.10.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 15.10
Released: 2023-03-22
License: MIT
Release Assets:
##### [Create](https://about.gitlab.com/stages-devops-lifecycle/create/)
[See all branch-related settings together](https://docs.gitlab.com/ee/user/project/repository/branches/) (SaaS only):
> All branch-related protections now display on a single page. To see a unified list of your branches and all their protection methods, go to **Settings > Repository > Branch rules**. Each branch shows the merge request approvals, security approvals, protected branches, and status checks configured for it. Previously, these settings were grouped by type, making it tough to see a holistic view of a specific branch's protections.
>
> We hope this change helps you discover, use, and monitor these settings more easily. We'd love your feedback [in issue #388149](https://gitlab.com/gitlab-org/gitlab/-/issues/388149).
Source Code Management[Suggested Reviewers generally available](https://docs.gitlab.com/ee/user/project/merge_requests/reviews/#suggested-reviewers) (SaaS only):
> Since release in closed beta, Suggested Reviewers has been enabled in over 1,000 projects and suggested over 200,000 reviewers. We've also made the service more reliable and are now making it generally available to all Ultimate customers.
>
> Deciding the right person to [review your merge request](https://docs.gitlab.com/ee/user/project/merge_requests/reviews/) isn't always straightforward or obvious. Choosing the wrong reviewer can cause delays, low quality reviews, back and forth reassigning reviewers, or even no review at all.
>
> Now, GitLab can recommend a reviewer with [Suggested Reviewers](https://docs.gitlab.com/ee/user/project/merge_requests/reviews/#suggested-reviewers). Using the changes in a merge request and a project's contribution graph, machine learning powered suggestions appear in the [reviewer dropdown](https://docs.gitlab.com/ee/user/project/merge_requests/) in the merge request sidebar. Suggested Reviewers is our first—[of many](/blog/2023/03/16/what-the-ml-ai/)—fully available ML feature at GitLab.
Workflow Automation[Extend DORA GraphQL API to support multiple metrics](https://docs.gitlab.com/ee/api/graphql/reference/index.html#dorametric):
> Previously, the GraphQL API supported only one metric per request. Now, it supports multiple DORA metrics in the same request. This change improves performance when querying DORA metrics data.
>
> Gitlab's [DORA metrics](https://docs.gitlab.com/ee/user/analytics/dora_metrics.html) help executives who are investing in DevOps transformation to understand the ROI on processes they are implementing and tools they have purchased. The teams can use the changes in these metrics as KPIs.
DORA Metrics[Configurable depth for Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#configuring-dependency-scanning):
> GitLab Dependency Scanning now supports a new `DS_MAX_DEPTH` variable to allow users to scan their entire repository for lock files. This variable defaults to only scanning up to two directories deep by default; however, users can set the variable to a larger number or to a value of `-1` to scan their entire repository.
Dependency Scanning[Self-managed support for the new License Compliance scanner](https://docs.gitlab.com/ee/user/compliance/license_scanning_of_cyclonedx_files/):
> The new method of License Compliance scanning is now fully supported for self-managed GitLab instances, including [instances that are running in an offline environment](https://docs.gitlab.com/ee/topics/offline/quick_start_guide.html#enabling-the-package-metadata-database). This feature is behind two feature flags that are disabled by default. To try this feature, enable the `license_scanning_sbom_scanner` and `package_metadata_synchronization` feature flags, and replace the `Jobs/License-Scanning.gitlab-ci.yml` template in your CI configuration with the `Jobs/Dependency-Scanning.gitlab-ci.yml` template. In GitLab 16.0 and later, the old method of scanning with the `Jobs/License-Scanning.gitlab-ci.yml` template will no longer be supported.
License Compliance[Automatically resolve SAST findings when rules are disabled](https://docs.gitlab.com/ee/user/application_security/sast/#automatic-vulnerability-resolution):
> GitLab SAST now automatically [resolves](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-status-values) vulnerabilities from the [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep)- and [KICS](https://gitlab.com/gitlab-org/security-products/analyzers/kics)-based analyzers when either:
>
> - You [disable a predefined rule](https://docs.gitlab.com/ee/user/application_security/sast/customize_rulesets.html#disable-predefined-rules).
> - We remove a rule from the default ruleset.
>
> This change helps you focus on the vulnerabilities that are still relevant after the rule update.
> Previously, when a rule was no longer scanned, its findings would be marked ["No longer detected"](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/#activity-filter) but you still had to take action to resolve them.
> Now, the Vulnerability Management system automatically resolves those findings and leaves a comment explaining that the rule was removed, so you still have a historical record of the vulnerability.
>
> This change will automatically resolve findings from a small number of rules that we've replaced or removed in recent releases.
> In this release, we've also [removed a JavaScript SAST rule](https://gitlab.com/gitlab-org/gitlab/-/issues/373920) that created too many false-positive results.
>
> This feature is enabled by default on GitLab.com and in GitLab 15.10.
> On GitLab.com, [contact Support](/support/) if you need to disable the flag for your project.
> On GitLab self-managed, you can [disable the project-level feature flag](https://docs.gitlab.com/ee/administration/feature_flags.html) named `sec_mark_dropped_findings_as_resolved`.
SAST[Compliance frameworks report](https://docs.gitlab.com/ee/user/compliance/compliance_report/#compliance-frameworks-report):
> Previous versions of GitLab provided a compliance report that shows compliance violations.
>
> In GitLab 15.10, we've added a compliance framework report so can you see at a glance which compliance frameworks have been applied to the projects in your group.
Compliance Management[Enforce IaC Scanning with Scan Execution Policies (SEPs)](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html):
> Users can now require SAST IaC scans to run on a regular schedule or as part of project CI pipelines, independent of the `.gitlab-ci.yml` file’s contents. This allows security teams to manage these scan requirements separately, without allowing developers to change the configuration. You can get started by creating a scan execution policy on the **Security & Compliance > Policies** page.
SAST, Security Policy Management[Revoked and created agent access tokens trigger audit events](https://docs.gitlab.com/ee/administration/audit_events.html#gitlab-agent-for-kubernetes-events):
> The GitLab agent for Kubernetes manages access with agent access tokens. Because they can be used to update your cluster from GitLab, you should regularly rotate your agent tokens. GitLab now triggers audit events when the agent access tokens are created or revoked to support your security and compliance requirements.
Audit Events, Kubernetes Management[New language filter for code search results](https://docs.gitlab.com/ee/user/search/#filter-code-search-results-by-language):
> You can now filter code search results by one or more languages. The new filter uses Elasticsearch aggregations to help you narrow down the results to specific programming languages. To use this feature, [Advanced Search must be enabled](https://docs.gitlab.com/ee/user/search/advanced_search.html#enable-advanced-search).
Global Search[SAML group lock](https://docs.gitlab.com/ee/user/group/saml_sso/group_sync.html#global-saml-group-memberships-lock) (self-managed only):
> SAML group lock allows GitLab administrators to prevent additional members being added to groups that are controlled by SAML group links. Previously, if SSO enforcement was enabled, a group Owner could add a non-group user to their group if that user has signed in using SSO. If SSO enforcement was not enabled, a group Owner could add any non-group user to their group. Now, if SAML group lock is enabled, users can only be added using SAML group links.
User Management[Improved onboarding experience for SAML/SCIM provisioned users](https://docs.gitlab.com/ee/integration/saml.html):
> When users are provisioned with SAML or SCIM, the link in their email confirmation now directs them to sign in through their identity provider. Previously, users were directed to the GitLab sign-in page, which was potentially confusing.
User Management[Groups for OpenID Connect](https://docs.gitlab.com/ee/administration/auth/oidc.html#configure-users-based-on-oidc-group-membership) (self-managed only):
> The OpenID Connect (OIDC) OmniAuth provider for authentication in GitLab now supports group claims for administrator, external, and required groups. This is consistent with our SAML implementation, and administrators can use OIDC and group claims to manage upstream user access to GitLab.
User Management[Geo now verifies replicated Container Registries](https://docs.gitlab.com/ee/administration/geo/replication/datatypes.html) (self-managed only):
> With this release, Geo now automatically verifies the data integrity of a replicated [Container Registry](https://docs.gitlab.com/ee/user/packages/container_registry/). This ensures that container images are not corrupted in transfer or at rest. If Geo is used as part of a disaster recovery strategy, this protects you against data loss.
Geo-replication, Disaster Recovery[Report abuse from users' comments in epics](https://docs.gitlab.com/ee/user/report_abuse.html#report-abuse-from-a-users-comment):
> You can report abuse from other GitLab users to GitLab administrators. Previously, you could report specific comments, for example, in issues and merge requests.
> Now you can also report comments in epics.
Portfolio Management[New pairing rule for custom stages in Value Stream Analytics](https://docs.gitlab.com/ee/user/group/value_stream_analytics/#create-a-value-stream-with-custom-stages):
> To improve the tracking of development workflows in Value Stream Analytics, we added a new pairing rule for customizable stages between MR label events and MR merged events. This rule makes it possible to create a custom stage that, for example, measures the time from when an MR was labeled as `workflow::in review` to when it was merged.
Value Stream Management[Define default owners for `CODEOWNERS` sections](https://docs.gitlab.com/ee/user/project/codeowners/#set-default-owner-for-a-section):
> Define a default code owner for each section of your `CODEOWNERS` file. This default
> now applies to files and directories referenced in the section. This way you don't
> have to repeat the same owners over and over. Individual files and directories can
> still be overridden.
>
> In this example, all files and directories are owned by `@dev-team`, except `README.md`
> and the `data-models/` directory.
Source Code Management[Add a merge request to the Merge Train using API](https://docs.gitlab.com/ee/api/merge_trains.html#add-a-merge-request-to-a-merge-train):
> Merge Trains allow you to sequence merge requests (MRs) and verify their changes work together before they are merged to the target branch. Previously, to add an MR to a merge train, you had to click a button on the MR's page in the GitLab UI. This method did not support CI/CD automation or other flows that some organizations might want to implement.
>
> Now you can add a merge request to a merge train by using the merge trains API, enabling more control through automation.
Merge Trains[Apple App Store integration](https://docs.gitlab.com/ee/user/project/integrations/apple_app_store.html):
> From GitLab 15.10, you can configure and validate your projects with Apple App Store credentials. You can then use those credentials in CI/CD pipelines to automate releases to Test Flight and the App Store.
>
> To record your experiences with the App Store integration, see this [feedback issue](https://gitlab.com/gitlab-org/incubation-engineering/mobile-devops/feedback/-/issues/10).
Continuous Delivery[Learn to configure Flux for GitLab](https://docs.gitlab.com/ee/user/clusters/agent/gitops/flux_tutorial.html):
> In February 2023, GitLab announced plans to [integrate Flux with the agent for Kubernetes for GitOps](https://about.gitlab.com/blog/2023/02/08/why-did-we-choose-to-integrate-fluxcd-with-gitlab/). To help you get started, we added a tutorial to configure Flux with GitLab for production.
Kubernetes Management[Use a dedicated subdomain for KAS address](https://docs.gitlab.com/ee/administration/clusters/kas.html):
> Omnibus installations of GitLab run the Kubernetes Agent Server (KAS) on the main GitLab domain. To stay consistent with the GitLab chart installation method, you can now serve KAS to Omnibus installations on a dedicated subdomain.
>
> The KAS address `/-/kubernetes-agent` on the main GitLab domain remains the default setting.
Kubernetes Management[Improved workflow for editing projects in the Admin Area](https://docs.gitlab.com/ee/administration/admin_area.html#administering-projects) (self-managed only):
> When editing a project in the Admin Area, users are currently redirected to the project settings page of the respective project.
> This redirect requires several clicks to return to the original list of of projects, thus making it cumbersome for an administrator who tries to edit multiple projects.
>
> To improve this workflow, a new project edit page is introduced that allows administrators to stay in the Admin Area when editing a project, and to return to the project list with just one click.
>
> Thank you [Markus Ferrel](https://gitlab.com/markus.ferrell) for your contribution!
Projects[Find users more quickly with Advanced Search](https://docs.gitlab.com/ee/user/search/advanced_search.html#refining-user-search):
> You can now search for users by using [Advanced Search](https://docs.gitlab.com/ee/user/search/advanced_search.html). This new functionality not only improves the performance of searching for users, but also gives the ability to [refine the search](https://docs.gitlab.com/ee/user/search/advanced_search.html#refining-user-search) by using [Advanced Search syntax](https://docs.gitlab.com/ee/user/search/advanced_search.html#syntax).
Global Search[API support for project user management](https://docs.gitlab.com/ee/api/graphql/reference/#mutationprojectmemberbulkupdate):
> Users with the Owner or Maintainer role for a project can now use the GraphQL API to change the maximum access level of non-inherited users of a project. This release brings more administrative features to users with the Owner or Maintainer role for projects on GitLab.com, and lays the foundation for future administrative bulk actions.
User Management, Projects[Duo supported as a 2FA method](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html#enable-one-time-password-using-duo):
> Duo time-based one-time password (TOTP) is now supported as a two-factor authentication (2FA) method when signing into GitLab.
>
> Thank you [Jamie Murphy](https://gitlab.com/ITJamie) for your contribution!
System Access[Automatic disabling of failing group webhooks](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#failing-webhooks):
> To protect GitLab and users across the system from any potential abuse or misuse, we've implemented a feature to disable group webhooks that fail consistently.
>
> - Group webhooks that return response codes in the `5xx` range are understood to be failing intermittently and are temporarily disabled. These webhooks are initially disabled for 1 minute, which is extended on each retry up to a maximum of 24 hours.
> - Group webhooks that fail with `4xx` errors are permanently disabled.
>
> Users with the Owner or Maintainer role are alerted in the app to investigate and re-enable any failed group webhooks.
>
> By default, this feature is enabled on GitLab.com and disabled on self-managed GitLab. To enable automated disabling of failed webhooks for project or group webhooks, administrators of self-managed instances must enable the `auto_disabling_web_hooks` [feature flag](https://docs.gitlab.com/ee/administration/feature_flags.html).
Integrations[Generate a new OAuth client secret](https://docs.gitlab.com/ee/integration/oauth_provider.html):
> If you have an existing OAuth application, you can now select **Renew secret** to generate a new client secret. This improves application security by providing an easy way to get a new secret.
>
> Thank you [nobody](https://gitlab.com/kyrie.31415926535) for your contribution!
System Access[Explore projects, groups, snippets, and topics](https://docs.gitlab.com/ee/user/project/working_with_projects.html#view-projects):
> This release includes a new section dedicated to browsing and discovering various content within GitLab. This new section, called **Explore**, helps you view and search across different content types. Previously, it was difficult to switch between types while searching for content.
>
> Also with this change, the **Topics** section is elevated to the **Explore** section. This change should better accommodate the feature and its discoverability. This change helps promote open source while helping you find content related to topics you are interested in.
Navigation & Settings[Direct transfer migration on GitLab self-managed no longer requires feature flag](https://docs.gitlab.com/ee/user/group/import/#migrate-groups-by-direct-transfer-recommended) (self-managed only):
> The [open beta release of migrating GitLab projects](https://about.gitlab.com/blog/2023/01/18/try-out-new-way-to-migrate-projects/) with
> top-level groups by direct transfer meant GitLab self-managed users gained access to the beta feature. However, instance administrators had
> to enable both:
>
> - An application setting for migrating groups.
> - The `bulk_import_projects` feature flag for migrating projects in the groups.
>
> In this release, we have removed the feature flag so you only need the [application setting](https://docs.gitlab.com/ee/administration/settings/visibility_and_access_controls.html#enable-migration-of-groups-and-projects-by-direct-transfer).
>
> This change also enables GitLab Dedicated instances to take advantage of the feature.
Importers[Default syntax highlighting theme for new users](https://docs.gitlab.com/ee/user/profile/preferences.html#syntax-highlighting-theme):
> Set the syntax highlighting theme shown to new users, or users who are viewing code but not signed in. Previously, the default only applied to signed-in users, causing signed-out users to sometimes see a visual clash between dark and light theme highlighting.
>
> Thank you [Colin Berry](https://github.com/colin969) for your contribution!
System Access[Import GitHub repository collaborators as GitLab project members](https://docs.gitlab.com/ee/user/project/import/github.html#collaborators-members):
> Until now, imported GitHub projects didn't have their collaborators imported with them. This meant that no users had any
> permissions on these projects. As a workaround, group owners would add members before the import.
>
> Now, if a collaborator's role can be mapped to a GitLab role, GitLab adds the GitHub collaborator to the imported project as a GitLab project member.
Importers[Improved security through filtering outbound requests](https://docs.gitlab.com/ee/security/webhooks.html#filter-requests) (self-managed only):
> To protect against the risk of data loss and exposure, GitLab administrators can now use outbound request filtering controls to safely manage their instances. With this setting, you can block all requests and define accepted IP addresses and domains in an allowlist to establish secure routes for outbound traffic.
Integrations[Use WebAuthn for two-factor authentication without a one-time password](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html#set-up-a-webauthn-device):
> Previously, you had to use a time-based one-time password (TOTP) before you could add a WebAuthn device as a two-factor authentication (2FA) method on your GitLab account. Now, you can add a WebAuthn device as your 2FA method without having to use a TOTP. You must download recovery codes when adding a WebAuthn device as your 2FA method so you can recover access to your account if you are locked out.
System Access[Name shown in sign-in notification emails](https://docs.gitlab.com/ee/user/profile/notifications.html#notifications-for-unknown-sign-ins):
> GitLab sends a notification email when your account is signed into from an unknown location. Previously, this email did not include name information, making it difficult to tell which account the notification was associated with. This notification email now includes both the user's full name and username.
>
> Thank you [Anatoly Ubiyko](https://gitlab.com/aubiyko) for your contribution!
User Management[Improved import error messages that include subrelation errors](https://docs.gitlab.com/ee/user/group/import/#group-import-history):
> When migrating GitLab groups and projects, errors listed as import failures on the group **Import history** page were not always informative enough.
>
> We now include errors from all nested subrelations to make it clear why a relation (for example, a merge request), failed to import. Better error
> messages support debugging and speed up resolution time.
Importers[GitLab chart improvements](https://docs.gitlab.com/charts/) (self-managed only):
> - GitLab 15.10 adds the ability to [use Azure blob storage with the backup-utility](https://docs.gitlab.com/charts/backup-restore/#backups-to-azure-blob-storage). This is immensely beneficial if you're using Azure and want to take advantage of our backup tooling.
> - GitLab 15.10 introduces a new certificates container `certificates` built off of `gitlab-base`. Previously, they were built on top of Alpine Linux and named `alpine-certificates`.
> - GitLab 15.10 also introduces smaller [images for Cloud Native UBI8](https://docs.gitlab.com/charts/advanced/ubi/#configure-the-gitlab-chart-with-ubi-based-images). These images have been made smaller by [adopting UBI Minimal](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/4117) allowing for more rapid deployments. This is part of a larger initiative to reduce the number and severity of vulnerabilities across GitLab container images.
Cloud Native Installation[Omnibus improvements](https://docs.gitlab.com/omnibus/) (self-managed only):
> - GitLab 15.10 includes [Mattermost 7.8](https://mattermost.com/blog/mattermost-v7-8-is-now-available/) with updates to Boards filters and groups, and more. This version also includes [security updates](https://mattermost.com/security-updates/) and upgrading from earlier versions is recommended. For more information, [read the upgrade notes](https://docs.gitlab.com/ee/integration/mattermost/#upgrading-gitlab-mattermost-to-1510).
> - In GitLab 15.10, we also introduce new public [version manifests](https://gitlab-org.gitlab.io/omnibus-gitlab/gitlab-manifests/manifests.html) for Omnibus GitLab. The version manifest file shows the top level software versions, and importantly, where those versions can be fetched from. These files may need to be readily available for different cloud-deploy requirements, so now our release pipelines will generate a public manifest version.
Omnibus Package[Create diagrams in wikis by using the diagrams.net editor](https://docs.gitlab.com/ee/user/markdown.html#diagramsnet-editor):
> With GitLab 15.10, you can more easily create and edit diagrams in wikis by using the diagrams.net GUI editor. This feature is available in the Markdown editor and the content editor, and was implemented in close collaboration with the GitLab wider community.
Wiki[View system notes and add comments on tasks](https://docs.gitlab.com/ee/user/tasks.html#view-task-system-notes):
> Before this release, there was no way to see a detailed change log for a task or have discussions directly with team members. Tasks now show system notes and support collaborating with comments and threads.
Team Planning[Discover commits by their tag in commits list view](https://docs.gitlab.com/ee/user/project/repository/tags/index.html#view-tagged-commits-in-the-commits-list):
> Identifying commits that have been tagged just got simpler. View the commits list at **Repository > Commits** to see commits with their tags attached. This view helps you understand what commits have been added since a tagged release commit.
Source Code Management[Create and switch branches in the Web IDE Beta](https://docs.gitlab.com/ee/user/project/web_ide_beta/#switch-branches):
> When you open the Web IDE Beta from a repository or merge request, the currently selected branch is used by default. You can create a new branch with your changes or, if you're not on a protected branch, commit to the current branch. Starting with GitLab 15.10, you can now also create a new branch any time while making changes or switch branches in the Web IDE Beta. This way, you can boost your productivity by not having to close the Web IDE Beta to switch contexts.
Web IDE[GitLab CLI v1.26.0 released](https://docs.gitlab.com/ee/integration/glab/):
> The v1.26.0 release of the GitLab CLI brings two great new features for working with GitLab CI/CD:
>
> - [Sebastian Gumprich](https://gitlab.com/rndmh3ro) contributed the ability to [run pipeline schedules](https://gitlab.com/gitlab-org/cli/-/issues/1237).
> - [madflow](https://gitlab.com/madflow) contributed an [export function for CI/CD variables](https://gitlab.com/gitlab-org/cli/-/issues/1218) in both projects and groups.
>
> There are also many improvements to existing commands, and documentation improvements to help both SaaS and self-managed users to get started. For a full list of changes, see [the release notes](https://gitlab.com/gitlab-org/cli/-/releases/v1.26.0).
>
> Thank you Sebastian and madflow for your contributions!
GitLab CLI[GitLab Runner 15.10](https://docs.gitlab.com/runner):
> We’re also releasing GitLab Runner 15.10 today! GitLab Runner is the lightweight, highly-scalable agent that runs your CI/CD 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:
>
> - [Support `activeDeadlineSeconds` on Kubernetes pods](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29279)
> - [Add support for a custom Kubernetes PodSpec](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/3114)
> - [ARM64 images of `gitlab-runner-helper-ocp`](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29677)
>
> #### Bug Fixes:
>
> - [In GitLab Runner 15.9, runners overwrite `config.toml` file on startup](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29636)
>
> The list of all changes is in the GitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/15-10-stable/CHANGELOG.md).
GitLab Runner Core[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 15.10 release milestone. These updates bring additional coverage, bug fixes, and improvements.
>
> - KICS-based analyzer updated to version 1.6.11. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/kics/-/blob/main/CHANGELOG.md#v378) for further details. This version includes new rules, bug fixes, and improvements.
> - PMD Apex-based analyzer updated to version 6.54.0. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/pmd-apex/-/blob/master/CHANGELOG.md#v333) for further details.
> - Secrets analyzer updated with new rules. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/blob/master/CHANGELOG.md#v4510) for further details. New rules include:
> - Sendinblue SMTP tokens, thanks to a community contribution from [`@ohemelaar`](https://gitlab.com/ohemelaar).
> - Google Cloud Platform API keys.
> - GitLab Runner Authentication Tokens.
> - Semgrep-based analyzer updated to refine a Go rule and improve [false positive detection](https://docs.gitlab.com/ee/user/application_security/sast/#false-positive-detection). See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/blob/main/CHANGELOG.md#v3133) for further details.
> - SpotBugs-based analyzer updated to improve debug logging. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs/-/blob/master/CHANGELOG.md#v334) for further 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.
>
> For previous changes, see [last month's updates](https://about.gitlab.com/releases/2023/02/22/gitlab-15-9-released/#static-analysis-analyzer-updates).
SAST, Secret Detection[Native attachments for Service Desk emails](https://docs.gitlab.com/ee/user/project/service_desk.html#receiving-files-attached-to-comments-as-email-attachments):
> Customer support agents often send screenshots and other files to external Service Desk issue authors.
> However, if your GitLab instance is not reachable from the internet or if you are using a private project that requires
> authentication to access issue uploads, issue authors won't be able to access the assets.
>
> In this release, files up to 10 MB attached to comments on Service Desk issues are sent to external participants as native email attachments.
> This allows external issue authors to access the
> assets directly in their inboxes without having to access the attachments through GitLab.
Service Desk