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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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 GitLab.com are automatically revoked if Secret Detection finds them leaked on the default branch of a public repository.
We’ll roll this feature out across GitLab.com 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.
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 GitLab.com.
We plan to enable the flag by default in Self-Managed instances in GitLab 15.7.
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.
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, performance improvements, and UI 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 UI. 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 UI improvements we’ve delivered in 15.6.
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.
Container registry push events are rejected by the /api/v4/container_registry_event/events endpoint resulting in Geo secondary sites not being aware of updates to container registry images and subsequently not replicating the updates. Secondary sites may contain out of date container images after a failover as a consequence. This impacts versions 15.6.x and 15.7.0 - 15.7.2. If you’re using Geo with container repositories, you are advised to upgrade to GitLab 15.7.3 or 15.8.0 which contain a fix for this issue and avoid potential data loss after a failover.
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.
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