GitLab.org/GitLab: Release v17.7.0-ee

We are excited to introduce the small hosted runner on Linux Arm for GitLab.com, available for all tiers. This 2 vCPUs Arm runner is fully integrated with GitLab CI/CD and allows you to build and test applications natively on the Arm architecture.

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.

Group and project access tokens are now visible in the credentials inventory on GitLab.com. Previously, only personal access tokens and SSH keys were visible. Additional token types in the inventory allow for a more complete picture of credentials across the group.

Group Owners can now use a dedicated API endpoint to list enterprise users and any associated attributes.

Instance administrators can now configure an allowlist to control which integrations can be enabled on a GitLab instance. If an empty allowlist is configured, no integrations are allowed on the instance. After an allowlist is configured, new GitLab integrations are not on the allowlist by default.

Previously enabled integrations that are later blocked by the allowlist settings are disabled. If these integrations are allowed again, they are re-enabled with their existing configuration.

We've updated Advanced SAST to detect the following vulnerability classes more accurately:

• C#: OS command injection and SQL injection.
• Go: path traversal.
• Java: code injection, CRLF injection in headers or logs, cross-site request forgery (CSRF), improper certificate validation, insecure deserialization, unsafe reflection, and XML external entity (XXE) injection.
• JavaScript: code injection.

We've also improved detection of user input sources for C# (ASP.NET) and Java (JSF, HttpServlet) and updated severity levels for consistency.

To see which types of vulnerabilities Advanced SAST detects in each language, see Advanced SAST coverage. To use this improved cross-file, cross-function scanning, enable Advanced SAST. If you've already enabled Advanced SAST, the new rules are automatically activated.

In GitLab 17.7, we added support for the Known Exploited Vulnerabilities Catalog (KEV). The KEV Catalog is maintained by CISA and curates listings of CVEs that have been exploited in the wild. You can leverage KEV to better prioritize scan results and to help evaluate the potential impact a vulnerability may have on your environment.

This data is available to composition analysis users through GraphQL. There is planned work to support displaying this data in the GitLab UI.

The Advanced SAST code flow view is now available wherever vulnerabilities are shown, including the:

• Vulnerability Report.
• Merge request security widget.
• Pipeline security report.
• Merge request changes view.

The new views are enabled on GitLab.com. On GitLab self-managed, the new views are on by default starting in GitLab 17.7 (MR changes view) and GitLab 17.6 (all other views). For details on supported versions and feature flags, see code flow feature availability.

To learn more about Advanced SAST, see the announcement blog.

With this release, you can now enable secret push protection on all projects in your group via the REST API and the GraphQL API. This allows you to efficiently enable secret push protection on a per-group basis instead of project by project. Audit events are logged every time push protection is enabled or disabled.

The Owner base role is no longer available when creating a custom role as it provided no additional value because permissions are additive. Existing custom roles with the Owner base role are not impacted by this change.

GitLab's security scanning tools help identify known vulnerabilities and potential weaknesses in your application code. Scanning feature branches surfaces new weaknesses or vulnerabilities so they can be remediated before merging. In the case of vulnerabilities already in your project's default branch, fixing these in a feature branch will mark the vulnerability as no longer detected when the next default branch scan runs. While it is informative to know which vulnerabilities are no longer detected, each must still be manually marked as Resolved to close them. This can be time consuming if there are many of these to resolve, even when using the new Activity filter and bulk-changing status.

We are introducing a new policy type Vulnerability Management policy for users who want vulnerabilities automatically set to Resolved when no longer detected by automated scanning. Simply configure a new policy with the new Auto-resolve option and apply it to the appropriate project(s). You can even configure the policy to only Auto-resolve vulnerabilities of a certain severity or from specific security scanners. Once in place, the next time the project's default branch is scanned, any existing vulnerabilities that are no longer found will be marked as Resolved. The action updates the vulnerability record with an activity note, timestamp when the action occurred, and the pipeline the vulnerability was determined to be removed in.

Discover GitLab Duo Chat's powerful features! Just type /help in the chat message field to explore everything it can do for you.

Give it a try and see how GitLab Duo Chat can make your work smoother and more efficient.

Central DevOps teams often need to track where their CI/CD components are used across pipelines to better manage and optimize them. Without visibility, it's challenging to identify outdated component use, understand adoption rates, or support component life cycles.

To address this, we've added a new GraphQL query that enables DevOps teams to view a list of projects where a component is used across their organization's pipelines. This capability empowers DevOps teams to enhance productivity and make better decisions by providing crucial insights.

We continue to make iterative and important improvements to the compliance center's user experience for both groups and projects.

With GitLab 17.7, we shipped two key improvements:

• Users can now filter by groups in the Projects tab of the compliance center, which gives another option to users to apply, filter, and search for the appropriate project, and the compliance framework attached to that project.
• A project's compliance center now has a Frameworks tab, which allows users to search for compliance frameworks attached to that particular project.

Please note that adding or editing frameworks is still done on groups, not projects.

