GitLab 18.3 Release

Bulk edit epic assignees, milestones, and more

Bulk edit epic assignees, milestones, and more

You can now bulk edit more epic attributes in a group. In addition to labels, you can now update assignee, health status, subscription, confidentiality, and milestone for multiple epics at once.

This enhancement makes it faster to manage large numbers of epics by letting you apply the same changes across multiple epics simultaneously.

Enhancements to wiki functionality

Enhancements to wiki functionality

This release introduces an enhanced wiki experience with three key improvements: you can now subscribe to wiki pages, view wiki comments while editing a page, and sort wiki page comments.

These enhancements help teams collaborate more effectively on documentation by letting you:

• Discuss content directly in context.
• Suggest improvements and corrections.
• Keep documentation accurate and up-to-date.
• Share knowledge and expertise.

With these updates, your GitLab wiki becomes living documentation that evolves alongside your projects through direct feedback and discussion.

Faster workspace startup with shallow cloning

Faster workspace startup with shallow cloning

Workspaces now use shallow cloning to reduce startup time. During initialization, GitLab downloads only the latest commit history instead of the full Git history. After the workspace starts, Git converts the shallow clone to a full clone in the background.

This feature applies automatically to all new workspaces, no configuration is required, and it doesn’t affect your development workflow.

Kubernetes 1.33 support

Kubernetes 1.33 support

GitLab now fully supports Kubernetes version 1.33. If you deploy your apps to Kubernetes, you can upgrade your connected clusters to the most recent version and take advantage of all its features.

For more information, see the Supported Kubernetes versions for GitLab features.

Concise DAST job output

Concise DAST job output

GitLab 18.3 introduces several improvements to the dynamic analysis security testing job output.

This improved job output provides clear, structured information that helps you understand scan results and troubleshoot failures.

Each section of the job output is concise and intuitive, with a link to our troubleshooting documentation at the bottom of the output. To override concise job output, set DAST_FF_DIAGNOSTIC_JOB_OUTPUT: "true" in your DAST configuration.

User-defined source for license information

User-defined source for license information

Users may now choose which source of license information has priority - the GitLab License database or a CycloneDX SBOM report. This provides users with more flexibility in sourcing license information for their open-source dependencies. Users who wish to define the source of license information may use the Security Configuration UI to make a selection. By default we use the SBOM data as a source for license information.

Group by OWASP 2021 in the vulnerability report

Group by OWASP 2021 in the vulnerability report

In the vulnerability report for projects and groups, you can now group the vulnerabilities by their OWASP Top 10 2021 category. Available for GitLab.com and GitLab Dedicated instances only.

Security policy audit events

Security policy audit events

GitLab Ultimate now provides comprehensive audit events for security policy management, with events organized and centralized within each security policy project.

Security teams can now:

• Track all policy modifications with detailed metadata.
• Monitor enforcement failures, including scan and pipeline execution failures.
• Monitor skipped scan execution and pipeline execution pipelines.
• Detect policy violations within each project, including MRs merged with policy violations.
• Receive alerts when limits are exceeded.
• Detect policy configuration errors.
• Use streaming-only options for high-volume scenarios.

New audit events include:

• security_policy_create
• security_policy_delete
• security_policy_update
• security_policy_merge_request_merged_with_policy_violations
• security_policy_yaml_invalidated
• security_policies_limit_exceeded
• security_policy_violations_detected (streaming only)
• security_policy_pipeline_failed (streaming only)
• security_policy_pipeline_skipped (streaming only)
• merge_request_branch_bypassed_by_security_policy

This enhancement strengthens your security posture by ensuring you have access to policy changes, configuration errors, and enforcement gaps, enabling faster incident response and thorough auditing capabilities.

Additional service account email configuration options

Additional service account email configuration options

By default, GitLab automatically generates an email address for new service accounts. Organizations can now assign a custom email address for service accounts through the UI. Previously, custom email configuration was only possible through the Service Accounts API. This change allows organizations to better route notifications to designated email addresses.

Instance level compliance and policy management (Beta)

Instance level compliance and policy management (Beta)

Enterprise users want to manage their compliance frameworks and security policies across multiple top-level groups. This is often the case when all groups in an instance:

• Share the same compliance frameworks. For example, when all projects in a group must adhere to the ISO 27001 standard.
• Enforce similar policies. For example, when all groups share the same pipeline execution policy.

With GitLab 18.3, compliance and security policy management is now available in beta for GitLab Self-Managed instances. You can now create, configure, and allocate compliance frameworks and security policies from a single top-level group and enforce them across all of the other top-level groups across your GitLab Self-Managed instance.

