GitLab 16.3 Release

GitLab 16.3 released with new velocity metrics in the Value Streams Dashboard

GitLab 16.3 released with new velocity metrics in the Value Streams Dashboard, more powerful GitLab SaaS runners on Linux, additional filtering for scan result policies, workspace connections with SSH, Flux sync status visualization, and much more!

Today, we are excited to announce the release of GitLab 16.3 with new velocity metrics in the Value Streams Dashboard, more powerful GitLab SaaS runners on Linux, additional filtering for scan result policies, workspace connections with SSH, Flux sync status visualization, and much more!

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

We thank the wider GitLab community for the 237 contributions they provided to GitLab 16.3! 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 16.4 release kickoff video.

GitLab MVP badge

MVP This month's Most Valuable Person (MVP) is awarded to Thomas Spear

Thomas has contributed 15 merge requests to the GitLab agent for Kubernetes Helm chart in the last month!

Thomas made the chart more mature in terms of security and observability, made it simpler to troubleshoot issues with agentk, and improved the CI/CD pipeline to check for breaking changes.

As a security engineer, Thomas enjoys collaborating with the team to provide a more secure default deployment of the Gitlab agent. Thomas expressed thanks for all the timely reviews and feedback, which team members were more than happy to provide.

Thank you Thomas, your contributions are hugely appreciated! 🙌

We would also like to take the opportunity to thank Shane Maglangit and Batuhan Apaydın for their great contributions.

16.3 Key improvements released in GitLab 16.3

New velocity metrics in the Value Streams Dashboard

New velocity metrics in the Value Streams Dashboard

The Value Streams Dashboard has been enhanced with new metrics: Merge request (MR) throughput and Total closed issues (Velocity). In GitLab, MR throughput is a count of the number of merge requests merged per month, and Total closed issues is the number of flow items closed at a point in time.

With these metrics, you can identify low or high productivity months and the efficiency of merge request and code review processes. You can then gauge whether the Value Stream delivery is accelerating or not.

Over time, the metrics accumulate historical data from MRs and issues. Teams can use the data to determine if delivery rates are accelerating or need improvement, and provide more accurate estimates or forecasts for how much work they can deliver.

To help us improve the Value Streams Dashboard, please share feedback about your experience in this survey.

New velocity metrics in the Value Streams Dashboard

Connect to a workspace with SSH

Connect to a workspace with SSH

With workspaces, you can create reproducible, ephemeral, cloud-based runtime environments. Since the feature was introduced in GitLab 16.0, the only way to use a workspace was through the browser-based Web IDE running directly in the environment. The Web IDE, however, might not always be the right tool for you.

With GitLab 16.3, you can now securely connect to a workspace from your desktop with SSH and use your local tools and extensions. The first iteration supports SSH connections directly in VS Code or from the command line with editors like Vim or Emacs. Support for other editors such as JetBrains IDEs and JupyterLab is proposed in future iterations.

Connect to a workspace with SSH

Flux sync status visualization

Flux sync status visualization

In previous releases, you probably used kubectl or another third-party tool to check the status of your Flux deployments. From GitLab 16.3, you can check your deployments with the environments UI.

Deployments rely on Flux Kustomization and HelmRelease resources to gather the status of a given environment, which requires a namespace to be configured for the environment. By default, GitLab searches the Kustomization and HelmRelease resources for the name of the project slug. You can customize the name GitLab looks for in the environment settings.

Flux sync status visualization

Additional filtering for scan result policies

Additional filtering for scan result policies

Determining which results from a security or compliance scan are actionable is a significant challenge for security and compliance teams. Granular filters for scan result policies will help you cut through the noise to identify which vulnerabilities or violations require your attention the most. These new filters and filter updates will streamline your workflows:

  • Status: Status rule changes introduce more intuitive enforcement of “new” versus “previously existing” vulnerabilities. A new status field new_needs_triage allows you to filter only new vulnerabilities that need to be triaged.
  • Age: Create policies to enforce approvals when a vulnerability is outside of SLA (days, months, or years) based on the detected date.
  • Fix Available: Narrow the focus of your policy to address dependencies that have a fix available.
  • False Positive: Filter out false positives that have been detected by our Vulnerability Extraction Tool, for SAST results, and via Rezilion for our Container Scanning and Dependency Scanning results.
