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
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.
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.
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.
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
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:
- 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.
- 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
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.
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
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.
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.
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.
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.
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
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.
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
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.
Dependency and License Scanning support for Java v21
GitLab Dependency and License Scanning now support analyzing Java v21 Maven lock files.
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
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
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.
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.
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.
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.