When you use a compliance and security policy top-level group, you have a single source of truth where you can manage and edit your compliance frameworks and security policies. Group admins can then apply these compliance frameworks and security policies to all the projects within those groups.

When you manage key frameworks and policies from the chosen top-level compliance and security policy group, it’s easier to manage and enforce key compliance and security needs across your GitLab Self-Managed instance. However, groups still retain the ability to create their own compliance frameworks and security policies to address specific situations or workflows that can arise in those groups.

This feature is for GitLab Self-Managed customers because GitLab.com and GitLab Dedicated customers are already able to manage policies centrally within a single top-level group or namespace.

SAML SSO support for session timeout attribute

SAML SSO support for session timeout attribute

GitLab now automatically detects and respects the SessionNotOnOrAfter attribute in SAML assertions from your Identity Provider (IdP). When this attribute is present, GitLab sets user sessions to expire at the time specified by your IdP, ensuring consistent session management across your organization. This feature requires no configuration changes - if your IdP provides the attribute, GitLab automatically honors the specified expiration time.

SSH key security warnings

SSH key security warnings

GitLab now displays a security warning in the UI when a user uploads a weak SSH key. This warning appears for older key types or keys with insufficient bit length (less than 2048 bits). This change helps educate users about SSH key security best practices and encourages the use of stronger cryptographic keys.

More models available for use with GitLab Duo Self-Hosted

More models available for use with GitLab Duo Self-Hosted

GitLab Self-Managed customers with GitLab Duo Enterprise can now use Anthropic Claude 4 with GitLab Duo Self-Hosted. Claude 4 is supported on AWS Bedrock. Open source OpenAI GPT OSS 20B and 120B have been added as experimental models, and are available on vLLM, Azure OpenAI, and AWS Bedrock. To leave feedback on using these models with GitLab Duo Self-Hosted, see issue 523918.

New navigation experience for groups in Your work

New navigation experience for groups in Your work

We’re excited to announce significant improvements to the group overview in Your work, designed to streamline how you discover and access your groups. The new tabbed interface features a Member tab, which provides a comprehensive view of accessible groups, and an Inactive tab to track groups pending deletion. We’ve also streamlined group management by adding Edit and Delete actions to the list view for users with appropriate permissions. We hope that these improvements make it easier to find and manage the groups that matter most to you.

We value your feedback on this update! Join the discussion in epic 18401 to share your experience with the new navigation system.

Control unique domains default for GitLab Pages sites

Control unique domains default for GitLab Pages sites

Administrators can now set the default behavior for unique domains on new GitLab Pages sites. By default, new Pages sites use unique domain URLs (like my-project-1a2b3c.example.com) to prevent cookie sharing between sites.

With this new setting for the instance, you can set new Pages sites to use path-based URLs (like my-namespace.example.com/my-project) by default. This helps organizations align GitLab Pages behavior with their workflows and security requirements.

Users can still override this setting for individual projects, and existing Pages sites remain unaffected.

OAuth apps support SSO authentication

OAuth apps support SSO authentication

OAuth applications can now seamlessly integrate with your organization’s single sign-on requirements. Previously, users had to authenticate twice: first with GitLab, then with SSO, creating unnecessary friction and complexity.

Now, OAuth applications can specify a parameter in their authorization requests to automatically trigger SSO authentication when required. This provides:

• A unified authentication experience for users
• Automatic compliance with your organization’s SSO policies
• Consistent security across all GitLab integrations
• Simple implementation for developers with just a parameter addition

Your OAuth integrations now respect SSO policies automatically, eliminating confusing authentication workflows while maintaining security.

GitLab Runner 18.3

GitLab Runner 18.3

We’re also releasing GitLab Runner 18.3 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.

Bug Fixes:

• In GitLab 18.2.0, runners are unable to pull the job cache by using the subdirectory file as cache key
• Docker executor fails to start jobs intermittently and returns an incorrect username or password error message.
• Inconsistency in *_get_sources hooks usage between none and empty Git strategies
• Operator deployed with non-OLM manifests assumes wrong default images
• Operator creates ConfigMap with the wrong name if CR has the app.kubernetes.io/instance label
• Operator 1.10.0 on OpenShift 4.9 fails to create runner ConfigMap and start pod in the gitlab-runner namespace

What’s new:

• GitLab Runner Operator now supports runner manager pod annotation
• GitLab Runner Operator now supports OpenShift 4.19

The list of all changes is in the GitLab Runner CHANGELOG.