Additional filtering for scan result policies

Security findings in VS Code

Security findings in VS Code

You can now see security findings directly in Visual Studio Code (VS Code), just as you would in a merge request.

You could already monitor the status of your CI/CD pipeline, watch CI/CD job logs, and move through your development workflow in the GitLab Workflow panel. Now, after you create a merge request for your branch, you can also see a list of new security findings that weren’t previously found on the default branch.

This new feature is part of GitLab Workflow for VS Code. Security scan results are pulled from an API, so this feature is available to developers using GitLab.com or self-managed instances running GitLab 16.1 or higher.

Security findings in VS Code

Use the needs keyword with parallel jobs

Use the needs keyword with parallel jobs

The needs keyword is used to define dependency relationships between jobs. You can use the keyword to configure jobs to be dependent on specific earlier jobs instead of following stage ordering. When the dependent jobs complete, the job can start immediately, speeding up your pipeline.

Previously, it was impossible to use the needs keyword to set parallel matrix jobs as dependent, but in this release, we have enabled the ability to use needs with parallel matrix jobs too. You can now define a flexible dependency relationship to parallel matrix jobs, which can help speed up your pipeline even more! The earlier your jobs can start, the earlier your pipeline can finish!

Use the `needs` keyword with parallel jobs

More powerful GitLab SaaS runners on Linux

More powerful GitLab SaaS runners on Linux

Having recently upgraded all of our Linux SaaS runners, we are now introducing xlarge and 2xlarge SaaS runners on Linux. Equipped with 16 and 32 vCPUs respectively and fully integrated with GitLab CI/CD, these runners will allow you to build and test your application faster than ever before.

We are determined to provide the industry’s fastest CI/CD build speed and look forward to seeing teams achieve even shorter feedback cycles and ultimately deliver software faster.

More powerful GitLab SaaS runners on Linux

Azure Key Vault secrets manager support

Azure Key Vault secrets manager support

Secrets stored in Azure Key Vault can now easily be retrieved and used in CI/CD jobs. Our new integration simplifies the process of interacting with Azure Key Vault through GitLab CI/CD, helping you streamline your build and deploy processes!

Azure Key Vault secrets manager support

16.3 Other improvements in GitLab 16.3

Audit event recorded for applications settings change

Audit event recorded for applications settings change

Application setting changes at an instance, project, and group level are now recorded in the audit log, along with which user made the change. This improves auditing of application settings for both self-managed and SaaS.

New navigation has color themes available

New navigation has color themes available

With the new navigation enabled, you can now select one of five different color themes, and choose the light or dark variety for each. Use themes to identify different environments or choose your favorite color.

New navigation has color themes available

Preserve pull request reviewers when importing from BitBucket Server

Preserve pull request reviewers when importing from BitBucket Server

Until now, the BitBucket Server importer did not import pull request (PR) reviewers and instead categorized them as participants. Information on PR reviewers is important from an audit and compliance perspective.

In GitLab 16.3, we added support for correctly importing PR reviewers from BitBucket. In GitLab, they become merge request reviewers.

CODEOWNERS file syntax and format validation

CODEOWNERS file syntax and format validation

You can now see in the UI if your CODEOWNERS file has syntax or formatting errors. Being able to specify code owners offers great flexibility, allowing multiple file locations, sections, and rules to be configured by users. With this new syntax validation, errors in your CODEOWNERS file will be surfaced in the GitLab UI, making it easy to spot and fix issues. The following errors will be surfaced:

  • Entries with spaces.
  • Unparsable sections.
  • Malformed owners.
  • Inaccessible owners.
  • Zero owners.
  • Fewer than 1 required approvals.

Previously, the CODEOWNERS file didn’t validate the information being entered into the file. This could lead to creating:

  • Rules for files/paths that don’t exist.
  • Rules that create conflict with other existing rules.
  • Rules that don’t apply because of incorrect syntax.

GitLab Runner 16.3

GitLab Runner 16.3

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

Bug Fixes:

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

Kubernetes 1.27 support

Kubernetes 1.27 support

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

You can read more about our Kubernetes support policy and other supported Kubernetes versions.

