GitLab.org/GitLab: Release v15.3.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 15.3
Released: 2022-08-22
License: MIT
Release Assets:
#### [Ultimate](https://about.gitlab.com/pricing/ultimate/)
[UI for custom HTTP headers on streaming audit events](https://docs.gitlab.com/ee/administration/audit_event_streaming.html#use-the-gitlab-ui):
> You can now add and remove custom HTTP headers for streaming audit events directly in the GitLab user interface.
>
> This makes it easy to interface with other systems that expect specific header values to be present and means
> that you can use a UI-based workflow instead of going through the [API](https://docs.gitlab.com/ee/administration/audit_event_streaming.html#use-the-api).
Audit Events[DORA custom reporting for data-driven software development improvements](https://docs.gitlab.com/ee/user/project/insights/index.html#dora-query-parameters):
> Building on top of our recent added support for [DORA metrics](https://docs.gitlab.com/ee/user/analytics/#devops-research-and-assessment-dora-key-metrics), we have added new DORA query parameters to Insights. With this new visualization, software leaders can track metrics improvements, understand patterns in their metrics trends, and compare performance between groups and projects.
>
> [Insights reports](https://docs.gitlab.com/ee/user/project/insights/index.html) are configured with a YAML file and can be shared across the organization as a single place for everyone to see the same metrics in the relevant context. In addition to DORA, Insights allows users to create custom reports to explore data such as issues created and closed, bugs created, merge requests, regressions, missed deadlines, track labeled issues, and much more.
Value Stream Management[Audit event for changes to audit event custom headers](https://docs.gitlab.com/ee/administration/audit_events.html#group-events):
> GitLab now records an audit event when a [custom HTTP header](https://docs.gitlab.com/ee/administration/audit_event_streaming.html#custom-http-headers)
> is added or removed for streaming audit events.
>
> This audit event helps you to ensure that your configuration for streaming
> audit events is correct and that you can:
>
> - Identify when changes happen for an audit.
> - Identify when you need to take action.
Audit Events[View your group runners' upgrade status](https://docs.gitlab.com/ee/ci/runners/configure_runners.html#determine-which-runners-need-to-be-upgraded):
> If you have to manage a fleet runners for your group, it can be time-consuming and inefficient to try to determine how many and which runners aren't using the latest version of GitLab Runner. Failing to update the version doesn't just mean you aren't using the latest features--it could also mean that you aren't taking advantage of security fixes.
>
> In 15.3, the list view shows two new summary status badges that indicate how many runners have versions that are out-of-date. The first badge shows how many runners have an upgrade recommended, and the second shows how many have an optional upgrade available. You can also view the status for individual runners, as well as filter the list by status. With these new additions, you can more easily identify runners that require version updates.
Runner Fleet[View your runners' upgrade status](https://docs.gitlab.com/ee/ci/runners/configure_runners.html#determine-which-runners-need-to-be-upgraded):
> For GitLab administrators responsible for operating and maintaining a fleet of runners, it can be time-consuming and inefficient to try to determine how many and which runners aren't using the latest version of GitLab Runner. In 15.1, in the Admin Area on the **Runners** page, badges were added to individual runners to show when an upgrade was available or recommended. In 15.2, you can filter the list by the upgrade status.
>
> In 15.3, you can view two new summary status badges that indicate how many runners have versions that are out-of-date. The first badge shows how many runners have an upgrade recommended, and the second shows how many have an optional upgrade available. With these new additions, administrators can more easily identify runners that require version updates.
Runner Fleet[DAST API and API Fuzzing speed improvements](https://docs.gitlab.com/ee/user/application_security/dast_api):
> As a part of our on-going efforts to improve the speed of testing APIs with DAST API scanning and API Fuzzing, we have added support for multi-CPU runners. API tests, like any tests on running applications, can take a long time to cover all operations with all test cases. The time that it takes to scan an API with a large number of operations can often discourage teams from including these tests in their pipelines, especially pipelines, such as feature branch pipelines, that are sensitive to execution time. The use of multi-CPU runners allows DAST API scans or API Fuzzing tests to be executed in parallel automatically. This significantly reduces the time needed to complete security testing of your APIs.
>
> In our benchmark tests, using a private runner with 3 CPUs increased the test speed by ~78%. Real numbers will vary depending on a number of factors, including the speed of the API being tested and the test modules that have been enabled. In general, when using runners with multiple CPUs, you can expect a significant reduction in test time over using shared runners or runners with a single CPU.
API Security[Browser-based DAST passive check milestone](https://docs.gitlab.com/ee/user/application_security/dast/checks/):
> Browser-based DAST scans now run all passive vulnerability checks from the browser-based analyzer! While browser-based DAST is still in an opt-in beta state, we have been releasing new vulnerability checks on a regular basis. Once each of these are finished and enabled in the browser-based analyzer, they are simultaneously disabled in the legacy proxy-based analyzer. Any checks that have not been ported over to the new analyzer are still run in the legacy analyzer, to ensure full vulnerability coverage for all tests. As of 15.3, we have completely switched all passive checks over to the new analyzer. This marks a major milestone in the development of our new analyzer.
>
> Going forward, we will be working on active vulnerability check development. As with the passive checks, the individual active checks will be enabled as they are released, for any scan where the DAST environment variable `DAST_BROWSER_SCAN` is set to `true`.
DAST[License compliance analyzer updates](https://docs.gitlab.com/ee/user/compliance/license_compliance/):
> GitLab License Compliance supports gathering license data by running the `license-finder` analyzer. This analyzer has been updated to use a Debian Bullseye base image instead of the previous Debian Buster base image.
License Compliance[Improved design for license compliance MR widget](https://docs.gitlab.com/ee/user/project/merge_requests/widgets.html#license-compliance):
> The license compliance merge request widget has a redesigned user experience that brings the following improvements:
>
> - Better consistency with the other widgets.
> - Improved readability through indentation.
> - A more clean overall stylistic look and feel.
License Compliance[Interactive security policy editor validation](https://docs.gitlab.com/ee/user/application_security/policies/):
> GitLab's security policy YAML editor now includes automatic inline validation. This validation helps prevent common YAML formatting errors and gives you live feedback on your policy as you type.
Security Orchestration[Add approval rules for all protected branches](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#approvals-for-protected-branches):
> You can now create an [MR approval rule](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html) and apply it to only protected branches in your
> project. This is a great improvement that allows you to more selectively apply compliance controls with increased granularity.
>
> Previously, adding an MR approval rule would apply it to all branches. This was a great way to ensure that proper workflows were enforced before
> code reached production, but it also meant that MRs for feature branches, short-lived branches, or experimental branches all had to use the same
> workflow. This could slow down developers that did not intend to commit to protected branches and who likely did not need the same level
> of workflow enforcement.
>
> Creating MR approval rules for protected branches allows you to be confident that the sensitive branches you depend on will have proper
> workflows applied to them while not slowing down development on other branches that do not need the same level of control.
Compliance Management[Define password complexity requirements](https://docs.gitlab.com/ee/administration/settings/sign_up_restrictions.html#password-complexity-requirements) (self-managed only):
> GitLab administrators can now define password complexity requirements in addition to minimum password length. For new passwords, you can
> now require:
>
> - Numbers.
> - Uppercase letters.
> - Lowercase letters.
> - Symbols.
>
> Complex passwords are less likely to be compromised, and the ability to configure password complexity requirements helps administrators
> enforce their password policies.
>
> Thank you [Martin Tan](https://gitlab.com/mtan-gitlab), [Kun Qian](https://gitlab.com/qk44077907), and [Shuang Zhang](https://gitlab.com/tonygodspeed92) for your contribution!
Authentication and Authorization[Maintain SAML Group Links with API](https://docs.gitlab.com/ee/api/groups.html#saml-group-links):
> Until now, SAML group links had to be configured in the UI. Now, you can manage SAML group links programmatically using the API so you can automate SAML groups management.
User Management[User SCIM identity visible in UI](https://docs.gitlab.com/ee/administration/admin_area.html#user-identities) (self-managed only):
> Previously, the SCIM identity for a user could only be accessed using the [SCIM API](https://docs.gitlab.com/ee/api/scim.html).
>
> Now, a user's SCIM identity is visible to GitLab administrators in the **Identities** tab of the User list. With
> this, troubleshooting of SCIM-related issues is simplified. Administrators can validate what identity, if any, is
> being used for a specific account without requiring GitLab Support or an API query.
User Management[Fortinet push notification support for Git over SSH](https://docs.gitlab.com/ee/security/two_factor_authentication.html#2fa-for-git-over-ssh-operations) (self-managed only):
> In previous version of GitLab, one-time passwords (OTP) were the only option when using FortiAuthenticator for two factor authentication. This option requires the user to type in this OTP each time it is presented.
>
> Now, users can choose to receive a push notification instead of an OTP, allowing users to verify themselves more quickly.
System Access[Group-level protected environment configuration in project settings page](https://docs.gitlab.com/ee/ci/environments/protected_environments.html#protect-critical-environments-under-a-group):
> Previously, there was no way to see if there are related group-level protected environment settings when viewing a project's configuration settings. In 15.3, you can now see these settings in the project's protected environment configuration settings page.
Environment Management[Geo supports project-level secure files](https://docs.gitlab.com/ee/administration/geo/replication/datatypes.html) (self-managed only):
> Geo now supports replication and verification of [project-level secure files](https://docs.gitlab.com/ee/ci/secure_files/) across Geo sites. With project-level secure files you can upload binary files, such as profiles, certificates, and keystores, to projects in GitLab and use them in CI/CD jobs.
Geo-replication, Disaster Recovery[Remove approvals by Code Owners if their files changed](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/settings.html#remove-approvals-by-code-owners-if-their-files-changed):
> To ensure that merge request approvals are about the latest proposed changes, you may [remove approvals when more changes are added](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/settings.html#remove-all-approvals-when-commits-are-added-to-the-source-branch). However, this kind of removal can be impractical if you also [require Code Owners to approve changes](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html#require-code-owner-approval-on-a-protected-branch) for specific files or paths. Even if the new changes don't affect the files that a Code Owner is responsible for, their approval is removed.
>
> Now you can be more selective and only remove Code Owner approvals if their files changed, increasing the speed of code review by avoiding unnecessary re-approvals.
>
> Thank you [Lee Tickett](https://gitlab.com/leetickett) for your contribution!
Code Review[GitOps features are now free](https://docs.gitlab.com/ee/user/clusters/agent/gitops.html):
> When you use GitOps to update a Kubernetes cluster, also called a pull-based deployment, you get an improved security model, better scalability and stability.
>
> The GitLab agent for Kubernetes has supported [GitOps workflows](https://docs.gitlab.com/ee/user/clusters/agent/gitops.html) from its initial release, but until now, the functionality was available only if you had a GitLab Premium or Ultimate subscription. Now if you have a Free subscription, you also get pull-based deployment support. The features available in GitLab Free should serve small, high-trust teams or be suitable to test the agent before upgrading to a higher tier.
>
> In the future, we plan to add [built-in multi-tenant support](https://gitlab.com/gitlab-org/gitlab/-/issues/337904) for Premium subscriptions. This feature would be similar to the impersonation feature already available for the [CI/CD workflow](https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html#restrict-project-and-group-access-by-using-impersonation).
Kubernetes Management, Deployment Management[Omnibus improvements](https://docs.gitlab.com/omnibus/) (self-managed only):
> - GitLab 15.3 includes [Mattermost 7.1](https://mattermost.com/blog/mattermost-v7-1-is-now-available/) with a new Insights dashboard and more. This version also includes [security updates](https://mattermost.com/security-updates/) and upgrade from earlier versions is recommended.
> - Gitaly is now using [new cgroup configurations](https://docs.gitlab.com/ee/administration/gitaly/configure_gitaly.html#control-groups). The following configs are to be deprecated: `gitaly['cgroups_count']`, `gitaly['cgroups_memory_limit']`, `gitaly['cgroups_memory_enabled]`, and `gitaly['cgroups_cpu_enabled']`. If you use any of the previous settings, ensure you remove them or switch to the new ones, before the 16.0 major release.
> - Starting in 15.3, the bundled Grafana will be disabled by default for new installations. The version of Grafana we bundle with Omnibus has a [security vulnerability](https://nvd.nist.gov/vuln/detail/CVE-2022-31107) and is now [deprecated](https://docs.gitlab.com/ee/update/deprecations.html#bundled-grafana-deprecated).
Omnibus Package[Migrate multiple MR assignees when migrating groups](https://docs.gitlab.com/ee/user/group/import/index.html#migrated-project-resources):
> As part of our effort to improve and iterate on [group migration](https://docs.gitlab.com/ee/user/group/import/index.html) by adding more metadata to the
> migrated groups and projects and creating a great migration experience. We are adding support for migrating multiple assignees to a merge request.
>
> Prior to this milestone, only a single merge request assignee could be migrated.
> This will help automate migrations and save time from eliminating the manual work of assigning all the assignees that were assigned prior to the migration.
Importers[Secure defaults for new access tokens](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html):
> When you create access tokens, the following defaults are displayed:
>
> - Expiration date is 30 days from the current date.
> - For project and group access tokens, the role is Guest.
>
> Previously, there were no defaults in place. By setting a default expiration date and pre-selecting the least privileged role, GitLab provides a more secure baseline
> from which to create a token.
Credential Management[User ID added to profile page](https://docs.gitlab.com/ee/user/profile/):
> The user ID is now available on the user profile page, including the ability to copy the ID. This will make tasks such as automation easier. Thanks to [Andreas Deicha](https://gitlab.com/TrueKalix) for this community contribution.
User Profile[New links to SSH fingerprints](https://docs.gitlab.com/ee/user/ssh.html#verify-that-you-can-connect):
> Your GitLab SSH fingerprints are now easier to find, thanks to new links on the SSH configuration page and in the documentation.
>
> Thank you [Andreas Deicha](https://gitlab.com/TrueKalix) for your contribution!
System Access[Delete deployments by using the API](https://docs.gitlab.com/ee/api/deployments.html#delete-a-specific-deployment):
> You can now delete deployments by using the API. This change allows you to manage and clean up old deployments refs.
Release Orchestration, Environment Management[Create annotated tags using the Release CLI](https://gitlab.com/gitlab-org/release-cli/-/tree/master/docs#create-a-new-release):
> Previously, you were only able to create lightweight tags when using the GitLab Release CLI to create a release. With this update, you can now add an optional `tag-message` parameter to create an annotated tag when creating a release. This enables you to include relevant information along with the new tag so downstream users and application can have additional context.
Release Orchestration[Create annotated tags by using `release:tag_message` keyword](https://docs.gitlab.com/ee/ci/yaml/#releasetag_message):
> You can now create an annotated tag when you create a release. In the `.gitlab-ci.yaml` file, use the `release` keyword to include an optional `tag_message` subkey and specify a message. This enables you to include relevant information along with the new tag, so downstream users and applications can have additional context.
Release Orchestration[Releases usability improvements](https://docs.gitlab.com/ee/user/project/releases/):
> In 15.3, we made several improvements that made GitLab Releases easier to use. Users can now [delete a release directly in the UI](https://gitlab.com/gitlab-org/gitlab/-/issues/39471), [set the release date in the UI](https://gitlab.com/gitlab-org/gitlab/-/issues/208948), [edit the `release_at` date in the UI](https://gitlab.com/gitlab-org/gitlab/-/issues/39471), and [easily identify a historical release](https://gitlab.com/gitlab-org/gitlab/-/issues/199429).
Release Orchestration[Edit all release details by using Edit tag button](https://docs.gitlab.com/ee/user/project/releases/#edit-a-release):
> We have updated the edit tag workflow so it navigates to edit the release. Previously, it led to a legacy edit tag page. Now you can more easily create or update the related release information, including release notes, and take advantage of other supported functionality such as webhooks for the new release.
Release Orchestration[Safe method to remove Praefect database records](https://docs.gitlab.com/ee/administration/gitaly/recovery.html#manually-remove-repositories) (self-managed only):
> In some cases Gitaly Cluster may create a database entry for a repository but fail to replicate the on-disk data. You can now manually remove
> the Gitaly Cluster database entries while leaving the on-disk repository intact by using the [`-db-only`](https://docs.gitlab.com/ee/administration/gitaly/recovery.html#manually-remove-repositories) option. This allows administrators to remove
> orphaned database entries while protecting on-disk repositories.
>
> To re-track a repository, use the [`track-repository` command](https://docs.gitlab.com/ee/administration/gitaly/recovery.html#manually-track-repositories).
Gitaly[Improve the accuracy of repository size calculation](https://docs.gitlab.com/ee/user/project/repository/#repository-size) (self-managed only):
> We are working hard to make the repository size displayed in GitLab more accurate by improving how we calculate
> the size of a repository. We are doing this to give a more accurate picture of how much disk space your
> repositories use.
>
> In the past, we included shared objects that were a part of the pool repository in our calculation. We have revised
> our calculation methods to no longer include these shared objects, and provide a more accurate representation of
> your repositories' actual storage space. As a result, calculated storage for forked projects now only includes
> the git changes as opposed to the entire git repository.
>
> While this is an improvement to repository size calculation, it is not perfect. There are still situations where
> the calculated repository size can differ from what is expected, and we are [investigating ways to fix this
> situation](https://gitlab.com/gitlab-org/gitaly/-/issues/4428).
Gitaly[Create tasks in issues](https://docs.gitlab.com/ee/user/tasks.html):
> Tasks provide a robust way to refine an issue into smaller, discrete work units. Previously in GitLab, you could break down an issue into smaller parts using markdown checklists within the description. However, these checklist items could not be easily assigned, labeled, or managed anywhere outside of the description field.
>
> You can now create tasks within issues from the Child Items widget. Then, you can open the task directly within the issue to quickly update the title, set the weight, or add a description. Tasks break down work within projects for GitLab Free and increase the planning hierarchy for our GitLab Premium customers to three levels (epic, issue, and task). In our next iteration, you will be able to add labels, milestones, and iterations to each task.
>
> Tasks represent our first step toward evolving issues, epics, incidents, requirements, and test cases to [work items](https://docs.gitlab.com/ee/development/work_items.html). If you have feedback or suggestions about tasks, please comment on [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/363613).
Team Planning[Submit merge request review with summary comment](https://docs.gitlab.com/ee/user/project/merge_requests/reviews/#submit-a-review):
> When you finish reviewing a merge request, there are probably some common things that you do, like summarizing your review for others or approving the changes if they look good to you. Those common tasks are now quicker and easier: when you submit your review, you can add a summary comment along with any [quick actions](https://docs.gitlab.com/ee/user/project/quick_actions.html) like `/approve`.
Code Review[Enforce authorization checks for all media files](https://docs.gitlab.com/ee/security/user_file_uploads.html):
> Images attached to issues, merge requests, or comments did not require authentication to be viewed if you knew the direct URL of the attachment. In some cases, this wasn't enough security for compliance-minded organizations.
>
> Authorization checks are now enabled by default for all projects, and can be configured in the UI or via the [projects API](https://docs.gitlab.com/ee/api/projects.html) to meet your organizational needs. Authentication checks may cause issues for email clients or other external services, which can't create a valid GitLab session to authenticate.
Code Review, Team Planning[Visualize table of contents in the WYSIWYG wiki editor](https://docs.gitlab.com/ee/user/project/wiki/#content-editor):
> When you're editing a wiki page in the rich text WYSIWYG editor, you expect to see an accurate representation of the content as it will appear after it's published. Some elements are too complex for plain text formatting, and require short codes or macros that generate content when the page is built. A wiki's table of contents is one example: it generates a list from your page's subheadings, simplifying navigation of very long pages. However, WYSIWYG page editing displayed a table of contents as a static placeholder block.
>
> GitLab 15.3 shows a visual representation of the Table of Contents in the WYSIWYG wiki editor. To add a table of contents while editing a page, select the plus (+) icon in the toolbar, then select **Table of Contents.** The table of contents updates in real time as you create and edit subheadings on the page, helping you monitor the outline of your longer wiki pages.
Wiki[Simulate default branch pipeline in the Pipeline Editor](https://docs.gitlab.com/ee/ci/pipeline_editor/):
> The pipeline editor helps prevent syntax errors in your pipeline before you commit. But pipeline logic issues are harder to spot. For example, incorrect `rules` and `needs` job dependencies might not be noticed until after you commit and try running a pipeline.
>
> In this release, we've brought the ability to simulate a pipeline to the pipeline editor. This was previously available in limited form in the [CI Lint tool](https://docs.gitlab.com/ee/ci/lint.html#simulate-a-pipeline), but now you can use it directly in the pipeline editor. Use it to simulate a new pipeline creation on the default branch with your changes, and detect logic problems before you actually commit!
Pipeline Authoring[Improved behavior of CI/CD `changes` with new branches](https://docs.gitlab.com/ee/ci/yaml/#ruleschanges):
> Configuring CI/CD jobs to run on pipelines when certain files are changed by using `rules: changes` is very useful with merge request pipelines. It compares the source and target branches to see what has changed, and adds jobs as needed. Unfortunately, `changes` does not work well with branch pipelines. For example, if the pipeline runs for a new branch, `changes` has nothing to compare to and always returns `true`, so jobs might run unexpectedly.
>
> In this release we're adding `compare_to` to `rules:changes` for both jobs and `workflow:rules`, to improve the behavior in branch pipelines. You can now configure your jobs to check for changes between the new branch and the defined comparison branch. Jobs that use `rules:changes:compare` will work the way you expect, comparing against the branch you define. This is useful for monorepos, where many independent jobs could be configured to run based on which component in the repo is being worked on.
Pipeline Authoring[Improved details and editing for group runners](https://docs.gitlab.com/ee/ci/runners/runners_scope.html#view-and-manage-group-runners):
> If you're a group owner, when you're viewing a runner's details, the redesigned details page has an improved layout. The runner's metadata is displayed more compactly and you can edit the runner from the new view. These changes help make the experience of managing runners easier and more efficient.
Runner Fleet[GitLab Runner 15.3](https://docs.gitlab.com/runner):
> We’re also releasing GitLab Runner 15.3 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:
>
> - [Use Podman for the Docker executor on Linux](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27119)
>
> #### Bug Fixes:
>
> - [Artifact downloads fail with certain `CI_JOB_TOKEN` values](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29193)
> - [GitLab Runner Operator for Kubernetes does not install in offline environments](https://gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator/-/issues/77)
>
> The list of all changes is in the GitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/15-3-stable/CHANGELOG.md).
GitLab Runner Core[Rebase a merge request from the UI without triggering a pipeline](https://docs.gitlab.com/ee/user/project/merge_requests/methods/index.html#rebase-without-cicd-pipeline):
> In large and busy monorepos with semi-linear branching, you might need to rebase your merge requests frequently. To save resources, you might not want to run a pipeline each time you rebase. You could skip the pipeline while [rebasing with the API](https://docs.gitlab.com/ee/api/merge_requests.html#rebase-a-merge-request), or by using [Git push options](https://docs.gitlab.com/ee/user/project/push_options.html#push-options-for-gitlab-cicd) or [`[ci skip]` in a commit message](https://docs.gitlab.com/ee/ci/pipelines/index.html#skip-a-pipeline), but not when rebasing from the UI in a merge request.
>
> Now we have an option to skip the pipeline when rebasing from the UI, so you have better control over when a pipeline runs for your merge requests. Thanks to [Kev](https://gitlab.com/KevSlashNull) for the contribution!
Continuous Integration (CI)[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.3 release milestone. These updates bring additional coverage, bug fixes, and improvements.
>
> - Kics analyzer updated to add additional rules, fix bugs, and update to kics version 1.5.12. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/kics/-/blob/main/CHANGELOG.md#v312) for details.
> - NodeJSScan analyzer updated to fix an issue scanning repositories that contain symlinks. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/nodejs-scan/-/blob/master/CHANGELOG.md#v312) for details.
> - PMD-Apex analyzer updated to version 6.47.0. This update resolves a security vulnerability in a PMD dependency. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/pmd-apex/-/blob/master/CHANGELOG.md#v311) for details.
> - Semgrep analyzer updated. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/blob/main/CHANGELOG.md#v331) for details.
> - We've updated to Semgrep version 0.104.0 to improve performance, fix bugs, and otherwise improve the scanning engine.
> - We've made it possible to remove the "Improper Control of Generation of Code ('Code Injection')" rule, which is [prone to false positives](https://gitlab.com/gitlab-org/gitlab/-/issues/351399). To remove the rule from scanning today, set the [`SAST_EXPERIMENTAL_FEATURES` CI/CD variable](https://docs.gitlab.com/ee/user/application_security/sast/index.html#experimental-features). We're [exploring options to better handle rule removals](https://gitlab.com/gitlab-org/gitlab/-/issues/368284) before we remove the rule from the default scanning job.
> - Secrets analyzer updated to fix handling of custom certificate authorities (CAs) in OpenShift. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/blob/master/CHANGELOG.md#v423) for details.
> - SpotBugs analyzer updated to include new versions of SpotBugs, Gradle, Grails, Maven, sbt, Java, and other dependencies, and to fix handling of custom certificate authorities (CAs) in OpenShift. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs/-/blob/master/CHANGELOG.md#v323) 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.
>
> For previous changes, see [last month's updates](https://about.gitlab.com/releases/2022/07/22/gitlab-15-2-released/#static-analysis-analyzer-updates).
Code Quality, SAST, Secret Detection[Exclude paths from Secure scanning with double-star globs](https://docs.gitlab.com/ee/user/application_security/sast/#vulnerability-filters):
> We've improved the way you can ignore paths in GitLab Secure scanners.
> Ignoring paths can help you focus on the right findings by ignoring test files, example code, or other code you don't want to scan.
>
> You can now use double-star glob patterns like `**/*_test.go` or `test/**/fixture*` to exclude paths in:
>
> - Dependency Scanning, by using the [`DS_EXCLUDED_PATHS` variable](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#configuring-dependency-scanning).
> - SAST, by using the [`SAST_EXCLUDED_PATHS` variable](https://docs.gitlab.com/ee/user/application_security/sast/#vulnerability-filters).
> - Secret Detection, by using the [`SECRET_DETECTION_EXCLUDED_PATHS` CI/CD variable](https://docs.gitlab.com/ee/user/application_security/secret_detection/#available-cicd-variables).
Dependency Scanning, SAST, Secret Detection[IaC Scanning rules for secret detection now disabled](https://docs.gitlab.com/ee/user/application_security/iac_scanning/):
> We've updated GitLab IaC Scanning to disable built-in rules that detected secret tokens and values.
> These rules were added in the upstream project that powers IaC Scanning (kics).
>
> If you previously had IaC Scanning findings in the "Passwords and Secrets" family, they will show as ["No longer detected"](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/#activity-filter) after the analyzer updates.
>
> This change prevents duplicate findings when both GitLab Secret Detection and GitLab IaC Scanning are run in the same project.
> We expect this change to improve scanning performance by removing expensive pattern matching.
>
> We are [tracking work](https://gitlab.com/gitlab-org/gitlab/-/issues/367177) to ensure that the removed rules are all covered by built-in rules in GitLab Secret Detection.
SAST[Preview upcoming SAST analyzer consolidations](https://docs.gitlab.com/ee/user/application_security/sast/analyzers.html#transition-to-semgrep-based-scanning):
> You can now test upcoming changes by using [the Latest variant](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST.latest.gitlab-ci.yml) of the GitLab-managed SAST CI/CD template in your pipeline.
> This is part of our iterative plan to [replace language-specific GitLab SAST analyzers with Semgrep-based scanning](https://docs.gitlab.com/ee/update/deprecations#sast-analyzer-consolidation-and-cicd-template-changes), as announced [in 15.0](https://about.gitlab.com/releases/2022/05/22/gitlab-15-0-released/#semgrep-based-sast-scanning-available-for-early-adoption).
>
> In GitLab 15.3, we've amended the `latest` template so that the Semgrep analyzer replaces the deprecated analyzers bandit, gosec, and eslint.
> We recommend that you test this change in a merge request but stay on the Stable template in your default branch pipeline configuration.
> To learn more about the change, see documentation on the [transition to Semgrep-based scanning](https://docs.gitlab.com/ee/user/application_security/sast/analyzers.html#transition-to-semgrep-based-scanning).
>
> The `latest` template contains all changes that we plan to release in the Stable template in GitLab 15.4.
> To learn more about Stable and Latest templates, see documentation on [CI/CD template versioning](https://docs.gitlab.com/ee/development/cicd/templates.html#versioning).
SAST