New CLI commands for GitLab-managed OpenTofu and Terraform states

New CLI commands for GitLab-managed OpenTofu and Terraform states

The GitLab CLI (glab) now includes a new top-level command, opentofu. The opentofu command is aliased to terraform and tf commands to assist with GitLab-managed
OpenTofu and Terraform states.

The following commands have been added:

• glab opentofu init: Initialize the state backend locally.
• glab opentofu state list: List all states in a project.
• glab opentofu state download: Download the latest state or a specific version.
• glab opentofu state delete: Delete the entire state or a specific version.
• glab opentofu state lock: Lock a state.
• glab opentofu state unlock: Unlock a state

To manage state with the opentofu command, you must have at least glab 1.66 or later.

Improved file location information for Dependency Scanning analyzer

Improved file location information for Dependency Scanning analyzer

Being able to trace a dependency back to its source is important, especially for vulnerability remediation. Previously, the Dependency Scanning analyzer sometimes linked to job artifacts which were deleted when they expired. This made it difficult to trace back to the source of the dependency. The Dependency Scanning analyzer can now link to the project file that introduced the dependency. With this option enabled, links in the dependency list and vulnerability report are reliable. Users may enable this functionality by setting DS_FF_LINK_COMPONENTS_TO_GIT_FILES=true for the Dependency Scanning job.

Grant pipeline execution policies access to CI/CD configurations via API

Grant pipeline execution policies access to CI/CD configurations via API

Use the Projects REST API to programmatically enable or disable the Pipeline execution policy setting in security policy projects with the new spp_repository_pipeline_access field. Previously, this setting could only be managed through the GitLab UI. With this enhancement, you can now:

• GET the current Pipeline execution policy status.
• PUT to enable or disable the setting programmatically.

This improvement enables better automation and integration workflows for teams managing security policies at scale.

Scan execution policy templates

Scan execution policy templates

Scan execution policy templates help you quickly create scan execution policies based on common use cases. Choose from three templates:

• Merge request security
• Scheduled scanning
• Release security

Once you select a template, choose which GitLab security scans to enable with the template to get up and running immediately. If you have more advanced use cases, you can switch to the custom configuration to extend the policy with specific branch patterns, pipeline sources, and more.

Service account and access token exceptions for approval policies

Service account and access token exceptions for approval policies

The new Service Account & Access Token Exceptions feature allows you to designate service accounts and access tokens that can bypass merge request approval policies when necessary. This eliminates friction for known automations, while preserving security controls.

Key capabilities include:

• Automated workflow support: Configure specific service accounts, bot users, group access tokens, and project access tokens to bypass approval requirements for CI/CD pipelines, pull mirroring, and automated version updates. Service accounts can push directly to protected branches using approved tokens while maintaining restrictions for human users.
• Emergency access and auditing: Enable break-glass scenarios for critical incidents with comprehensive audit trails. All bypass events generate detailed audit logs with context and reasoning, supporting compliance requirements while allowing rapid response during outages or security fixes.
• GitOps integration: Unblock common automation challenges including repository mirroring, external CI systems (Jenkins, CloudBees), automated changelog generation, and GitFlow release processes. Service accounts receive the minimum required permissions with token-based access scoped to specific projects and branches.

This enhancement maintains strict security policies with flexibility for modern DevOps automation needs, eliminating custom workarounds while preserving governance controls.

Enterprise user enhancements

Enterprise user enhancements

GitLab 18.3 introduces enterprise user enhancements that give organizations greater control over user privacy and lifecycle management.

Group owners can now delete enterprise users in their namespace with the Users API. This destructive action unlinks user contributions and associates them with a system-wide Ghost user. These option is particularly valuable for cleaning up users erroneously created with automated SCIM imports or managing federated environments where usernames and emails need to be repurposed.

Additionally, organizations can now hide enterprise user emails on their user profiles, providing broader email privacy enforcement for all enterprise users.

Enhanced Admin area projects list

Enhanced Admin area projects list

We’ve upgraded the Admin area projects list to provide a more consistent experience for GitLab administrators:

• Delayed deletion protection: Project deletions now follow the same safe deletion flow used throughout GitLab, preventing accidental data loss.
• Faster interactions: Filter, sort, and paginate projects without page reloads for a more responsive experience.
• Consistent interface: The projects list now matches the look and behavior of other project lists across GitLab.

This update brings the administrator experience in line with GitLab design standards, and adds important safety features to protect your data. Future enhancements to project management will automatically appear in all project lists throughout the platform.