GitLab 17.5 release notes

Until now, the agent for Kubernetes could be used only if the Kubernetes cluster could connect to the GitLab instance. This issue meant that some customers couldn’t use the agent if, for example, they ran GitLab on a private network or behind a firewall. From GitLab 17.5, you can initiate the cluster-GitLab connection from GitLab, assuming that a properly configured agentk instance is already waiting for a connection initialization.

Once the initial connection is established, all the features of the agent are available. Initializing from a cluster is not changed with this development.

Administrators now have an enhanced, summarized view of the following critical pieces of information about the users on their instance:

• Pending approval.
• Without two-factor authentication.
• Administrators.

This increases user management efficiency, because administrators can quickly see how many users are in these states from the summary view, and filter on them.

You can now target groups/subgroups in security policy scopes. This extends the existing options allowing you to target all projects in a group/subgroup, projects based on a defined project list, and projects matching a list of compliance framework labels.

This gives you further flexibility in enabling policies across your groups, while also being able to apply exceptions to scope projects out of enforcement where necessary.

This improvement also precedes a number of enhancements that will simplify the process of linking security policy projects and granularly scoping enforcement of policies.

Previously, the compliance center was available only for top-level groups and subgroups.

With this release, we’ve added the compliance center to projects. At this level, compliance center provides view-only capabilities for checks and violations that pertain to a particular project.

To add or edit a framework, you should access the compliance center on top-level groups instead.

In GitLab 17.3, we announced the deprecation of compliance pipelines and its eventual removal by the 18.0 release. Instead of compliance pipelines, you should use the pipeline execution policy type instead, which was released in GitLab 17.2.

To help you migrate your existing compliance pipelines over to the pipeline execution policy type, this release includes a warning banner that:

• Notifies users about the deprecation of compliance pipelines.
• Provides a prompted and guided workflow to migrate existing compliance pipelines to the pipeline execution policy type.

Previously, when SAML SSO was enabled, groups could choose to enforce SSO, which required all members to use SSO authentication to access the group. However, some groups want the security of SSO enforcement for employees or group members, while still allowing outside collaborators or contractors to access their groups without SSO.

Now, groups with SAML SSO enabled have SSO automatically enforced for all members who have a SAML identity. Group members without SAML identities are not required to use SSO unless SSO enforcement is explicitly enabled.

A member has a SAML identity if one or both of the following are true:

• They signed in to GitLab using their GitLab group’s single sign-on URL.
• They were provisioned by SCIM.

To ensure smooth operation of the selective SSO enforcement feature, ensure your SAML configuration is working properly before selecting the Enable SAML authentication for this group checkbox.

We’re excited to announce a significant improvement to our Container Registry API for self-managed GitLab instances. With the release of GitLab 17.5, we’ve implemented keyset pagination for the :id/registry/repositories/:repository_id/tags endpoint, bringing it in line with the functionality already available on GitLab.com. This enhancement is part of our ongoing efforts to improve API performance and provide a consistent experience across all GitLab deployments.

Keyset pagination offers a more efficient method for handling large datasets, resulting in improved performance and a better user experience. This update is particularly useful when managing large container registries, as it allows for smoother navigation through repository tags. In order to use this feature, self-managed instances must upgrade to the next-generation container registry.

We’re thrilled to introduce support for protected npm packages, a new feature designed to enhance the security and stability of your GitLab package registry. In the fast-paced world of software development, accidental modification or deletion of packages can disrupt entire development processes. Protected packages address this issue by allowing you to safeguard your most important dependencies against unintended changes.

From GitLab 17.5, you can protect npm packages by creating protection rules. If a package is matched by a protection rule, only specified users can update or delete the package. With this feature, you can prevent accidental changes, improve compliance with regulatory requirements, and streamline your workflows by reducing the need for manual oversight.

We’ve added Ruby support to GitLab Advanced SAST. To use this new cross-file, cross-function scanning support, enable Advanced SAST. If you’ve already enabled Advanced SAST, Ruby support is automatically activated.

In the last month, we’ve also released updates to improve the detection rules for the other languages Advanced SAST supports by:

• Detecting additional Java path traversal, Java command injection, and JavaScript path traversal vulnerabilities.
• Updating CWE mappings to more specifically and consistently identify vulnerability types.
• Increasing the severity of path traversal vulnerabilities.

To see which types of vulnerabilities Advanced SAST detects in each language, see the new Advanced SAST coverage page.

To learn more about Advanced SAST, see last month’s announcement blog.

We’re also releasing GitLab Runner 17.5 today! GitLab Runner is the highly-scalable build 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:

• Support AWS S3 multipart uploads with scoped temporary credentials

Bug Fixes:

• Jobs with extra services don’t complete if one of the service container is not running
• The gitlab-runner-fips-17.4.0-1 package fails to run on Amazon Linux 2 and returns a glibc error
• Cache doesn’t work with Amazon S3 when using S3 Express One Zone endpoints
• Jobs are unable to pull base images if the DOCKER_AUTH_CONFIG variable has multiple registries