Nov 22, 2022 - Alana Bellucci  

GitLab 15.6 released with improvements to security policies, CI/CD variables, and DAST API

Git abuse rate limiting, special character support in CI/CD variables, group and subgroup-level scan result policies, scan execution policy support for dependency scanning and much more!

Today, we are excited to announce the release of GitLab 15.6 with Git abuse rate limiting, Support for special characters in CI/CD variables, group and subgroup-level scan result policies, DAST API analyzer for on-demand DAST API scans and much more!

These are just a few highlights from the 30+ improvements in this release. Read on to check out all of the great updates below.

We thank the wider GitLab community for the 200+ contributions they provided to GitLab 15.6! At GitLab, everyone can contribute and we couldn't have done it without you!

To preview what's coming in next month’s release, check out our Upcoming Releases page, which includes our 15.7 release kickoff video.

GitLab MVP badge

This month's Most Valuable Person (MVP) is Deja Norby

Deja contributed 9 different merge requests across multiple stages including Create, Secure, and Fulfillment. She resolved many linter issues helping GitLab continue to iterate. We are thankful for Deja’s contributions and it sounds like she learned a lot by contributing. Thank you Deja! Your contributions deserve the spotlight, and embody what iteration is all about.

Key improvements released in GitLab 15.6

Group and subgroup-level scan result policies

GitLab now supports managing scan result policies at both the group and subgroup levels. These policies automatically flow down and apply to all projects inside the group. This makes it considerably easier to enforce these policies uniformly for large organizations that have large numbers of projects. To get started, have a group or subgroup Owner link an associated security policy project on the Security & Compliance > Policies page.

Git abuse rate limiting

In GitLab 15.6, we’re introducing Git abuse rate limiting. Enable this feature to automatically notify administrators when a user downloads or clones more than a specified number of repositories in a group or any of its subgroups within a given time frame.

You can also automatically ban users who exceed the rate limit. Banned users cannot access the main group or any of its non-public subgroups. Access to unrelated groups is unaffected. Bans are permanent by default, but group administrators can always unban a banned user.

Git abuse rate limiting

DAST API analyzer for on-demand DAST API scans

With GitLab 15.6, the DAST API analyzer is now being used for GitLab on-demand DAST API scans. In previous versions of GitLab, the analyzer used in these on-demand scans was our legacy DAST analyzer. Our benchmarking shows that our DAST API analyzer finds more vulnerabilities, with a lower false-positive rate than our legacy analyzer. Our DAST API analyzer benchmark against a vulnerable API showed a 86% true positive detection rate versus a 36% true positive detection rate for the legacy analyzer. In addition, the benchmark showed a 78% decrease in false positives with our new DAST API analyzer. The DAST API analyzer also introduces new functionality such as GraphQL scans, support for authentication tokens that expire, scans using Postman collections, and scans using HAR files. With the switch to the DAST API analyzer, some of that functionality is already available in the on-demand site profile. In addition to using an OpenAPI specification in the site profile to define an API test, you can now use a Postman collection or HAR file to make sure that your test gets the API coverage that you expect. Also, we’ve added basic authentication as an option for on-demand API scans, adding to the previous functionality of using token authentication in authorization headers. Next, we will be working next on adding GraphQL support for on-demand API scans. Look for more improvements over the next few releases as we incorporate more of the advanced functionality of the DAST API analyzer.

DAST API analyzer for on-demand DAST API scans

Support for special characters in CI/CD variables

Previously, it was difficult to use the $ character in a CI/CD variable because $ normally signifies the start of another variable. GitLab would interpret it as a variable and try to expand it. In this release, we are introducing the variable: expand: keyword which will allow you to mark a variable as “raw”. A raw variable can contain any special characters and is not expanded when passed to the GitLab runner.

Support for special characters in CI/CD variables

CI/CD variable support in rules:exists configuration

The more complex your .gitlab-ci.yml configuration is, the more difficult it is to maintain and scale. By adding support for CI/CD variables with the rules: exists keyword, you can now use variables for paths or filenames. Having a single source of truth by storing frequently used values in variables ensures consistent behavior and makes your configuration easier to manage.

CI/CD variable support in `rules:exists` configuration

Other improvements in GitLab 15.6

Associate MRs to issues when migrating groups with projects

When migrating groups using GitLab Migration, GitLab now preserves associations of imported merge requests to issues. This populates the Related merge requests section on the issue details page.

Associate MRs to issues when migrating groups with projects

Import GitHub branch protection rules