Wrap feature flag names instead of truncating

Wrap feature flag names instead of truncating

If you used feature flags in previous versions of GitLab, you might have noticed that long feature flag names were truncated. This made it difficult to quickly differentiate similar feature flag names.

In GitLab 16.3, the entire feature flag name is shown. Long names wrap across multiple lines, if needed.

Dependency and License Scanning support for Java v21

Dependency and License Scanning support for Java v21

GitLab Dependency and License Scanning now support analyzing Java v21 Maven lock files.

Runner tags enable UI-based configuration of on-demand DAST scans

Runner tags enable UI-based configuration of on-demand DAST scans

You can now use tags to specify which runners you wish to use for on-demand DAST scans. Prior to 16.3, you could configure DAST scans using private runners via CI configuration files. This UI-based configuration enables efficient UI-configuration for managing DAST scans.

Compliance reports renamed to Compliance center

Compliance reports renamed to Compliance center

To facilitate the growth of compliance-related features beyond reporting and into management, the Compliance reports section of GitLab was renamed to reflect the expanding scope of the area.

From GitLab 16.3, Compliance reports are known as Compliance center.

Improve accuracy of scan result policies

Improve accuracy of scan result policies

A scan result policy is a type of security policy you use to evaluate and block merge requests if particular rules are violated. Approvers may review and approve the change, or work with their development teams to address any issues (such as addressing critical security vulnerabilities).

Previously, we compared vulnerabilities in the latest source and target branches to detect any new violations of policy rules. But, this might not capture vulnerabilities detected from scans running as a result of various pipeline sources. To increase accuracy, we are now comparing the latest completed pipelines for each pipeline source (with the exception of parent/child pipelines). This will ensure a more comprehensive evaluation and reduce the cases where approvals are required when it may be unexpected.

Names for audit event streams

Names for audit event streams

Previously, audit event streaming destinations were assigned by the destination URL. This could lead to confusion when you set up multiple streams for one group or instance, because you had to expand the destination in the UI to see what filters and custom headers had been applied.

With GitLab 16.3, you can now name audit event streaming destinations to help identify and differentiate them when you have multiple streaming destinations defined.

Geo verifies group wikis

Geo verifies group wikis

Geo is now able to detect and correct data corruption of group wikis at rest and in transit. If you use Geo as part of your disaster recovery strategy, this helps to protect you against data loss in the event of a failover.

Include or exclude archived projects from project search results

Include or exclude archived projects from project search results

You can now opt to include or exclude archived projects from search results. By default, archived projects are excluded. This feature is available for project search in GitLab. Support for other global search scopes is proposed in future releases.

Include or exclude archived projects from project search results

Configurable import limits available in application settings

Configurable import limits available in application settings

Hardcoded limits exist for both migration by direct transfer and by importing export files.

In this release, we’ve made some of these limits configurable in application settings to allow self-managed GitLab administrators to adjust them according to their needs:

We’ve also added a new maximum decompressed file size for imported archives application setting, which replaces the validate_import_decompressed_archive_size feature flag. This limit was hardcoded to 10 GB. On GitLab.com, we’ve set this limit to 25 GB.

With these new application settings, both self-managed GitLab and GitLab.com administrators can adjust these limits as needed.

No entity export timeout for migrations by direct transfer

No entity export timeout for migrations by direct transfer

Until now, migrating groups and projects by direct transfer had a 90 minute export timeout. This limit effectively excluded large projects from being migrated, because only projects that could be migrated in under 90 minutes were allowed.

The upper limit for the overall migration timeout is 4 hours, and so the 90 minutes export timeout was not necessary. In this milestone, the limit was removed, allowing larger projects to be migrated.

Support for Azure AD overage claim

Support for Azure AD overage claim

GitLab SAML Group Sync now supports the Azure AD (now known as Entra ID) overage claim, which allows a user to have over 150 groups associated with them. The previous maximum was 150 groups. For more information, see Microsoft group overages.

Expose pipeline name as a predefined CI/CD variable

Expose pipeline name as a predefined CI/CD variable

Pipeline names defined with the workflow:name keyword are now accessible via the predefined variable $CI_PIPELINE_NAME.

Expose pipeline name as a predefined CI/CD variable

