GitLab.org/GitLab: Release v16.3.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 16.3
Released: 2023-08-22
License: MIT
Release Assets:
##### [Verify](https://about.gitlab.com/stages-devops-lifecycle/verify/)
[More powerful GitLab SaaS runners on Linux](https://docs.gitlab.com/ee/ci/runners/saas/linux_saas_runner.html) (SaaS only):
> Having recently upgraded all of our Linux SaaS runners, we are now introducing `xlarge` and `2xlarge` [SaaS runners on Linux](https://docs.gitlab.com/ee/ci/runners/saas/linux_saas_runner.html). 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.
GitLab Runner SaaS[Automatic response to leaked Postman API keys](https://docs.gitlab.com/ee/user/application_security/secret_detection/automatic_response.html) (SaaS only):
> 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](https://learning.postman.com/docs/developer/postman-api/authentication/).
> 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](https://learning.postman.com/docs/administration/token-scanner/#protecting-postman-api-keys-in-gitlab).
>
> This integration is on by default for projects that have [enabled Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/#enable-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](https://blog.postman.com/protecting-your-postman-api-keys-in-gitlab/) for further details.
Secret Detection[Explain this vulnerability](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#explaining-a-vulnerability-beta) (SaaS only):
> 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.
Vulnerability Management[New velocity metrics in the Value Streams Dashboard](https://docs.gitlab.com/ee/user/analytics/value_streams_dashboard.html):
> The [Value Streams Dashboard](https://about.gitlab.com/blog/2023/06/12/getting-started-with-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](https://docs.gitlab.com/ee/user/analytics/merge_request_analytics.html). You can then gauge whether the [Value Stream delivery](https://docs.gitlab.com/ee/user/group/value_stream_analytics/) 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](https://gitlab.fra1.qualtrics.com/jfe/form/SV_50guMGNU2HhLeT4).
Value Stream Management[Dependency and License Scanning support for Java v21](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#obtaining-dependency-information-by-parsing-lockfiles):
> GitLab Dependency and License Scanning now support analyzing Java v21 Maven lock files.
Software Composition Analysis[Runner tags enable UI-based configuration of on-demand DAST scans](https://docs.gitlab.com/ee/user/application_security/dast/proxy-based.html#on-demand-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.
DAST[Improved SAST vulnerability tracking](https://docs.gitlab.com/ee/user/application_security/sast/#advanced-vulnerability-tracking):
> GitLab SAST [Advanced Vulnerability Tracking](https://docs.gitlab.com/ee/user/application_security/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](https://docs.gitlab.com/ee/user/application_security/sast/#advanced-vulnerability-tracking), 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.
> 1. 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](https://about.gitlab.com/releases/2023/07/22/gitlab-16-2-released/#improved-sast-vulnerability-tracking).
> 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](https://gitlab.com/groups/gitlab-org/-/epics/5144).
>
> These changes are included in [updated versions](#sast-analyzer-updates) of GitLab SAST [analyzers](https://docs.gitlab.com/ee/user/application_security/sast/analyzers.html).
> 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](https://docs.gitlab.com/ee/user/application_security/sast/#pinning-to-minor-image-version).
SAST[Security findings in VS Code](https://docs.gitlab.com/ee/editor_extensions/visual_studio_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](https://marketplace.visualstudio.com/items?itemName=GitLab.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.
Editor Extensions, API Security, Container Scanning, DAST, Fuzz Testing, SAST, Secret Detection, Software Composition Analysis, Vulnerability Management[Names for audit event streams](https://docs.gitlab.com/ee/administration/audit_event_streaming/#add-a-new-http-destination):
> 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.
Audit Events[Compliance reports renamed to Compliance center](https://docs.gitlab.com/ee/user/compliance/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.
Compliance Management[Improve accuracy of scan result policies](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html):
> 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.
Security Policy Management[Instance-level streaming audit event filters](https://docs.gitlab.com/ee/administration/audit_event_streaming/#update-event-filters-1) (self-managed only):
> 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.
Audit Events[Security bot to trigger scan execution policies pipelines](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html):
> 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](https://gitlab.com/gitlab-org/gitlab/-/issues/414376) on all projects hosted on GitLab.com that have existing security policy project links.
Security Policy Management[Additional filtering for scan result policies](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html):
> 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.
Security Policy Management[Audit event recorded for applications settings change](https://docs.gitlab.com/ee/administration/audit_events.html#application-settings):
> 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.
Audit Events[Support for Azure AD overage claim](https://docs.gitlab.com/ee/user/group/saml_sso/group_sync.html#microsoft-azure-active-directory-integration):
> 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](https://learn.microsoft.com/en-us/security/zero-trust/develop/configure-tokens-group-claims-app-roles#group-overages).
User Management[Geo verifies group wikis](https://docs.gitlab.com/ee/administration/geo/) (self-managed only):
> Geo is now able to detect and correct data corruption of [group wikis](https://docs.gitlab.com/ee/user/project/wiki/group.html) 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.
Geo-replication, Disaster Recovery[CODEOWNERS file syntax and format validation](https://docs.gitlab.com/ee/user/project/codeowners/reference.html#error-handling-in-code-owners):
> 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.
Source Code Management[Connect to Workspaces with SSH](https://docs.gitlab.com/ee/user/workspace/configuration.html#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.
Workspaces[Azure Key Vault secrets manager support](https://docs.gitlab.com/ee/ci/secrets/azure_key_vault.html):
> 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!
Secrets Management[Include or exclude archived projects from project search results](https://docs.gitlab.com/ee/user/search/#include-archived-projects-in-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](https://docs.gitlab.com/ee/user/search/#global-search-scopes) is proposed in future releases.
Global Search[Kubernetes 1.27 support](https://docs.gitlab.com/ee/user/clusters/agent/#supported-cluster-versions):
> 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](https://docs.gitlab.com/ee/user/clusters/agent/#supported-cluster-versions) and other supported Kubernetes versions.
Deployment Management[Wrap feature flag names instead of truncating](https://docs.gitlab.com/ee/operations/feature_flags.html):
> 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.
Feature Flags[Omnibus improvements](https://docs.gitlab.com/omnibus/) (self-managed only):
> - GitLab 16.3 includes [Mattermost 8.0](https://mattermost.com/blog/mattermost-v8-0-is-now-available/). This version includes
> [security updates](https://mattermost.com/security-updates/) and upgrading from earlier versions is recommended.
> - Our Amazon Linux builds are now [Amazon Linux 2023](https://aws.amazon.com/linux/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.
Omnibus Package[Preserve pull request reviewers when importing from BitBucket Server](https://docs.gitlab.com/ee/user/project/import/bitbucket_server.html):
> 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.
Importers[Configurable import limits available in application settings](https://docs.gitlab.com/ee/user/group/import/index.html#limits) (self-managed only):
> 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:
>
> - [Maximum relation size that can be downloaded from the source instance in direct transfer](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#maximum-download-file-size-for-imports-by-direct-transfer).
> Previously hardcoded at 5 GB. On GitLab.com, we've set this limit to 5 GB.
> - [Maximum size of a remote import file that can be downloaded from remote Object Storages (such as AWS S3)](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#maximum-remote-file-size-for-imports).
> Previously hardcoded at 10 GB. On GitLab.com, we've set this limit to 10 GB.
>
> We've also added a new
> [maximum decompressed file size for imported archives](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#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.
Importers[New navigation has color themes available](https://docs.gitlab.com/ee/user/profile/preferences.html#change-the-color-theme):
> 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.
Navigation & Settings[No entity export timeout for migrations by direct transfer](https://docs.gitlab.com/ee/user/group/import/#limits):
> 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.
Importers[Flux sync status visualization](https://docs.gitlab.com/ee/ci/environments/kubernetes_dashboard.html#flux-sync-status):
> 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.
Environment Management[Expose pipeline name as a predefined CI/CD variable](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html):
> Pipeline names defined with the [`workflow:name`](https://docs.gitlab.com/ee/ci/yaml/#workflowname) keyword are now accessible via the predefined variable `$CI_PIPELINE_NAME`.
Continuous Integration (CI)[GitLab Runner 16.3](https://docs.gitlab.com/runner):
> 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:
>
> - [Configure project clone directory as safe by default](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29022)
>
> #### Bug Fixes:
>
> - [Runner v16.2.0 not available in Debian/RHEL repository](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/36048)
> - [Gitlab-runner with the shell executor sometimes fails to fetch submodules](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26993)
>
> The list of all changes is in the GitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/16-3-stable/CHANGELOG.md).
GitLab Runner Core[Use the `needs` keyword with parallel jobs](https://docs.gitlab.com/ee/ci/yaml/#needsparallelmatrix):
> 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](https://docs.gitlab.com/ee/ci/yaml/#parallelmatrix) 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!
Pipeline Composition[SAST analyzer updates](https://docs.gitlab.com/ee/user/application_security/sast/analyzers):
> GitLab SAST includes [many security analyzers](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) 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](https://gitlab.com/gitlab-org/security-products/analyzers/kics/-/blob/main/CHANGELOG.md?ref_type=heads#v414) 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](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/blob/main/CHANGELOG.md?ref_type=heads#v446) 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)) 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](https://docs.gitlab.com/ee/user/application_security/sast/#pinning-to-minor-image-version).
>
> For previous changes, see [last month's updates](https://about.gitlab.com/releases/2023/07/22/gitlab-16-2-released/#sast-analyzer-updates).
SAST