When you import projects from GitHub to GitLab, GitHub branch protection rules that have an equivalent on GitLab are mapped to GitLab branch protection rules or project-wide GitLab settings:

  • GitHub rule Require conversation resolution before merging for the project’s default branch is mapped to the All threads must be resolved GitLab setting.
  • GitHub rule Require a pull request before merging is mapped to the No one option in the Allowed to push list of the branch protection rule.
  • GitHub rule Require a pull request before merging - Require review from Code Owners is mapped to the Code owner approval branch protection rule. Requires GitLab Premium or higher.
  • GitHub rule Require signed commits for the project’s default branch is mapped to the Reject unsigned commits GitLab push rule. Requires GitLab Premium or higher.
  • GitHub rule Allow force pushes - Everyone is mapped to the Allowed to force push branch protection rule.

New GraphQL parameter for analyzing deprecated schema items

You can now make calls against the GraphQL API as if all deprecated items were already removed. To make these calls, add the new remove_deprecated=true query parameter to the GitLab GraphQL API endpoint. This way, you can verify your API calls against the GraphQL schema without the deprecated schema items.

Prevent Guests from viewing internal notes

Internal notes provide organizations with a way to manage internal communication in an issue or epic. We have improved support for this use case by ensuring users with the Guest role cannot create or view internal notes on GitLab issues and epics, even if they are the assignee or the author for that issue or epic. This provides organizations assurance that information in their internal notes will only be visible to members of their organization.

Default split view for Markdown preview in the Web Editor

The ability to preview Markdown files side by side while editing was introduced in GitLab 14.2. With this release, we’ve made the split view the default experience for previewing Markdown in the Web Editor. In the Preview tab, you can now see a live Markdown preview that updates as you type alongside your content. This way, you can be confident that your markup is valid and renders as you intended without having to switch between the Write and Preview tabs.

Admin Area Runners - job queued and duration times

When GitLab administrators get reports from their development team that a CI job is either waiting for a runner to become available or is slower than expected, one of the first areas they investigate is runner availability and queue times for CI jobs. While there are various methods to retrieve this data from GitLab, those options could be more efficient. They should provide what users need - a view that makes it more evident if there is a bottleneck on a specific runner.

The first iteration of solving this problem is now available in the GitLab UI. GitLab administrators can now use the runner details view in Admin Area > Runners to view the queue time for CI job and job execution duration metrics.

Admin Area Runners - job queued and duration times

Beta: Automatic revocation of leaked Personal Access Tokens

GitLab Secret Detection finds leaked credentials in your codebase so you can revoke them and protect your organization. It detects many kinds of sensitive values, including GitLab Personal Access Tokens.

GitLab is dogfooding a new feature where Personal Access Tokens on are automatically revoked if Secret Detection finds them leaked on the default branch of a public repository.

We’ll roll this feature out across and Self-Managed instances in an upcoming release. If you’re interested in testing this feature during its Beta period, please let us know by completing this form.

See multiple Code Quality scan reports per pipeline

GitLab Code Quality includes an MR widget, a pipeline report, and MR diff annotations to help you find and fix problems in your code. Many tools, including code scanners and linters for technical documentation, can output results in Code Quality’s open report format.

Previously, you could only see results from a single scan in the pipeline report and MR diff annotations. This made it harder to add custom scanning tools to your pipelines.

Now, all of the Code Quality views show results from all report artifacts saved in a pipeline.

This new feature is controlled by a feature flag that is now enabled by default in We plan to enable the flag by default in Self-Managed instances in GitLab 15.7.

Publish releases without giving access to source code

Previously, granting access to releases for public projects also allowed access to the source code. With this update, you can now publish releases without giving access to the source code. This is useful for organizations that use releases as a way to give access to new versions of software but do not want the source code to be public.

Improved values support for Helm-based deployments

We shipped initial Helm-chart support for the agent for Kubernetes in GitLab 15.4. In that release, Helm values had to be included in the Helm charts, which caused large-scale code duplication for users.

This release allows you to specify the Helm values as part of the agent configuration by adding environment-specific values to the agent configuration file, and keeping generic values within the Helm chart.

Mount ConfigMap to volumes with the Auto Deploy chart

The default Auto Deploy Helm chart now supports the extraVolumes and extraVolumeMounts options. In past releases, you could specify only Persistent Volumes for Kubernetes. Among other use cases, you can now mount:

  • Secrets and ConfigMaps as files to Deployments, CronJobs, and Workers.
  • Existing or external Persistent Volumes Claims to Deployments, CronJobs, and Workers.
  • Private PKI CA certificates with hostPath mounts to achieve trust with the PKI.

Thanks to Maik Boltze for this community contribution.

Automatically add incident severity changes to incident timelines

