GitLab 17.7 Release

GitLab 17.7 released with new Planner user role

GitLab 17.7 released with a new Planner user role, auto-resolution policy for vulnerabilities, admin-controlled instance integration allowlists, access token rotation in the UI and much more!

Today, we are excited to announce the release of GitLab 17.7 with a new Planner user role, auto-resolution policy for vulnerabilities, admin-controlled instance integration allowlists, access token rotation in the UI and much more!

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

To the wider GitLab community, thank you for the 138 contributions you provided to GitLab 17.7! 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 17.8 release kickoff video.

GitLab MVP badge

MVP This month's Most Valuable Person (MVP) is awarded to Vedant Jain

Everyone can nominate GitLab’s community contributors! Show your support for our active candidates or add a new nomination! 🙌

Vedant has been an outstanding community contributor, known for his proactive approach to contributing, his commitment to delivering, and his collaboration skills. He excels at taking on feedback, incorporating it into his work, and seeking assistance when needed, ensuring that his contributions are not only completed but also meet GitLab’s standards.

His contributions include streamlining project management processes with Abstracted work item attributes to a single list/board, Ordering of metadata on work items, and feature development in Remember the collapsed state of work item widgets. Vedant also fixed links in the UI to documentation (1, 2), helping the technical writing team as part of an important effort to improve UX across the entire product.

Amanda Rueda, Sr. Product Manager, Product Planning at GitLab, nominated Vedant and highlighted his proactive and community-oriented mindset, “Vedant’s work not only addresses user needs but through his contributions, he is co-creating a more stable and reliable GitLab environment. By contributing to bug fixes, usability improvements, and maintenance efforts, he has played a vital role in enhancing the overall quality of the product. His proactive approach and cross-group contributions embody GitLab’s core values of iteration, customer collaboration, and continuous improvement, making him a standout contributor in the community.”

“Thanks to everyone who helped me achieve my contributions,” says Vedant. “So grateful that I am able to make a good impact and looking forward to more contributions.”

Vedant is a Frontend Engineer at Atlan, an active metadata platform for modern data teams, and a Google Summer of Code 2024 Mentor.

We are so grateful to Vedant for all of his contributions and to all of our open source community for contributing to GitLab!

17.7 Key improvements released in GitLab 17.7

New Planner user role

New Planner user role

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.

New Planner user role

Instance administrators can control which integrations can be enabled

Instance administrators can control which integrations can be enabled

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.

Instance administrators can control which integrations can be enabled

New user contribution and membership mapping available in direct transfer

New user contribution and membership mapping available in direct transfer

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.

New user contribution and membership mapping available in direct transfer

Auto-resolve vulnerabilities when not found in subsequent scans

Auto-resolve vulnerabilities when not found in subsequent scans

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.

Auto-resolve vulnerabilities when not found in subsequent scans

Rotate personal, project, and group access tokens in the UI

Rotate personal, project, and group access tokens in the UI

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!

Track CI/CD component usage across projects

Track CI/CD component usage across projects

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.

Track CI/CD component usage across projects

Small hosted runner on Linux Arm available to all Tiers

Small hosted runner on Linux Arm available to all Tiers

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.

Small hosted runner on Linux Arm available to all Tiers

17.7 Other improvements in GitLab 17.7

Set your preferred text editor as default

Set your preferred text editor as default

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.

New /help command in GitLab Duo Chat

New /help command in GitLab Duo Chat

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.

New `/help` command in GitLab Duo Chat

Set namespace and Flux resource path from CI/CD job

Set namespace and Flux resource path from CI/CD job

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.

Efficient risk prioritization with KEV

Efficient risk prioritization with KEV

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.

Expanded Code Flow view for Advanced SAST

Expanded Code Flow view for Advanced SAST

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

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.

Expanded Code Flow view for Advanced SAST

Extended token expiration notifications

Extended token expiration notifications

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.

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.

Navigation and usability improvements for the compliance center

Omnibus improvements

Omnibus improvements

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.

Unicode 15.1 emoji support 🦖🍋‍🟩🐦‍🔥

Unicode 15.1 emoji support 🦖🍋‍🟩🐦‍🔥

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.

Kubernetes 1.31 support

Kubernetes 1.31 support

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.

Setting environment.action: access and prepare resets the auto_stop_in timer

Setting environment.action: access and prepare resets the auto_stop_in timer

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:

Enable secret push protection in your groups with APIs

Enable secret push protection in your groups with APIs

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.

Improved detection accuracy in Advanced SAST

Improved detection accuracy in Advanced SAST

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.

Group and project access tokens in credentials inventory

Group and project access tokens in credentials inventory

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.

New API endpoint to list enterprise users

New API endpoint to list enterprise users

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

New description field for access tokens

New description field for access tokens

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.

New description field for access tokens

Remove Owner base role from custom roles

Remove Owner base role from custom roles

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.

Features in Experiment Features in Experiment

SCA Vulnerability Prioritizer

SCA Vulnerability Prioritizer

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.

Custom Admin Role on GitLab self-managed

Custom Admin Role on GitLab self-managed

Administrators can now use Custom Admin Roles to provide granular access to the Admin area. This reduces the need for organizations to grant users full access to the Admin area to complete tasks. This feature is an Experiment. For more information, see the Custom admin roles.

We welcome feedback on this feature. If you have questions, comments, or would like to engage with our team, see this feedback issue.

Bug fixes, performance improvements, and UI improvements

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 17.7.

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.

  • Deprecation of `STORAGE` enum in `NamespaceProjectSortEnum` GraphQL API
  • Behavior change for Upcoming and Started milestone filters
  • Deprecation of `name` field in `ProjectMonthlyUsageType` GraphQL API
  • RunnersRegistrationTokenReset GraphQL mutation is deprecated
  • Pipeline job limits extended to the Commits API
  • Gitaly rate limiting
  • Increased default security for use of pipeline variables
  • Rename ‘setPreReceiveSecretDetection’ GraphQL mutation to ‘setSecretPushProtection’
  • Updated tooling to release CI/CD components to the Catalog
  • 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.

    • TLS 1.0 and 1.1 no longer supported
    • Important notes on upgrading to GitLab Important notes on upgrading to GitLab 17.7

      Starting from version 17.7, GitLab uses OpenSSL 3. This version of OpenSSL is a major release with notable deprecations and changes to the default behavior of OpenSSL (for more details see the OpenSSL 3 migration guide).

      Some of the older versions of TLS and cipher suites for external integrations may not be compatible with these changes. Therefore, it is crucial that you assess the compatibility of your external integrations before upgrading to a GitLab version that uses OpenSSL 3. GitLab bundles OpenSSL 3, so you are not required to make any changes to your operating system.

      With 17.7 and OpenSSL 3. TLS 1.2 or higher is required for all incoming and outgoing TLS connections. Also, TLS certificates must have at least 112 bits of security. RSA, DSA, and DH keys shorter than 2048 bits, and ECC keys shorter than 224 bits are prohibited.


      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