Automatic response to leaked Postman API keys

Automatic response to leaked Postman API keys

We’ve integrated Secret Detection with Postman to better protect customers who use Postman in their GitLab projects.

Secret Detection searches for Postman API keys. If a key is exposed in a public project on GitLab.com, GitLab sends the leaked key to Postman. Postman verifies the key, then notifies the owner of the Postman API key.

This integration is on by default for projects that have enabled Secret Detection on GitLab.com. Secret Detection scanning is available in all GitLab tiers, but an automatic response to leaked secrets is currently only available in Ultimate projects.

See the Postman blog post about this integration for further details.

Improved SAST vulnerability tracking

Improved SAST vulnerability tracking

GitLab SAST Advanced Vulnerability Tracking makes triage more efficient by keeping track of findings as code moves. We’ve released two improvements in GitLab 16.3:

  1. Expanded language support: In addition to its existing coverage, we’ve enabled Advanced Vulnerability Tracking for:
    • C and C++, in the Flawfinder-based analyzer.
    • Java, in the MobSF-based analyzer.
    • JavaScript, in the NodeJS-Scan-based analyzer.
  2. Better tracking: We’ve improved the tracking algorithm to handle anonymous functions in JavaScript.

This builds on previous expansions and improvements released in GitLab 16.2. We’re tracking further improvements, including expansion to more languages, better handling of more language constructs, and improved tracking for Python and Ruby, in epic 5144.

These changes are included in updated versions of GitLab SAST analyzers. Your project’s vulnerability findings are updated with new tracking signatures after the project is scanned with the updated analyzers. You don’t have to take action to receive this update unless you’ve pinned SAST analyzers to a specific version.

SAST analyzer updates

SAST analyzer updates

GitLab SAST includes many security analyzers that the GitLab Static Analysis team actively maintains, updates, and supports. We published the following updates during the 16.3 release milestone:

  • The Kics-based analyzer has been updated to use version 1.7.5 of the Kics engine. This update includes various bug fixes, and also adds improvements to error handling for self references in JSON and YAML. See the CHANGELOG for further details.
  • The Semgrep-based analyzer has been updated to add support for specifying ambiguous refs during passthrough custom configurations. We’ve also updated the SARIF parser to use Name over Title, and no longer fail scans upon SARIF toolExecutionNotifications of level error. See the CHANGELOG for further details.

If you include the GitLab-managed SAST template (SAST.gitlab-ci.yml) and run GitLab 16.0 or higher, you automatically receive these updates. To remain on a specific version of any analyzer and prevent automatic updates, you can pin its version.

For previous changes, see last month’s updates.

Explain this vulnerability

Explain this vulnerability

GitLab surfaces vulnerabilities that contain relevant information, however, sometimes it is unclear where to start. It takes time to research and synthesize information that is surfaced within the vulnerability record. Moreover it can be difficult to figure out how to fix a given vulnerability. With this Beta release, you can click a button to get an explanation and recommendation on how to mitigate the vulnerability, generated by AI.

Explain this vulnerability

Instance-level streaming audit event filters

Instance-level streaming audit event filters

In GitLab 16.2, we introduced instance-level audit event streaming. However, no filters were available to apply to these streams.

In GitLab 16.3, you can now apply filters by audit event type to instance-level audit event streams. With the addition of these filters in the UI, you can capture a subset of audit events to send to each streaming location, focusing only on the events that are relevant for you.

Security bot to trigger scan execution policies pipelines

Security bot to trigger scan execution policies pipelines

Security bot users will be created to support managing background tasks, and to enforce security policies for all newly created or updated security policy project links. This will ease the process for security and compliance team members to configure and enforce policies, specifically removing the need for security policy project maintainers to also maintain Developer access in development projects. Security policy bot users will also make it much clearer for users within an enforced project when pipelines are executed on behalf of a security policy, as this bot user will be the pipeline author.

When a security policy project is linked to a group or subgroup, a security policy bot will be created in each project in the group or subgroup. When a link is made to a group, subgroup, or an individual project, a security bot user will be created for the given project or for any projects in the group or subgroup. Any groups, subgroups, or projects that already have a link to a security policy project will be unaffected at this time, but users may re-establish any existing links to take advantage of this feature. In GitLab 16.4, we plan to enable security bots on all projects hosted on GitLab.com that have existing security policy project links.