Incident severity is assigned at the beginning of an incident to ensure proper response across the organization. Incident severity is determined based on the information available at the time. Severity should be adjusted as more information becomes available. In this release, changes in incident severity automatically appear in the incident timeline.

Automatically add incident severity changes to incident timelines

Scan execution policy support for dependency scanning

Users can now require Dependency Scanning 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.

Scan execution policy support for dependency scanning

Omnibus improvements

  • GitLab 15.6 also includes Mattermost 7.4, with Calls keyboard shortcuts and multiple improvements to Boards including minimum default board roles, guest account support, and multi-person properties. This version also includes security updates and upgrading from earlier versions is recommended.

Display a summary of a user’s contributions before deletion

Previously, when you deleted a user and their contributions from the Admin area, it was not clear what and how many associated contributions were about to be deleted. Now, before proceeding with deleting a user, a confirmation message lists the number of groups, projects, issues, and merge requests associated with the user. This summary can help you prevent the accidental deletion of projects or subgroups.

Display a summary of a user's contributions before deletion

Import pull request assigned reviewers from GitHub

Previously, while importing projects from GitHub to GitLab, reviewers assigned to pull requests in GitHub were not imported as reviewers assigned to merge requests in GitLab.

With this release, assigned reviewers are imported as assigned reviewers in GitLab. The following are out of scope for this release:

  • Review approval status.
  • Reviews requested from teams.

New GraphQL API for Contribution Analytics

To help you analyze team contributions, we have now exposed the Contribution Analytics data through GraphQL. Using this new API, you can identify opportunities for improvement and gain insights into the top contributors in your team.

The Contribution Analytics report visualizes the team’s push events, merge requests, and opened or closed issues at a group level over time.

New GraphQL API for Contribution Analytics

Configure default names for branches created from issues

Define a custom template for naming branches created from issues. The previous setting {issue ID}-{issue-title-hyphenated} remains the default. To define a custom template for your project, go to Repository Settings > Branch defaults.

Configure default names for branches created from issues

Update access levels from Protected Branch API

Previously, the UI was required to update the access levels of protected branches. The API required you to unprotect, then reprotect, a branch when updating its access levels. Now, the protected branches API enables you to directly update which users or groups are allowed_to_push, allowed_to_merge, allowed_to_unprotect, and more. This one-step method decreases the risk of a bot changing this setting and leaving a branch unprotected.

GitLab Runner 15.6

We’re also releasing GitLab Runner 15.6 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:

Bug Fixes:

The list of all changes is in the GitLab Runner CHANGELOG.

More accurate SAST rules for Python

The GitLab Vulnerability Research team has updated the rules used for Python SAST scanning to catch more relevant problems with fewer false-positive results.

The updated rules are included in the latest release of the Semgrep-based SAST analyzer. If you use the default GitLab-managed CI/CD template for SAST on GitLab 15.0 or higher, your pipelines automatically update the Semgrep-based SAST analyzer to use the new rules.

On your first scan after the update, existing findings we’ve identified as false positives will be marked “No longer detected”, and new findings may be created.

Static Analysis analyzer updates

GitLab Static Analysis includes many security analyzers that the GitLab Static Analysis team actively manages, maintains, and updates. The following analyzer updates were published during the 15.6 release milestone. These updates bring additional coverage, bug fixes, and improvements.

  • Gitleaks-based analyzer updated to version 8.15.0. See CHANGELOG for further details. This month, we also:
    • Fixed the rule for Slack webhook URLs.
  • KICS-based analyzer updated to version 1.6.2. See CHANGELOG for further details. This month, we also:
    • Added new rules for CloudFormation and Terraform.
    • Addressed several false positive detections in existing rules. Findings from these rules will be marked “No longer detected”.
    • Changed the severity of some existing rules.
    • Fixed an issue where Info-level findings were incorrectly mapped to Unknown severity.
  • MobSF-based analyzer updated to version 3.6.0. See CHANGELOG for further details.
  • PMD Apex-based analyzer updated to version 6.50.0. See CHANGELOG for further details.
  • Semgrep-based analyzer updated to version 0.121.2. See CHANGELOG for further details.
  • SpotBugs-based analyzer updated to version 4.7.3. See CHANGELOG for further details.