Because of a bug, FIPS Linux packages for GitLab 17.6 and earlier did not use the system Libgcrypt, but the same Libgcrypt bundled with regular Linux packages.

This issue is fixed for all FIPS Linux packages for GitLab 17.7, except for AmazonLinux 2. The Libgcrypt version of AmazonLinux 2 is not compatible with the GPGME and GnuPG versions shipped with the FIPS Linux packages.

FIPS Linux packages for AmazonLinux 2 will continue to use the same Libgcrypt bundled with the regular Linux packages, otherwise we would have to downgrade GPGME and GnuPG.

Previously, when using the action: prepare, action: verify, and action: access jobs together with the auto_stop_in setting, the timer was not reset. Starting in 18.0, action: prepare and action: access will reset the timer, while action: verify leaves it untouched.

For now, you can change to the new implementation by enabling the prevent_blocking_non_deployment_jobs feature flag.

Multiple breaking changes are intended to differentiate the behavior of the environment.action: prepare | verify | access values. The environment.action: access keyword will remain the closest to its current behavior, except for the timer reset.

To prevent future compatibility issues, you should review your use of these keywords. Learn more about these proposed changes in the following issues:

• Issue 437132
• Issue 437133
• Issue 437142

This release adds full support for Kubernetes version 1.31, released in August 2024. If you deploy your apps to Kubernetes, you can now upgrade your connected clusters to the most recent version and take advantage of all its features.

For more information, see our Kubernetes support policy and other supported Kubernetes versions.

To use the dashboard for Kubernetes, you need to select an agent for Kubernetes connection from the environment settings, and optionally configure a namespace and a Flux resource to track the reconciliation status. In GitLab 17.6, we added support for selecting an agent with a CI/CD configuration. However, configuring the namespace and the Flux resource still required you to use the UI or make an API call. In 17.7, you can fully configure the dashboard using the CI/CD syntax with the environment.kubernetes.namespace and environment.kubernetes.flux_resource_path attributes.

This experimental feature is another step in helping users prioritize vulnerabilities identified during Dependency Scanning or Container Scanning. Users may include this CI/CD component in their .gitlab-ci.yml file, which will generate a prioritization report for vulnerabilities found in the project. The report will print to the pipeline output.

The component queries the GitLab GraphQL API to retrieve vulnerability data and prioritizes as follows:

1. Vulnerabilities with known exploits (KEV) are the top priority.
2. Vulnerabilities with high EPSS scores.
3. Higher severity vulnerabilities.

Only detected and confirmed vulnerabilities are shown. Currently, the component relies on EPSS and KEV data to help prioritize vulnerabilities. EPSS and KEV data are only found on CVEs, which are collected through dependency and container scanning. To learn more, please refer to the Vulnerability Prioritizer.

As always, we welcome your feedback. Please add any questions or comments to the feedback issue.

The new method of user contribution and membership mapping is now available when you migrate between GitLab instances by direct transfer. This feature offers flexibility and control for both users managing the import process and users receiving contribution reassignments. With the new method, you can:

• Reassign memberships and contributions to existing users on the destination instance after the import has completed. Any memberships and contributions you import are first mapped to placeholder users. All contributions appear associated with placeholders until you reassign them on the destination instance.
• Map memberships and contributions for users with different email addresses on source and destination instances.

When you reassign a contribution to a user on the destination instance, the user can accept or reject the reassignment.

For more information, see streamline migrations with user contribution and membership mapping. To leave feedback, add a comment to issue 502565.

In previous versions of GitLab, emoji support was limited to an older Unicode standard, which meant some newer emojis were unavailable.

GitLab 17.7 introduces support for Unicode 15.1, bringing the latest emoji additions. This includes exciting new options like the t-rex 🦖, lime 🍋‍🟩, and phoenix 🐦‍🔥, allowing you to express yourself with the most up-to-date symbols.

Additionally, this update enhances emoji diversity, ensuring greater representation across cultures, languages, and identities, helping everyone feel included when communicating on the platform.

In this version, we're introducing the ability to set a default text editor for a more personalized editing experience. With this change, you can now choose between the rich text editor, the plain text editor, or opt for no default, allowing flexibility in how you create and edit content.

This update ensures smoother workflows by aligning the editor interface with individual preferences or team standards. With this enhancement, GitLab continues to prioritize customization and usability for all users.

We've introduced the new Planner role to give you tailored access to Agile planning tools like epics, roadmaps, and Kanban boards without over-provisioning permissions. This change helps you collaborate more effectively while keeping your workflows secure and aligned with the principle of least privilege.

Previously, token expiration email notifications were only sent seven days before expiry. Now, these notifications are also sent 30 and 60 days before expiry. The increased frequency and date range of notifications makes users more aware of tokens that may be expiring soon.

When creating a personal, project, group, or impersonation access token, you can now optionally enter a description of that token. This helps provide extra context about the token, such as where and how is it used.

You can now use the UI to rotate personal, project, and group access tokens. Previously, you had to use the API to do this.

Thank you shangsuru for your contribution!