Security bot to trigger scan execution policies pipelines

Omnibus improvements

Omnibus improvements

  • GitLab 16.3 includes Mattermost 8.0. This version includes security updates and upgrading from earlier versions is recommended.
  • Our Amazon Linux builds are now Amazon Linux 2023. Amazon Linux 2022 was never officially generally available and was replaced with Amazon Linux 2023, so we have adjusted our offering to the updated release.

Bug fixes, performance improvements, and usability improvements

Bug fixes, performance improvements, and usability improvements

At GitLab, we’re dedicated to providing the best possible experience for our users. With every release, we work tirelessly to fix bugs, improve performance, and enhance usability. Whether you’re one of the over 1 million users on GitLab.com or using our platform elsewhere, we’re committed to making sure your time with us is smooth and seamless.

Click the links below to see all the bug fixes, performance enhancements, and usability improvements we’ve delivered in 16.3.

Deprecations Deprecations

New deprecations and the complete list of all features that are currently deprecated can be viewed in the GitLab documentation. To be notified of upcoming breaking changes, subscribe to our Breaking Changes RSS feed.

  • Deprecate field `hasSolutions` from GraphQL VulnerabilityType
  • Geo: Housekeeping Rake tasks
  • RSA key size limits
  • Twitter OmniAuth login option is removed from GitLab.com
  • Twitter OmniAuth login option is deprecated from self-managed GitLab
  • Job token allowlist covers public and internal projects
  • GraphQL field `totalWeight` is deprecated
  • Removals and breaking changes Removals and breaking changes

    The complete list of all removed features can be viewed in the GitLab documentation. To be notified of upcoming breaking changes, subscribe to our Breaking Changes RSS feed.

    • RSA key size limits
    • Twitter OmniAuth login option is removed from GitLab.com
    • Bundled Grafana deprecated and disabled
    • License Compliance CI Template
    • Other notable changes Other notable changes

      Code suggestions (Beta) for self-managed instances

      Code suggestions (Beta) for self-managed instances

      GitLab 16.3 will be enforcing cloud licensing as a requirement for Code Suggestions (Beta). Cloud licensing replaces the authentication flow introduced in 16.1. Self-managed customers enabling Code Suggestions in 16.3 no longer need to create a SaaS account.

      As part of this change, GitLab will be collecting aggregated telemetry data, including the number of unique users and accepted code suggestions to help us scale and improve our service. For more information, see the Code Suggestions documentation.

      Important notes on upgrading to GitLab Important notes on upgrading to GitLab 16.3

      Git pulls against a secondary Geo site are being proxied to the primary Geo site even when that secondary site is up to date. You are impacted if you are using Geo to accelerate remote users who make Git pull requests against a secondary Geo site.

      • Impacted versions: 16.3.0 - 16.3.2
      • Versions containing fix: 16.3.4 and later

      For more information, see issue 425224.


      GitLab 16.3 will enforce cloud licensing for self-managed instances using Code Suggestions (beta). Self-managed customers on GitLab 16.2 and earlier with a GitLab Free subscription will lose access to Code Suggestions when they update to GitLab 16.3 or later.


      PostgreSQL Requirements have increased slightly. Ultimate customers’ server should have at least 12 GB of storage available, as 1GB of vulnerability data needs to be imported.


      To be consistent with all other data types, projects replication and verification now leverages the Geo self-service framework. This is a behind-the-scenes change that will make support and maintenance easier in the future. No action is needed from your part.


      16.3 will be a scheduled required stop. This means you must upgrade to 16.3 before moving to future releases, it cannot be skipped. For more information, take a look at the required stops. To better plan your upgrade, you can see all the required stops in our GitLab upgrade path tool.


      Changelog Changelog

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

      Installing Installing

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

      Updating Updating

      Check out our update page.

      Questions? Questions?

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

      GitLab Subscription Plans 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

      We want to hear from you

      Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.

      Share your feedback

      Take GitLab for a spin

      See what your team could do with The DevSecOps Platform.

      Get free trial

      Have a question? We're here to help.

      Talk to an expert
      Edit this page View source