If you include the GitLab-managed SAST template (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. 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.

Show multiple approval rules in deployment approval UI

In this release, we are adding additional key information for multiple approval rules in the approval UI. Now during the workflow of approving a deployment, you can see who has already approved, as well as how many approvals are still needed and from which groups. This key information enables transparency and context for making the approval decision and also ensures compliance during an audit review.

Show multiple approval rules in deployment approval UI

Kubernetes 1.25 support

This release adds full support for Kubernetes version 1.25, released in August 2022. If you use Kubernetes, you can now upgrade your clusters to the most recent version and take advantage of all its features.

Read more about our Kubernetes support policy and other supported Kubernetes versions.

Add linked resource to an incident with a quick action

Important links can end up buried in comments throughout your incident. We added linked resources in incidents in 15.3. In this release, you can use a quick action to add one or more linked resources to an incident.

Add linked resource to an incident with a quick action

GitLab chart improvements

  • Cloud Native GitLab will replace alpine-certificates behaviors with gitlab-base in 15.7. To prevent differential behaviors between Alpine and Debian, and increase consistency across containers, we are going to build the pattern on gitlab-base. This means operational service containers will share a common root layer, which provides an efficiency boost to Pod instantiation time. The user impact of this change is that we will be changing the image name and tags used. We will maintain a mirrored tag for a brief period.
  • The GitLab Helm Chart will have a new major version release before the next major GitLab version, separate from the next major version as a whole. We are not sure when this next Helm chart major version will be released. Expect it no sooner than 2 milestones, and possibly longer. This was announced in 15.5. This major Helm chart release will require downtime, as we incorporate large updates and require manual intervention for upgrade paths.

Minimum required Git version is now v2.37.0

The minimum required version of Git is now v2.37.0. This newer version has a lot of changes that we, and other Git community members, have made that provide a much better experience and resolve many issues, including:

  • Improved replication speed in git-fetch.
  • Improvements to git-cat-file which reduces the number of spawning processes needed.
  • An update that fixes corruption in Git references using the new core.fsync option.
  • A bugfix for git-update-ref which fixes flushing semantics so that we can properly lock references.
  • Support for cruft packs.
  • A new feature to compute merges in bare repositories with git-merge-tree.

    If you use a version of Git on your GitLab instance that is not bundled with GitLab, please ensure you upgrade to at least v2.37.0.

Bug fixes

Some of the notable bug fixes in 15.6 are:

Performance improvements

In every release, we continue to make great strides improving GitLab’s performance. We’re committed to making every GitLab instance faster. This includes, an instance with over 1 million registered users!

In GitLab 15.6, we’re shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab 15.6 are:

Usability improvements

In every release, we make great strides in improving the overall effectiveness and usefulness of our product.

We also have a UI Polish Gallery to track important updates to our interfaces. These updates, while often small, improve your user experience.

In GitLab 15.6, we’re shipping usability improvements for issues, projects, milestones, and much more! We highlight the following changes in GitLab 15.6:


New deprecations and the complete list of all features that are currently deprecated can be viewed in the GitLab documentation.

  • Configuration fields in GitLab Runner Helm Chart
  • GitLab Runner registration token in Runner Operator
  • POST /api/v4/runners method to register runners
  • gitlab-runner register command
  • merge_status API field
  • runnerRegistrationToken parameter for GitLab Runner Helm Chart
  • Removals and breaking changes

    The complete list of all removed features can be viewed in the GitLab documentation.

    • NFS as Git repository storage is no longer supported. Migrate to Gitaly Cluster as soon as possible.
    • Other notable changes

      Removal of support for NFS as Git repository storage

      As of November 22, 2022, we are removing support for customers utilizing NFS for Git repository storage. This was originally planned for May 22, 2022, but in an effort to allow continued maturity of Gitaly Cluster, we chose to extend our removal of support date until now. Please see our official Statement of Support for further information.

      This change in our support follows the existing halt in development for NFS for Git repository storage that occurred in GitLab 14.0.

      Gitaly Cluster offers tremendous benefits for our customers such as:

      We encourage customers currently using NFS for Git repositories to migrate as soon as possible by reviewing our documentation on migrating to Gitaly Cluster.

      Important notes on upgrading to GitLab 15.6

      PostgreSQL versions have been bumped from 12.10 to 12.12 and 13.6 to 13.8. This can cause downtime for users upgrading to 15.6. More information can be found in our documentation regarding automatic restarts when PostgreSQL version changes.


      Please check out the changelog to see all the named changes:


      If you are setting up a new GitLab installation please see the download GitLab page.


      Check out our update page.


      We'd love to hear your thoughts! Visit the GitLab Forum GitLab Forum and let us know if you have questions about the release.

      GitLab Subscription Plans
      • Free: Free-forever features for individual users
      • Premium: Enhance team productivity and coordination
      • Ultimate: Organization wide security, compliance, and planning

      Try all GitLab features - free for 30 days

      Cover image licensed under CC0

      Try all GitLab features - free for 30 days

      GitLab is more than just source code management or CI/CD. It is a full software development lifecycle & DevOps tool in a single application.

      Try GitLab Free
      Open in Web IDE View source