Ultimate

Application security testing

Dependency resolution for Maven and Python SBOM scanning: Software Composition Analysis

GitLab dependency scanning using SBOM now supports generating a dependency graph automatically for Maven and Python projects.

Previously, dependency scanning required users to provide a lock file or a graph file to get an accurate dependency analysis.

Now, when a lock file or graph file is not available, the analyzer automatically attempts to generate one.

This improvement makes it easier for Maven and Python projects to enable dependency scanning without requiring a lock file.

Incremental scanning for Advanced SAST: SAST

You can now perform incremental scans that analyze only changed parts of the codebase with GitLab Advanced SAST, significantly reducing scan times compared to full repository scans. This feature is a further iteration of diff-based scanning, because it produces full results for codebases.

By scanning just the code that has changed rather than the entire codebase, your teams can integrate security testing more seamlessly into their development workflow without sacrificing speed or adding friction.

Unverified vulnerabilities (Beta): SAST

Advanced SAST can now surface unverified vulnerabilities (findings that cannot be fully traced from source to sink) directly in the vulnerability report. Enable this feature if you have a higher tolerance for false positives over false negatives.

This feature is in beta status. Provide feedback in issue 596512.

Software supply chain security

Vulnerability resolution generally available on GitLab Duo Agent Platform: Vulnerability Management

Agentic SAST Vulnerability Resolution is now generally available in GitLab 18.11 on the GitLab Duo Agent Platform. It runs as part of your SAST scan, after SAST false positive detection runs, or when manually triggered for individual SAST vulnerabilities.

Agentic SAST Vulnerability Resolution:

• Autonomously analyzes the finding and reasons through the surrounding code context.
• Automatically creates a ready-to-review merge request with proposed code fixes for critical and high severity SAST vulnerabilities.
• Provides quality assessments so reviewers can quickly gauge confidence in the proposed remediation.
• Allows you to apply resolutions directly from vulnerability details pages.

We welcome your feedback in issue 585626.

Security risk management

Automated vulnerability severity overrides: Security Policy Management

Default vulnerability severities don't always reflect your organization's actual risk. A critical CVE in an internal-only service might not warrant the same urgency as one in a public-facing application, yet teams spend significant time triaging findings that don't match their risk model.

Vulnerability management policies can now automatically adjust the severity of vulnerabilities based on conditions like CVE ID, CWE ID, file path, and directory. When applied, the policy updates the severity of any vulnerability that matches the criteria on the default branch. Manual overrides still take precedence, and all changes are logged in the vulnerability's history and audit events.

This reduces triage work and ensures developers focus on the findings that matter most to your business.

Top CWE chart in security dashboards

The top CWE chart is now available on the new security dashboards. Identify the most common CWEs across your project or instance to identify opportunities for training, improvement, or program optimization. Users can group the dashboard data by severity and filter the dashboard by severity, project, and report type.

Block merge requests with high exploitability risk: Security Policy Management

Previously, merge request (MR) approval policies could block MRs based on vulnerability severity, but not all vulnerabilities carry the same risk. CVSS severity alone doesn't tell you whether a CVE is being exploited or how likely exploitation is. This leads to noisy approval policies and wasted time for developers and security teams.

You can now configure MR approval policies using Known Exploited Vulnerability (KEV) and Exploit Prediction Scoring System (EPSS) data. Block or require approval when a finding is in the KEV catalog (actively exploited in the wild), or when its EPSS score is above a threshold. Policy violations in the MR include KEV and EPSS context so developers understand why the security gate was triggered.

This gives security teams precise control over which findings block or warn, reduces alert fatigue, and keeps enforcement aligned with the current threat landscape.

Assign CVSS 4.0 scores to vulnerabilities: Vulnerability Management

CVSS 4.0 is the latest version of the industry standard used to assess and rate the severity of a vulnerability. You can now view and access CVSS 4.0 score in the UI, including the vulnerability details page and the vulnerability report. You can also query the score using the API.

Improved row interaction in the vulnerability report: Vulnerability Management

Previously, you had to select the row description to navigate to a vulnerability details page from the vulnerability report.

You can now select anywhere in the row to go directly to its details. Link styling for the vulnerability description and file location only appears when you hover over each link, and keyboard navigation has been improved.

These changes make the vulnerability report more intuitive and accessible.

Export a security dashboard as a PDF: Vulnerability Management

You can export the security dashboard as a PDF for use in reports and presentations. The export captures the current state of all of the charts and panels in the dashboard, including any active filters.

SAST scanning in security configuration profiles: Security Testing Configuration

In GitLab 18.9, we introduced security configuration profiles with the Secret Detection - Default profile. In GitLab 18.11, profiles now extend to SAST with the Static Application Security Testing (SAST) - Default profile, giving you a unified control surface to apply standardized static analysis coverage across all your projects without touching a single CI/CD configuration file.

The profile activates two scan triggers:

• Merge Request Pipelines: Automatically runs a SAST scan each time new commits are pushed to a branch with an open merge request. Results only include new vulnerabilities introduced by the merge request.
• Branch Pipelines (default only): Runs automatically when changes are merged or pushed to the default branch, providing a complete view of your default branch's SAST posture.

Security attribute filters in group security dashboards: Vulnerability Management

You can now filter the results in a group security dashboard based on the security attributes that you have applied to the projects in that group.

The available security attributes include the following:

• Business impact
• Application
• Business unit
• Internet exposure
• Location

Identifier list popover in the vulnerability report: Vulnerability Management

The vulnerability report now shows the primary CVE identifier as a clickable link in each row. When multiple identifiers exist, a "+N more" popover lists all of the identifiers. Each identifier in the list links to its external reference (for example, in the CVE, CWE, or WASC databases) so you can quickly access more details without leaving the report.

Premium

Default model for GitLab Duo Agentic Chat updated from Haiku 4.5 to Sonnet 4.6: Duo Agent Platform

We've made an update to improve your Agentic Chat experience in GitLab. The default model for Agentic Chat was upgraded from Claude Haiku 4.5 to Claude Sonnet 4.6, hosted on Vertex AI. Claude Sonnet 4.6 offers improved reasoning and response quality but uses a higher GitLab Credit multiplier than Haiku 4.5.

You can select an alternative model, including Haiku, using the model selection setting. If you've already selected a specific model, your choice is preserved. This update only affects the default and will not override any existing selections. For information about credit multipliers by model, see the GitLab Credits documentation.

Mistral AI now supported as a self-hosted model in GitLab Duo Agent Platform (self-managed only): Self-Hosted Models

GitLab Duo Agent Platform now supports Mistral AI as an LLM platform for self-hosted model deployments. GitLab Self-Managed customers can configure Mistral AI alongside existing supported platforms, including AWS Bedrock, Google Vertex AI, Azure OpenAI, Anthropic, and OpenAI. This gives teams more choice in how they run AI-powered features.

Enhanced GitLab Duo Agent Platform analytics on Duo and SDLC trends dashboard: DevOps Reports

The GitLab Duo and SDLC trends dashboard delivers improved analytics capabilities to measure the impact of GitLab Duo
on software delivery. The dashboard now includes new single stat panels for monthly Agent Platform unique users and Agentic Chat sessions.

Additionally, metrics previously displayed as a % usage compared to seat assignments have been updated to strictly report usage counts.

This change resolves the issue where counts were missing Agent Platform usage controlled under the new usage billing model.

View historical months in GitLab Credits dashboard: Consumables Cost Management

The GitLab Credits dashboard in Customers Portal now supports historical month navigation. Billing managers can browse past billing months to review daily usage trends, compare consumption patterns across periods, and reconcile usage with invoices. Previously, the dashboard only displayed the current billing month. With this improvement, administrators can make more informed decisions about credit allocation and forecast future needs based on historical data.

Set subscription-level usage cap for GitLab Credits: Consumables Cost Management

Administrators can now set a monthly usage cap for On-Demand Credits at the subscription level. When total on-demand credit consumption reaches the configured cap, GitLab Duo Agent Platform access is automatically suspended for all users on that subscription until the next billing period begins or the admin adjusts the cap. This setting gives organizations a hard guardrail against unexpected overage bills, removing a key barrier to broader Agent Platform rollout. Caps reset automatically each billing period, and administrators receive an email notification when the cap is reached.

Set per-user GitLab Credits cap: Consumables Cost Management

Administrators can now set an optional per-user usage cap for GitLab Credits per billing period. When an individual user's total credit consumption reaches the configured limit, GitLab Duo Agent Platform access is suspended only for that user, while other users continue unaffected. This prevents any single user from consuming a disproportionate share of the organization's credit pool, and gives administrators fine-grained control over usage distribution. Per-user usage caps work alongside subscription-level usage caps, by applying the cap that is reached first.

Plan

Epic weights: Portfolio Management

Epics now support weights, making it easier to estimate and prioritize large-scale
initiatives during planning.

Before breaking down an epic into child issues, you can assign a preliminary weight
to represent your initial estimate.

As you decompose the epic, the weight automatically updates to reflect the rolled-up total
from all child issues.

This is consistent with how weight rollup works for issues and tasks.

On the epic detail page, you can see both the preliminary weight and the rolled-up weight
from child issues, giving you the insight needed to refine estimates over time.

Core

GitLab Data Analyst Foundational Agent now generally available: Custom Dashboards Foundation

The Data Analyst Agent is a specialized AI chat assistant that helps you query, visualize, and surface data across the GitLab platform.

Backed by the GitLab Query Language (GLQL), the Data Analyst can retrieve and analyze data about each of the supported data sources, and provide clear, actionable insights about your software development health and engineering efficiency.

These insights can be visualized directly in the agent output and embedded directly into issues and epics for further evaluation.

Deploy Gitaly on Kubernetes (self-managed only): Gitaly

You can now deploy Gitaly on Kubernetes as a fully supported deployment method. This gives you greater flexibility in managing your GitLab infrastructure by using Kubernetes orchestration capabilities for scaling, high availability, and resource management. Previously, Kubernetes deployments required custom configurations and weren't officially supported, making it difficult to maintain reliable Gitaly deployments in containerized environments.

Configure tools in custom flow definitions: Duo Agent Platform

You can now configure tool options and parameter values directly in your custom flow definitions to supersede the LLM default values. This gives you more precise, consistent control over how tools behave within a custom flow, making it easier to enforce guardrails and specific parameter values across that flow.

ClickHouse is generally available for Self-Managed deployments: DevOps Reports

For GitLab Self-Managed instances, we now have improved recommendations and configuration guidance for the GitLab ClickHouse integration. Customers have options to bring their own cluster, or use the ClickHouse Cloud (recommended) setup option. This integration powers multiple dashboards and unlocks access to various API endpoints within the analytics space.

This scalable, high-performance database is part of the larger architectural improvements planned for the GitLab analytics infrastructure.

GLQL now has access to projects, pipelines, and jobs data sources: Custom Dashboards Foundation

The GitLab Query Language (GLQL) now has access to three new data sources: projects, pipelines, and jobs. These new data sources are also available as embedded views, letting teams surface pipeline results, job statuses, and project overviews directly in wikis, issue and merge request descriptions, and repository Markdown files.

GLQL also powers the Data Analyst Agent. With these new types, the agent can inspect CI/CD job results, debug failures, and provide detailed overviews of pipeline execution, as well as provide an accurate overview of projects in a namespace.

Kubernetes 1.35 support: Deployment Management

GitLab now fully supports Kubernetes version 1.35. If you want to deploy your applications to Kubernetes
and access all features, upgrade your connected clusters to the most recent version.

For more information, see supported Kubernetes versions for GitLab features.

Linux package improvements (self-managed only): Omnibus Package

In GitLab 19.0, the minimum-supported version of PostgreSQL will be version 17. To prepare for this change, on instances that don't use PostgreSQL Cluster, upgrades to GitLab 18.11 will attempt to automatically upgrade PostgreSQL to version 17.

If you use PostgreSQL Cluster or opt out of this automated upgrade, you must manually upgrade to PostgreSQL 17 to be able to upgrade to GitLab 19.0.

Backup and Restore Support for Container Registry Metadata Database (self-managed only): Backup/Restore of GitLab instances

The GitLab backup Rake task for Linux package installations and the backup-utility for Cloud Native (Helm) installations now support the container registry metadata database. You can now back up references to blobs, manifests, tags, and other data stored in the metadata database, enabling recovery in the event of malicious or accidental data corruption.

New navigation experience for groups in Explore: Groups & Projects

We're excited to announce improvements to the groups list in Explore, making it easier to discover groups across your GitLab instance.

The redesigned interface introduces a tabbed layout with two views:

• Active tab: Browse all accessible groups, helping you discover relevant communities and projects.
• Inactive tab: View archived groups and groups pending deletion for visibility into group lifecycle status.

These changes streamline group discovery and provide clearer visibility into which groups are available to join.

Asynchronous transfer of projects: Groups & Projects

In previous versions of GitLab, transfers of large groups and projects could timeout. As we move groups and projects to use a unified state model for operations such as transfer, archive, and deletion, you get more consistent behavior, better visibility into state history and audit details, and fewer timeouts, specifically, for long running transfer operations through asynchronous processing.

Plan

Wiki sidebar toggle repositioned for easier access: Wiki

The wiki sidebar toggle is now positioned on the left side, directly next to the sidebar it controls.

When the sidebar is collapsed, the toggle remains visible as a floating control so you can reopen it without scrolling back to the top of the page.

Sticky action bar on wiki pages: Wiki

The action bar on wiki pages is now sticky, so it remains visible as you scroll
through a page. Previously, you had to scroll back to the top to access actions
like editing, viewing page history, or managing templates. Now the page title
and key actions, including Edit, New page, Templates, Page history, and more,
stay within reach no matter how far down the page you are.

Verify

CI Expert Agent launches in beta: Pipeline Composition

The AI-powered CI Expert Agent is now available in beta. This agent helps teams get from GitLab code to a first working pipeline without starting from a blank .gitlab-ci.yml.

Using GitLab Duo Agent Platform, the agent inspects your repository, asks a few guided questions about your build and test process, and generates a ready-to-run pipeline you can review, edit, and commit.

This turns pipeline creation into a conversational, context-aware experience, while still letting you take full control of the YAML after you're ready to evolve and optimize your configuration.

Reconfigure inputs when manually running MR pipelines: Pipeline Composition

A powerful aspect of CI/CD inputs is that you can manually run new pipelines with new values for runtime customization.

This was not available in merge request (MR) pipelines before, but in this release you can now customize inputs in MR pipelines too.

After you configure inputs for MR pipelines, you can optionally modify those inputs and change the pipeline behavior any time you run a new pipeline for a merge request.

GitLab Runner 18.11: GitLab Runner Core

We're also releasing GitLab Runner 18.11 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:

• Create concrete helper image with bundled dependencies
• Read the job router feature flag from the runner configuration instead of an environment variable

Bug Fixes:

• Incorrect runner binary path after refactoring
• Pipeline hangs on cache operations
• The docker-machine binary in GitLab Runner 18.9.0 references CVE-2025-68121
• Runner silently falls back to job payload credentials when credential helper binary is missing from DOCKER_AUTH_CONFIG
• CONCURRENT_PROJECT_ID not unique in different jobs, which causes a conflict in the builds directory
• Artifact upload fails with timeout awaiting response headers
• User-defined after_script executes after failed pre_build_script and bypasses post_build_script

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

Package

Prefer mode for the container registry metadata database (self-managed only): Container Registry

You can now set the container registry metadata database to prefer mode, a new configuration option alongside the existing true and false values. In prefer mode, the registry automatically detects whether it should use the metadata database or fall back to legacy storage based on the current state of your installation.

If your registry has existing filesystem metadata that has not been imported to the database, the registry continues to use legacy storage until you complete a metadata import. If the database is already in use, or on a fresh installation, the registry uses the database directly.

In a later release, prefer mode will become the default for new Linux package installations. Existing installations will not be affected. For more information, see issue 595480.

Package protection rules now support Terraform modules: Package Registry

Teams publishing Terraform modules through the built-in GitLab Terraform module registry had
no way to restrict who could push new module versions. Package protection rules supported
several package formats but did not include terraform_module, leaving infrastructure
teams without a project-level push control.

You can now create package protection rules scoped to terraform_module, restricting push
access based on minimum role. Support is available in the UI package type dropdown, the
REST API, the GraphQL API, and the GitLab Terraform provider resource.

Release evidence now includes packages: Package Registry, Release Evidence

When creating a GitLab Release, packages published to the package registry were not
automatically associated with it. Teams had to manually construct package URLs and attach
them as release links through the API or pipeline scripts, adding friction and risk of
incomplete release records.

GitLab now automatically includes packages in release evidence when the package version
matches the release tag. This creates a verifiable, auditable link between your release and
its associated packages without any manual steps, keeping source code, artifacts, and
packages together in one complete release snapshot.

Software supply chain security

Create Service Account in subgroups and projects: System Access

Teams can now create service accounts in subgroups and projects. Instead of broad, top-level group bots, you can attach a dedicated service account to a single subgroup or project and manage its access like any other member of that namespace. Group and subgroup service accounts can be invited to the group where they were created or to any descendant subgroups and projects. Project service accounts are limited to their own project.

Service Accounts available on GitLab Free: System Access

Service accounts are now available on GitLab.com in all tiers. Previously limited to
Premium and Ultimate, service accounts let you perform automated actions, access data, or run
scheduled processes without tying credentials to individual team members. They're commonly used in
pipelines and third-party integrations where credentials must stay stable regardless of team
changes. On GitLab Free, you can create up to 100 service accounts per top-level group, including those
created in subgroups or projects.

Fine-grained permissions for personal access tokens now available (Beta): Permissions

Fine-grained personal access tokens (PATs) are now available in beta. Unlike legacy PATs, which grant access to every project and group you belong to, fine-grained PATs let you limit each token to specific resources and actions. This reduces the potential impact of a leaked or compromised token.

Your existing PATs continue to work as before, and you can still create legacy PATs without fine-grained permissions.

This beta release covers approximately 75% of the GitLab REST API. Full REST API coverage, GraphQL enforcement, and administrator policy controls are planned for the GA release.

To share feedback, see epic 18555.

Security risk management

Security Manager role (Beta): Permissions

The Security Manager role is now available as a beta feature, providing a new default set of permissions designed specifically for security professionals. Security teams no longer need Developer or Maintainer roles to access security features, eliminating over-privileging concerns while maintaining separation of duties.

Users with the Security Manager role have the following access:

• Vulnerability management: View, triage, and manage vulnerabilities across groups and projects, including vulnerability reports and security dashboards.
• Security inventory: View a group's security inventory to understand scanner coverage across all projects.
• Security configuration profiles: View security configuration profiles for a group.
• Compliance tools: View audit events, compliance center, compliance frameworks, and dependency lists for a group or project.
• Secret push protection: Enable secret push protection for a group.
• On-demand DAST: Create and run on-demand DAST scans for a group.

To get started, go to a group and select Manage > Members to invite and assign members to the Security Manager role.

Original source

Ultimate

Verify

Runner controllers for job admission control (self-managed only): GitLab Runner Core

You can now enforce custom policies on CI/CD jobs before runner assignment with runner controllers.

The runner controller connects to the job router and makes admit or reject decisions based on custom rules.

Use runner controllers for admission control, compliance enforcement, or cost and resource governance.

Controllers support instance runners and a dry-run mode for safe validation before enforcement.

This feature is an experiment.

To get started, see Tutorial: Build a runner admission controller.

Application security testing

Dependency Scanning with SBOM support for Java Gradle build files: Software Composition Analysis

GitLab dependency scanning by using SBOM now supports scanning Java build.gradle and build.gradle.kts build files.

Previously, dependency scanning for Java projects using Gradle required a lock file to be present.

Now, when a lock file is not available, the analyzer automatically falls back to scanning build.gradle and build.gradle.kts files, extracting and reporting only direct dependencies for vulnerability analysis.

This improvement makes it easier for Java projects using Gradle to enable dependency scanning without requiring a lock file.

To enable manifest fallback, set the DS_ENABLE_MANIFEST_FALLBACK CI/CD variable to "true".

Dependency scanning SBOM-based scanning extended to self-managed: Software Composition Analysis

In GitLab 18.10, we're extending limited availability status to self-managed instances for the new SBOM-based dependency scanning feature.

This feature was initially released in GitLab 18.5 with limited availability for GitLab.com only, behind the feature flag dependency_scanning_sbom_scan_api and disabled by default.

With additional improvements and fixes, we now have confidence to reliably use the new SBOM scanning internal API and enable this feature flag by default.

This internal API allows the dependency scanning analyzer to generate a dependency scanning report containing all component vulnerabilities.

Unlike the previous behavior (Beta) that processed SBOM reports after CI/CD pipeline completion, this improved process generates scan results immediately during the CI/CD job, giving users instant access to vulnerability data for custom workflows.

Self-managed customers who encounter issues can disable the dependency_scanning_sbom_scan_api feature flag. The analyzer will then fall back to the previous behavior.

To use this feature, import the v2 dependency scanning template Jobs/Dependency-Scanning.v2.gitlab-ci.yml.

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

License scanning support for Dart/Flutter projects using Pub package manager: Software Composition Analysis

GitLab now supports license scanning for Dart and Flutter projects that use the pub package manager.

Previously, teams building with Dart or Flutter were unable to identify the licenses of their open source dependencies directly within GitLab, creating compliance blind spots for organizations with license policy requirements.

License data is sourced directly from pub.dev, the official Dart package repository, and results are surfaced alongside other supported ecosystems.

Dart/Flutter dependency scanning and vulnerability detection were already supported.

Software supply chain security

SAST false positive detection with GitLab Duo Agent Platform: Vulnerability Management

SAST false positive detection, which was first introduced as a beta in GitLab 18.7, is now generally available in GitLab 18.10.

When a security scan runs, GitLab Duo Agent Platform analyzes each critical and high severity SAST vulnerability and determines the likelihood that it's a false positive.

The assessment appears directly in the vulnerability report, giving teams the context they need to triage with confidence rather than uncertainty.

Key capabilities include:

• Automatic analysis: False positive detection runs automatically after each security scan with no manual intervention required.
• Manual option: Users can manually run false positive detection for individual vulnerabilities on the vulnerability details page for on-demand analysis.
• Focus on high-impact findings: Limiting the analysis to critical and high severity SAST vulnerabilities cuts through the noise where it matters most.
• Contextual AI reasoning: Each assessment explains why a finding may or may not be a false positive, factoring in code context, data flow, and vulnerability characteristics specific to static analysis.
• Seamless workflow integration: Results surface directly in the vulnerability report alongside existing severity, status, and remediation information — no changes to existing workflows required.

This feature is available for Ultimate customers with GitLab Duo Agent Platform. The feature must be enabled in your group or project settings.

We welcome your feedback in issue 583697.

Secret false positive detection with AI (beta): Vulnerability Management, Secret Detection

Security teams spend significant time investigating secret detection findings that turn out to be false positives. For example, test credentials, example values, and placeholder tokens that are incorrectly flagged as actual secrets.

False positives create alert fatigue, erode trust in scan results, and divert attention from genuine security risks.

GitLab 18.10 introduces AI-powered secret false positive detection (beta) to focus on the secrets that actually matter.

When a security scan runs, GitLab Duo automatically analyzes each Critical and High severity secret detection vulnerability to determine if it's a false positive.

The AI assessment appears directly in the vulnerability report, giving security engineers immediate context to make faster and confident triage decisions.

Key capabilities include:

• Automatic analysis: False positive detection runs automatically after each security scan without manual trigger.
• Manual trigger option: You can manually trigger false positive detection for individual vulnerabilities on the vulnerability details page for on-demand analysis.
• Focus on high-impact findings: Scoped for Critical and High severity vulnerabilities to maximize signal-to-noise improvement.
• Contextual AI reasoning: Each assessment includes an explanation of why the finding may or may not be a true positive, based on code context and vulnerability characteristics.
• Confidence scoring: Each detection includes a confidence score to help teams prioritize review based on the model's certainty.
• Seamless workflow integration: Results surface directly in the vulnerability report alongside existing severity, status, and remediation information.

This feature is available as a free beta for Ultimate customers and must be enabled in your group or project settings.

Share feedback in issue 592861.

Security risk management

Pipeline secret detection in security configuration profiles: Vulnerability Management

In GitLab 18.9, we introduced security configuration profiles with the Secret Detection - Default profile, starting with push protection. You use the profile to apply standardized secret scanning across hundreds of projects without touching a single CI/CD configuration file.

The Secret Detection - Default profile now also covers pipeline-based scanning, providing a unified control surface for secret detection across your entire development workflow.

The profile activates three scan triggers:

• Push Protection: Scans all Git push events and blocks pushes where secrets are detected, preventing secrets from ever entering your codebase.
• Merge Request Pipelines: Automatically runs a scan each time new commits are pushed to a branch with an open merge request. Results only include new vulnerabilities introduced by the merge request.
• Branch Pipelines (default only): Runs automatically when changes are merged or pushed to the default branch, providing a complete view of your default branch's secret detection posture.

Applying the profile requires no YAML configuration. The profile can be applied to a group to propagate coverage across all projects in the group, or to individual projects for more granular control.

Premium

Custom agents can use MCP to access external data: AI Catalog

You can now connect custom agents in the AI Catalog to external data sources and tools through the Model Context Protocol (MCP), without leaving GitLab.

This feature is an experiment. Share your feedback in issue 593219.

GitLab MCP server tool for pipeline management: MCP Server

You can now manage your CI/CD pipelines in a GitLab project with the new manage_pipeline tool.

This GitLab MCP server tool lets AI agents create, cancel, retry, delete, and update pipeline metadata in a single call.

With this tool, you no longer have to piece together multiple steps to automate your pipeline workflows.

If you want to see other GitLab MCP sever tools, let us know in the feedback issue.

Project Maintainers can enable custom agents and flows: AI Catalog

Previously, enabling AI agents and flows from the AI Catalog required top-level group permissions.

Now, when browsing the AI Catalog at the explore level or project level, project Maintainers can enable agents and flows directly in their projects.

Configure network access control for remote flows in projects: Duo Agent Platform

You can now configure network access controls for flows using GitLab runners in projects.

This provides secure external integrations, while maintaining control over network destinations. This also gives project maintainers the flexibility to allow necessary API connections, MCP servers, and third-party services while enforcing security boundaries.

Configure network access controls in the network_policy section of agent-config.yml. The agent-config.yml is protected by branch protection rules and MR approval workflows.

Self-hosted Vertex AI for GitLab Duo Agent Platform (self-managed only): Self-Hosted Models

Vertex AI is now a supported LLM platform within GitLab Duo Agent Platform Self-Hosted.

Customers can now configure Anthropic models hosted on Vertex AI for use with GitLab Duo Agent Platform features.

Users can enable agents and flows directly from projects: AI Catalog

Maintainers and Owners can now enable agents and flows directly from their project or the explore page, without navigating away from their current context.

Top-level group Owners can also select their group, and the specific projects where they want to activate agents and flows, streamlining their workflow setup.

Support for Agent Skills in IDEs and CI/CD pipelines: Duo Agent Platform

GitLab Duo Agent Platform now supports the Agent Skills specification,

an emerging standard for giving AI agents new capabilities and expertise.

You can define Agent Skills at the workspace level for your project

to give agents specialized knowledge and workflows for specific tasks, like writing

tests in a specific framework. Agents automatically discover and load relevant skills

as they encounter matching tasks.

You can also trigger skills manually by name, file path, or custom slash commands.

Agent Skills are accessible for flows and Agentic Chat in your IDE, and for

flows run in CI/CD pipelines. They also work with any other AI tool that supports

the specification.

Download credit usage data as CSV: Consumables Cost Management

Billing managers can now download credit usage data as a CSV file directly from the GitLab Credits dashboard in Customers Portal.

The export provides a daily, per-action breakdown of credit consumption for the current billing month, including commitment, waiver, trial, on-demand, and included credits used.

Finance and operations teams can use this data to perform cost allocation, chargeback reporting, and usage analysis in Excel, Google Sheets, or BI tools without manual data gathering or support requests.

Link credit usage to GitLab Duo Agent Platform sessions: Consumables Cost Management

The GitLab Credits dashboard now links credit consumption directly to the GitLab Duo Agent Platform session that generated it.

In the per-user drill-down view, the Action column for Agent Platform usage rows (such as Agentic Chat or Foundational Agents) is now a clickable hyperlink that navigates to the corresponding session details.

This link provides a direct audit trail from billing to AI session behavior, so administrators can investigate credit usage, support escalations, and compliance reviews without manually correlating timestamps across separate systems.

Sort users in the GitLab Credits dashboard: Consumables Cost Management

Enterprise administrators can now sort the Usage by User table in the GitLab Credits dashboard by total credits used or by username.

The default sort order is by total credits consumed (highest first), so the top consumers are immediately visible without scrolling.

With this view, administrators managing thousands of GitLab Duo users can quickly identify high-usage individuals for cost allocation, chargeback reporting, and license utilization audits.

Create

Enforce merge request title naming conventions with regex: Code Review Workflow

Maintaining consistent merge request titles is important for teams that rely on structured

naming conventions. Whether that's following the Conventional Commits format,

or linking to an internal tracking system. Teams previously needed external tooling or

custom CI/CD pipeline jobs to enforce these conventions, but this approach had a

critical gap. If someone changed the merge request title after the pipeline ran, there was no

re-validation, and the MR could still be merged with a non-compliant title.

You can now configure a required title regex for merge requests in your project settings.

When configured, GitLab evaluates the merge request title against the pattern as a

mergeability check — blocking the merge until the title is updated to comply, regardless

of when the title was last changed.

To set this up, go to your project's Settings > Merge requests and enter a regex

pattern in the Merge request title must match regex field.

Your existing merge request workflows continue to work as before. This check only

applies to projects where you explicitly configure a title regex.

Verify

macOS Tahoe 26 and Xcode 26 job image: GitLab Hosted Runners

You can now create, test, and deploy applications for the newest

generations of Apple devices using macOS Tahoe 26 and Xcode 26.

With hosted runners on macOS,

your development teams can build and deploy macOS applications faster in a secure,

on-demand build environment integrated with GitLab CI/CD.

Try it out today by using the macos-26-xcode-26 image in your .gitlab-ci.yml file.

Package

Manage container virtual registries with a dedicated UI (Beta): Virtual Registry

When the container virtual registry launched in beta last milestone, platform engineers could aggregate multiple upstream container registries — Docker Hub, Harbor, Quay, and others — behind a single pull endpoint. However, all configuration required direct API calls, meaning teams had to maintain scripts or manual curl commands to create and manage their registries, configure upstreams, and handle changes over time. This added operational overhead and made the feature inaccessible to users who weren't comfortable working directly with the API.

Container virtual registries can now be created and managed directly from the GitLab UI. From the group-level container registry page, you can create new virtual registries, configure upstream sources with authentication credentials, edit existing configurations, and delete registries you no longer need — all without leaving GitLab or writing a single API call. The UI integrates seamlessly with the existing container registry experience, making virtual registries a first-class part of your group's artifact management workflow.

This feature is in beta. To share feedback, please comment in the feedback issue.

Core

Purchase GitLab Credits on the Free tier on GitLab.com: Subscription Management

Free tier group Owners on GitLab.com can now unlock AI with GitLab Credits. Purchase a monthly credit amount, commit to an annual term, and get access to GitLab Duo Agent Platform agents and flows. Credits refresh automatically each month, so your team always has what it needs to build faster and smarter.

Key highlights:

• Usage-based pricing: Purchase a monthly credit commitment without needing a base plan subscription.
• Self-service purchasing: Buy credits through the GitLab purchase flow.
• Seamless upgrade path: Your credit commitment transfers if you later upgrade to Premium or Ultimate.
• Consumption tracking: Monitor your credit usage through the GitLab Credits dashboard.

This purchase option is currently only available for free GitLab.com top-level groups.

GitLab Blob Search for group and instance code search: Duo Agent Platform

The gitlab_blob_search tool now enables GitLab AI agents to search your code:

• Across all projects in a group.
• Across all accessible projects on an instance.

Previously, blob search was limited to a single project, or required specifying explicit project IDs. This change makes it easier for AI-powered workflows to discover and reuse code that's spread across multiple related projects.

New navigation experience for projects in Explore: Groups & Projects

We've streamlined the projects page in Explore to reduce clutter and remove redundant options that accumulated over time.

The simplified interface now focuses on two core views:

• Active tab: Discover projects with recent activity and ongoing development.
• Inactive tab: Access archived projects and those scheduled for deletion.

We've removed several redundant tabs:

• Most starred projects can be found by sorting Active or Inactive tabs by star count.
• All projects are available by viewing both Active and Inactive tabs.
• Trending tab will be fully removed in GitLab 19.0 due to limited functionality and low usage.

The cleaner design aligns with other project lists for visual consistency. You can still access all the same content through more logical organization and flexible sorting options.

Plan

Introducing the work items list and saved views: Portfolio Management

The GitLab planning experience is getting a significant upgrade with the work items list and saved views,

bringing together two long-requested capabilities:

• The work items list combines epics, issues, and other work items into a single unified list,
  eliminating the need to switch between separate pages for different work item types.
• This makes it easier to understand relationships across your planning objects.
• Saved views allow you to create and save customized list configurations, including filters,
  sort order, and display options. This makes routine checks more efficient, and supports standardized
  ways of viewing work across your team.

This is the next step in the GitLab work items journey, a unified architecture designed to deliver

consistency and unlock new capabilities across GitLab planning tools.

Share your thoughts and feedback in issue 590689.

Task item support in Markdown tables: Markdown

You can now use task item checkbox syntax directly in Markdown table cells.

Previously, achieving this required a combination of raw HTML and Markdown, which was

cumbersome and difficult to maintain.

This improvement makes it easier to track task completion directly within structured table

layouts in issues, epics, and other content.

Verify

Use runtime inputs with CI/CD jobs: Pipeline Composition

Using CI/CD variables for dynamic job configuration can be challenging. Variables follow a complex override hierarchy that's difficult to manage, and they can't be used for a variety of use cases.

Now you can use inputs to define explicit, typed inputs at the job level. Use job inputs to define and control the values that a job accepts at runtime. With job inputs, you get:

• Type safety (string, number, boolean, array).
• Default values that can be static or reference existing variables.
• The option to define a strict list of possible values to use.
• Regex support for validating input values.

Job inputs can use the default values without any user interaction, but you can modify the values when retrying a job or running a manual job.

GitLab Runner 18.10: GitLab Runner Core

We're also releasing GitLab Runner 18.10 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:

• Allow k8s runner to define Pod Level Resources for build pod
• Add automation to update Go versions and packages for all Runner projects

Bug Fixes:

• S3 cache with RoleARN returns 403 instead of 404 for non-existent cache
• Using helper image gitlab-runner-helper:x86_64-v16.11.1-nanoserver21H2 results in init-permissions error
• MacOS: LaunchAgent - Service could not initialize on M1 architecture

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

Package

Conan 2.0 package registry support (Beta): Package Registry

C and C++ development teams using Conan as their package manager have long requested registry support in GitLab. Previously, the Conan package registry was experimental and only supported Conan 1.x clients, limiting adoption for teams that have migrated to the modern Conan 2.0 toolchain.

The Conan package registry now supports Conan 2.0 and has been promoted from Experimental to Beta. This release includes full v2 API compatibility, recipe revision support, improved search capabilities, and proper handling of upload policies including the --force flag. Teams can publish and install Conan 2.0 packages directly from GitLab using standard Conan client workflows, reducing the need for external artifact management solutions like JFrog Artifactory.

With this update, platform engineering teams managing C and C++ dependencies can consolidate their package management within GitLab alongside their source code, CI/CD pipelines, and security scanning. The Conan registry supports both project-level and instance-level endpoints, and works with personal access tokens, deploy tokens, and CI/CD job tokens for authentication.

We welcome feedback as we work toward general availability. Please share your experience in the epic.

GitLab Helm Chart registry generally available: Package Registry

Teams using Helm to manage Kubernetes application deployments can now rely on the GitLab Helm Chart registry for production workloads. Previously in beta, the registry is now generally available following the resolution of key architectural and reliability concerns.

The path to GA included resolving a hard limit that prevented the index.yaml endpoint from returning more than 1,000 charts, fixing a background indexing bug that caused newly published chart versions to be missing from the index, completing a full AppSec security review, and adding Geo replication support for Helm metadata cache, ensuring high availability for self-managed customers running GitLab Geo.

Platform and DevOps teams can publish and install Helm charts directly from GitLab using standard Helm client workflows, with support for project-level endpoints and authentication using personal access tokens, deploy tokens, and CI/CD job tokens. Now you can keep charts alongside the source code, pipelines, and security scanning that depend on them.

Software supply chain security

Sign in securely with passkeys: System Access

GitLab now supports passkeys for passwordless sign-in and as a phishing-resistant two-factor authentication (2FA) method. Passkeys use public-key cryptography and biometric authentication (fingerprint, face recognition) or your device PIN to securely access your account.

Passkeys offer the following benefits:

• Passwordless convenience: Sign in with your device's biometrics or PIN instead of remembering a password.
• Multi-device support: Use passkeys on desktop browsers, mobile devices (iOS 16 or later, Android 9 or later), and FIDO2/WebAuthn-compatible hardware security keys.
• Phishing-resistant security: Your private key never leaves your device. GitLab only stores the public key, protecting your account even if GitLab servers are compromised.
• Automatic 2FA integration: For accounts with 2FA enabled, passkeys become available as your default 2FA method.

To get started, add a passkey in your account settings. We welcome your questions and feedback in issue 366758.

Original source

Ultimate

GitLab Duo Agent Platform available in Ultimate trials: Acquisition, Duo Agent Platform

Teams evaluating GitLab can now test agentic AI capabilities that automate complex development workflows and reduce manual tasks. Sign up for a GitLab Ultimate trial and get access to Duo Agent Platform with 24 evaluation credits per user, enabling hands-on experience with autonomous task execution and multi-step workflow orchestration during a 30-day evaluation. Evaluation credits are available for 30 days from the provision date, so consider your team's readiness before starting.

Start your free trial. Current paid customers can access evaluation credits through their account team. Contact Sales to learn more.

Application security testing

Dependency Scanning with SBOM support for Java pom.xml manifest files: Software Composition Analysis

GitLab dependency scanning by using SBOM now supports scanning Java pom.xml manifest files.

Previously, dependency scanning for Java projects using Maven required a graph file to be present.

Now, when a graph file is not available, the analyzer automatically falls back to scanning pom.xml files, extracting and reporting only direct dependencies for vulnerability analysis.

This improvement makes it easier for Java projects to enable dependency scanning without requiring a graph file.

To enable manifest fallback, set the DS_ENABLE_MANIFEST_FALLBACK CI/CD variable to "true".

Dependency Scanning with SBOM support for Python requirements.txt manifest files: Software Composition Analysis

GitLab dependency scanning by using SBOM now supports scanning Python requirements.txt manifest files.

Previously, dependency scanning for Python projects required a lock file to be present.

Now, when a lock file is not available, the analyzer automatically falls back to scanning requirements.txt files, extracting and reporting only direct dependencies for vulnerability analysis.

This improvement makes it easier for Python projects to enable dependency scanning without requiring a lock file.

To enable manifest fallback, set the DS_ENABLE_MANIFEST_FALLBACK CI/CD variable to "true".

Software supply chain security

Vulnerability resolution with GitLab Duo Agent Platform (Beta): Vulnerability Management

Triaging and remediating SAST vulnerabilities is one of the most time-consuming tasks in application security. After identifying a real vulnerability, developers need to understand the finding, locate the affected code, and write an appropriate fix. All of which take time and specialized knowledge.

In GitLab 18.9, we're introducing Agentic SAST Vulnerability Resolution. When you trigger resolution for a SAST vulnerability, GitLab Duo autonomously analyzes the finding, reasons through the surrounding code context, generates a context-aware fix, and creates a merge request without any manual intervention.

Key capabilities include:

Agentic multi-step resolution: Rather than producing a single code suggestion, the GitLab Duo Agent Platform reasons through the vulnerability, evaluates the codebase, and produces a well-informed fix.

Automatic merge request creation: Generates a ready-to-review merge request with the proposed code fix for critical and high severity SAST vulnerabilities.

Quality scoring: Each generated fix includes a quality assessment so reviewers can quickly gauge confidence in the proposed remediation.

SAST vulnerability resolution is available from the vulnerability report and the individual vulnerability details pages. You can trigger a resolution directly from the individual vulnerability details page.

This feature is available as a free beta for Ultimate customers. We welcome your feedback in issue 585626.

Security risk management

New security dashboard chart: Vulnerabilities by age: Vulnerability Management

The new Vulnerabilities by age chart helps you understand how long vulnerabilities have been open in your environment.

The chart shows the distribution of unresolved vulnerabilities based on the amount of time since they were first detected. You can group vulnerabilities by severity or by report type, helping you identify where remediation activities may be needed.

Centralized security governance and configuration: Vulnerability Management

Manage and visualize security scanner coverage across your organization. This release introduces security configuration profiles, starting with the secret detection profile.

Security teams now have a more powerful command center to secure your organization at scale.

Profile-based security configuration

Instead of manually editing YAML files for each project, you can now use preconfigured security configuration profiles that provide several advantages:

Standardized governance: Preconfigured profiles apply appropriate boundaries without interrupting productivity. You can apply standardized security best practices, without requiring custom role configurations.

Scalable management: Apply the same profile across hundreds or thousands of projects with a single action.

The secret detection profile is the first security configuration profile available. It provides the following advantages:

Actively identifies and blocks secrets from being committed to your repositories.

One profile manages secret detection across your entire development workflow. No need to manage separate configurations for different trigger types.

Enhanced security inventory

The security inventory has been upgraded to act as your primary dashboard to assess each group's security posture:

Group and project hierarchies: Easily distinguish between subgroups and projects in the inventory with clear iconography.

Bulk actions: A new Bulk Action menu allows you to apply or disable security scanner profiles across all selected projects and subgroups simultaneously.

Visual coverage status: Quickly identify gaps with color-coded status bars (Enabled, Not Enabled, or Failed) with tooltips for details.

Profile status indicators: See which trigger types are available in the profile details.

Security attributes: Security Asset Inventories

Security attributes, introduced as a beta in GitLab 18.6, are now generally available.

Security attributes allow security teams to apply business context to their projects, including business impact, application, business unit, internet exposure, and location. You can also create custom attribute categories to match your organization's taxonomy. By applying these attributes, you can filter and prioritize the items in your security inventory based on risk posture and organizational context.

Security dashboards: Vulnerabilities over time chart improvements: Vulnerability Management

The Vulnerabilities over time chart is updated to provide a more accurate view of your vulnerability inventory.

The chart previously included vulnerabilities that were no longer detected, leading to inflated numbers that did not accurately represent the state of active vulnerabilities.

We are aware of two additional issues that may slightly alter counts in some cases. Follow issue 590022 and issue 590018 for updates.

Premium

GitLab Duo Agent Platform Self-Hosted models now available for cloud licenses (self-managed only): Self-Hosted Models

GitLab Duo Agent Platform is now generally available for GitLab Self-Managed customers with a cloud license. Billing for this feature is usage-based.

Administrators can configure compatible models for use with GitLab Duo Agent Platform. Administrators using AWS Bedrock or Azure OpenAI can also configure Anthropic Claude or OpenAI GPT models.

Not yet on Ultimate? Start a free trial with Duo Agent Platform included.

Non-billable Minimal Access users (self-managed only): Seat Cost Management

Previously, organizations that used identity providers to automate user provisioning on GitLab Self-Managed Premium might run into a potential problem. When identity provider syncs attempt to add users beyond the licensed seat limit, administrators must either purchase extra seats for users who don't need active access, or manually intervene to prevent failures.

Now, users with the Minimal Access role on GitLab Self-Managed Premium subscriptions no longer count as billable seats, bringing them in line with how minimal access works on GitLab.com Premium, GitLab.com Ultimate, and GitLab Self-Managed Ultimate.

This change unlocks the restricted access feature, which automatically assigns the Minimal Access role to users who would otherwise exceed the seat limit during identity provider syncs. This change keeps syncs running smoothly without unexpected billing overages or manual intervention.

Geo data management view on primary site (self-managed only): Disaster Recovery, Geo Replication

You can now troubleshoot and verify data integrity directly from the primary site, thanks to the new data management view that brings detailed verification status information to the primary Geo site. This enhancement eliminates the need to access secondary sites for basic verification and troubleshooting tasks.

Previously, this verification status was only accessible through the secondary site UI. Now, with the data management view on the primary site, you can:

View detailed verification status for all replicable data types on the primary site

Perform data sanitization and troubleshooting tasks directly from the primary UI

Set up and verify your Geo configuration on the primary site before adding secondary sites

This enhancement is the first step toward comprehensive self-serve troubleshooting with the UI, reducing the need to access multiple sites for routine maintenance and issue resolution.

OAuth support in JetBrains IDEs for Self-Managed and Dedicated (self-managed only): Editor Extensions

The GitLab Duo plugin for JetBrains IDEs now supports OAuth authentication for GitLab Self-Managed and GitLab Dedicated. This means all JetBrains users can now enjoy a faster, more secure sign-in experience. No personal access token required.

Create

Restrict personal snippets for enterprise users: Source Code Management

Organizations using GitLab.com need to ensure that enterprise users don't accidentally expose sensitive code through personal snippets.

Previously, there was no way to prevent users from creating snippets in their personal namespace, which can pose a security risk if snippets are inadvertently set to public.

Group Owners can now restrict personal snippet creation for enterprise users, helping maintain tighter control over where code is shared.

When restricted, enterprise users cannot create snippets in their personal namespace.

Verify

View CI/CD job metrics for projects (limited availability): Fleet Visibility

GitLab CI/CD analytics now combines CI/CD pipeline and CI/CD job performance trends, which enables developers to identify inefficient or problematic CI/CD jobs quickly. These capabilities are included directly in the GitLab UI, so developers have the tools they need in context to identify and fix CI/CD performance problems that can significantly impact development teams' velocity and overall productivity. For platform administrators, the CI/CD jobs data in this view also reduces the need to rely on external or custom-built CI/CD observability solutions when you operate GitLab at an enterprise scale.

Package

Container virtual registry now available (Beta): Virtual Registry

Modern container-based development requires accessing images from multiple registries including Docker Hub, Harbor, Quay, and private registries. Without a container virtual registry, platform engineers must configure each project and CI/CD pipeline to authenticate with and pull from multiple registries individually. This creates configuration complexity, slows pulls with sequential registry queries, and makes it difficult to implement consistent security policies across container sources.

The container virtual registry addresses these challenges by aggregating multiple upstream container registries behind a single endpoint. Platform engineers can configure Docker Hub, Harbor, Quay, and other registries with long-lived token authentication through one URL. Intelligent caching improves pull performance while integrating with the GitLab authentication systems for centralized access control and audit logging.

The container virtual registry API is currently available in beta for GitLab Premium and Ultimate customers. Beta participants can use the GitLab API to create container virtual registries, configure multiple upstream sources with shareable configurations, and pull container images through the virtual registry. Please note the beta does not support registries that require IAM authentication. Support for cloud provider registries requiring IAM authentication is tracked in this epic.

On GitLab.com, this feature is behind a feature flag. To request access or share feedback, please comment in the feedback issue.

Core

Zero Downtime Upgrades now supported for Cloud Native Hybrid deployments (self-managed only): Cloud Native Installation

Zero Downtime Upgrades are now officially supported for Cloud Native Hybrid deployments.

Enterprise customers require their DevSecOps platform to be available at all times, making upgrade-related downtime a significant operational concern.

Until now, Zero Downtime Upgrades were only supported for Linux package-based high availability deployments, which drove many customers toward VM-based architectures even when cloud-native Kubernetes deployments would have better suited their infrastructure strategy.

We've been upgrading our own Cloud Native Hybrid SaaS instances with zero downtime for years.

With this release, we're bringing that same operational experience to self-managed customers running GitLab on Kubernetes.

The upgrade procedure has been comprehensively tested and is now fully documented, giving you the confidence to maintain availability during version upgrades.

Archive a group and its content: Groups & Projects

Managing completed initiatives and abandoned projects is now easier.

You can now archive entire groups, including all subgroups and projects, in one action, eliminating the need to manually archive each project individually.

When you archive a group:

All nested subgroups and projects are automatically archived.

Archived content moves to the Inactive tab with clear status badges.

Group data remains fully accessible in read-only mode for reference or restoration.

Write permissions are disabled across the archived group and its content.

Beyond the Settings page, you can archive groups and projects directly from the actions menu in list views. No more navigating through multiple screens for simple administrative tasks.

This highly requested feature dramatically reduces administrative overhead while keeping your workspace organized with clear separation between active and inactive work.

Share your feedback in epic 18616.

Valkey as replacement option for Redis (Beta) (self-managed only): Omnibus Package

Starting with GitLab 18.9, Valkey is bundled as an opt-in replacement for Redis in the Linux package.

Redis changed their license to AGPLv3, which is not suitable for open source customers. To guarantee security and maintainability for our GitLab Self-Managed customers, we are transitioning from Redis to Valkey, a community-driven fork that maintains the permissive BSD license.

Transition timeline:

GitLab 18.9 (this release): Valkey is bundled as an opt-in replacement (beta). You can switch from Redis to Valkey at your convenience. Valkey Sentinel support is included.

GitLab 19.0 (May 2026): Valkey becomes the default and Redis binaries are removed from the Linux package. Existing Redis configuration settings remain functional and are honored for backwards compatibility.

This transition only affects the bundled Redis in Linux packages. Customers on scaled architectures using external Redis deployments can continue to use Redis.

We are monitoring the potential feature divergence between Redis and Valkey and will provide guidance as the ecosystem evolves.

Create

Navigate repositories with collapsible file tree: Source Code Management

You can now browse repository files with a collapsible file tree. The tree provides a comprehensive view of your project structure, so you can expand and collapse directories inline, jump between files in different parts of your repository, and maintain context while you work.

The file tree appears as a resizable sidebar when you view repository files or directories.

You can toggle visibility with keyboard shortcuts, filter files by name or extension, and navigate through complex project hierarchies. The tree synchronizes with your current location, so when you select a file in the main content area, the tree updates to show that file.

Your existing repository structure and file organization remain unchanged. With fewer page loads required to move between files, this feature scales from small projects to large codebases with thousands of files.

Web-based commit signing on GitLab.com: Source Code Management

Ensuring commits are cryptographically signed is essential for code integrity and meeting compliance requirements. Previously, web-based commit signing was only available for GitLab Self-Managed.

GitLab.com now supports web-based commit signing. When enabled for a group or project, commits created through the GitLab web interface are automatically signed with the GitLab signing key and are displayed with a Verified badge, providing cryptographic proof of authenticity for your repositories.

Key details:

Enable in group or project settings based on your requirements.

All web-based commits (Web IDE edits, merges, API operations) are automatically signed when enabled.

This brings the GitLab.com security capabilities in line with GitLab Self-Managed and provides the foundation for comprehensive commit signing policies across your organization.

Rapid Diffs improves performance for commit changes: Source Code Management

Reviewing commits with many changed files or substantial modifications can be slow.

Rapid Diffs technology now powers the commits page (/-/commits/<SHA>), delivering faster loading times, smoother scrolling, and more responsive interactions.

With Rapid Diffs, you'll notice:

A pagination-free experience.

Faster initial load, so you can start working with code sooner.

A refreshed interface with a new file browser for quicker navigation between files.

Responsive interactions, even with large numbers of changed files.

All existing functionality is preserved. As Rapid Diffs expands to other areas of GitLab, the same performance benefits will follow.

Support for Bitbucket Cloud API tokens in import API: Importers

The GitLab import API now supports Bitbucket Cloud API tokens, providing a more secure way to import repositories from Bitbucket Cloud.

Atlassian has deprecated app passwords in favor of API tokens, and we're planning to remove support for app passwords in 19.0.

Importing from Bitbucket Cloud through the GitLab UI is not affected by this change.

Verify

Include CI/CD inputs from a file: Pipeline Composition

Previously, pipeline inputs could only be defined directly within a pipeline's spec section. This limitation made it challenging to reuse input configuration across multiple projects.

In this release you can now include input definitions from external files using the familiar include keyword. Being able to maintain a list of inputs in a separate place helps you have a manageable solution across many projects or pipelines. You can maintain centralized input configurations and even dynamically manage input values from external sources.

Add timestamps to CI job logs: Continuous Integration (CI)

You can now view timestamps on each CI job log line to identify performance bottlenecks and debug long-running jobs. Timestamps are displayed in UTC format. Use timestamps to troubleshoot performance issues, identify bottlenecks, and measure the duration of specific build steps. Requires GitLab Runner 18.7 or later for GitLab Self-Managed.

CI/CD Catalog component analytics: Pipeline Composition

Previously, teams lacked visibility into how CI/CD Catalog component projects were being used across their organization. Now you can view usage counts and adoption patterns at a high level, helping you understand which component projects are most valuable and optimize your catalog investments.

View security reports from child pipelines in merge requests: Continuous Integration (CI)

You can now view security and compliance reports from child pipelines directly in merge request widgets. Previously, you had to manually navigate through multiple pipelines to identify security issues, creating inefficient workflows especially with monorepos and complex testing setups.

With this enhancement, the merge request widget displays reports from child pipelines directly alongside parent pipeline results, with each child pipeline's reports presented individually and artifacts available for download. This provides a unified view of all security checks, significantly reducing time spent investigating failures and enables faster merge request reviews when using parent-child pipelines.

Original source

Software supply chain security

Centralized credential management API for group owners (SaaS only): System Access

The Credentials Inventory API is now available for Enterprise users on GitLab.com. This adds credential management capabilities previously only available on self-hosted instances, and enables organizations to better manage and secure their authentication tokens and keys.

The Credentials Inventory API provides programmatic access to view credentials across your organization, including:

• Personal Access Tokens (PATs)
• Group Access Tokens (GrATs)
• Project Access Tokens (PrATs)
• SSH Keys
• GPG Keys

This API complements the existing Credentials Inventory UI, allowing enterprise administrators to automate credential management tasks that previously required manual intervention. With the Credentials Inventory API, you can:

• Automate security workflows: Build automated processes to monitor, audit, and revoke credentials.
• Enforce credential policies: Identify and revoke unused or expired tokens.
• Improve security posture: Reduce the risk of credential misuse through regular auditing.
• Streamline operations: Integrate credential management into your existing security tools and workflows.

Group Owners can disable SSH keys for enterprise users (SaaS only): System Access

Group Owners can now disable SSH keys for all enterprise users in their group. When disabled, users cannot add new SSH keys and their existing keys are deactivated. This applies to all enterprise users in the group, including those with the Owner role.

Thank you to Wesley Yarde for helping build this feature!

Ultimate

Application security testing

C/C++ support in Advanced SAST now generally available: SAST

Cross-file, cross-function scanning support for C/C++ is now generally available in GitLab Advanced SAST.

Multiple Container Scanning: Container Scanning

In GitLab 18.8, we released multi-container scanning in Beta.

Users are now able to pass in an array of images to be scanned as part of many Container Scanning jobs.

Software supply chain security

GitLab Duo Security Analyst Agent now generally available: Vulnerability Management, Dependency Management

The GitLab Duo Security Analyst Agent, introduced as beta in GitLab 18.5, is now generally available in GitLab 18.8.

The Security Analyst Agent enables engineers to manage vulnerabilities through natural language commands in GitLab Duo Agentic Chat. Instead of manually clicking through vulnerability dashboards or writing custom scripts for bulk operations, security teams can now triage, assess, and provide guidance for vulnerabilities in Chat conversations.

As a foundational agent, the Security Analyst Agent is available by default in GitLab Duo Agentic Chat, with no manual setup required.

Security risk management

Auto-dismiss irrelevant vulnerabilities with vulnerability management policies: Security Policy Management

Security teams can now automatically dismiss vulnerabilities that don't apply to their organization using vulnerability management policies. Dismissing vulnerabilities that are not relevant to your organization reduces noise and helps developers focus on vulnerabilities that pose actual risk.

You can create policies to auto-dismiss vulnerabilities based on:

• File path
• Directory
• Identifier (CVE, CWE, or OWASP)

Auto-dismissed vulnerabilities appear in the merge request's security widget with an Auto-dismissed label and are tracked in the vulnerability report activity with a dismissal reason for audit purposes.

Premium

GitLab Duo Agent Platform now generally available: Duo Agent Platform

GitLab Duo Agent Platform is now generally available, bringing agentic AI orchestration across your entire software development lifecycle. Unlike AI tools that speed up individual tasks in isolation, the Agent Platform helps teams coordinate AI agents across planning, building, securing, and shipping software, closing the gap between faster individual work and the collaborative, multi-stage reality of software delivery.

The platform provides a central AI Catalog where teams can discover, manage, and share agents and flows across their organization. Built-in foundational agents like Planner, Security Analyst, and Data Analyst handle structured work at key decision points, while customizable flows automate multi-step agents and tasks in development workflows from issue to merge request, CI/CD migration, pipeline troubleshooting, and code reviews.

With governance controls, usage visibility, and flexible deployment options including self-hosted models for offline environments, organizations can adopt AI at scale with the transparency and control they need.

GitLab Premium and Ultimate users can start using the Agent Platform today on GitLab.com and GitLab Self-Managed instances with promotional GitLab Credits.

Turn the GitLab Duo Agent Platform on or off: Duo Agent Platform

You can now turn on or off the GitLab Duo Agent Platform, including GitLab Duo Chat (Agentic), agents, and flows for a top-level group or the entire instance. When this setting is turned off, these features are not available.

Group access control for GitLab Duo features: Duo Agent Platform

You can now define group access rules to control who can use GitLab Duo features, enabling flexible adoption strategies from immediate organization-wide access to phased rollouts.

This feature provides granular governance control so you can scale adoption at your pace while maintaining security and compliance.

GitLab Duo Agent Platform for GitLab Duo Self-Hosted (offline licensing) now generally available (self-managed only): Self-Hosted Models

GitLab Duo Agent Platform is now generally available for Duo Self-Hosted. This feature is available to GitLab Self-Managed customers with an offline license, and uses seat-based pricing.

Self-Managed administrators can configure compatible models for use with GitLab Duo Agent Platform. Administrators using AWS Bedrock or Azure OpenAI can also configure Anthropic Claude or OpenAI GPT models.

Plan

GitLab Duo Planner Agent now generally available: Portfolio Management

The Planner Agent is now generally available! The Planner Agent is a foundational agent built to support product managers directly in GitLab.

Use the Planner Agent to create, edit, and analyze GitLab work items. Instead of manually chasing updates, prioritizing work, or summarizing planning data, the Planner Agent helps you analyze backlogs, apply frameworks like RICE or MoSCoW, and surface what truly needs your attention. It's like having a proactive teammate who understands your planning workflow and works with you to make better, more efficient decisions.

Please provide your feedback in issue 583008.

Core

Verify

GitLab Runner 18.8: GitLab Runner Core

We're also releasing GitLab Runner 18.8 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:

• Improved error messages for job inputs interpolation errors

Bug Fixes:

• WaitForServicesTimeout no longer supports -1 to disable timeout
• Custom URL breaks submodule authentication with insteadOf rules
• Custom runner short-token on Windows 2025 uses 9 characters instead 8
• PowerShell default helper image missing for Docker executor in GitLab Runner 17.8.3
• GitLab Runner with Docker Autoscaler does not reuse available cache volumes
• VirtualBox leaves dangling VM when job is cancelled

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

Original source

Software supply chain security

Service accounts available during trials on GitLab.com (SaaS only): System Access

Service accounts are now available during trial periods, allowing you to test automation and integration workflows before purchasing.

Ultimate

Enhanced active trial experience for Self-Managed (self-managed only): Acquisition

GitLab Self-Managed users on an Ultimate trial can now access their active trial status, remaining days, accessible features, and expiration notifications from the left sidebar.

These enhancements help eliminate confusion about trial duration and make it easier to evaluate paid features before purchase.

Application security testing

Secret validity checks improved and generally available: Secret Detection

When a valid secret is leaked in one of your repositories, you must react quickly.

To help you prioritize urgent threats, validity checks automatically verify whether leaked credentials can still be used.

In GitLab 18.7, we've improved:

• Vendor integrations: Integrated with Google Cloud, AWS, and Postman, along with existing support for GitLab tokens.
• Report filtering: Filter the Vulnerability Report by validity status (active, inactive, possibly active) to quickly triage and prioritize secret findings.
• Group-level API: Turn on validity checks across all projects in a group with a single API call and streamline rollout across your organization.

In this release, validity checks are generally available.

Software supply chain security

SAST False Positive Detection with AI (Beta): Vulnerability Management

Security teams often spend significant time investigating SAST findings that turn out to be false positives, diverting attention from genuine security risks.

In GitLab 18.7, we're introducing AI-powered SAST False Positive Detection to help teams focus on the vulnerabilities that matter. When a security scan runs, GitLab Duo automatically analyzes each Critical and High severity SAST vulnerability to determine the likelihood that it's a false positive.

The AI assessment appears directly in the vulnerability report, giving security engineers immediate context to make faster, more confident triage decisions.

Key capabilities include:

• Automatic analysis: False positive detection runs automatically after each security scan with no manual triggering required.
• Manual trigger option: Users can manually trigger false positive detection for individual vulnerabilities on the vulnerability details page for on-demand analysis.
• Focused on high-impact findings: Scoped to Critical and High severity vulnerabilities to maximize signal-to-noise improvement.
• Contextual AI reasoning: Each assessment includes an explanation of why the finding may or may not be a true positive, based on code context and vulnerability characteristics.
• Seamless workflow integration: Results surface directly in the vulnerability report alongside existing severity, status, and remediation information.

This feature is available as a free beta for Ultimate customers and must be enabled in your group or project settings.

We welcome your feedback in issue 583697.

Filter and comment on compliance violations: Compliance Management

The compliance violations report provides a centralized view of all compliance violations across your organization's projects. The report displays comprehensive details about control violations, related audit events, and enables teams to track violation statuses effectively.

In GitLab 18.7, we've introduced powerful filtering capabilities to help you quickly find the violations that matter most. You can now filter by:

• Status
• Project
• Control

Teams can now also collaborate directly on resolving violations through comments. Within the violation record itself, teams can:

• Tag team members for investigation
• Discuss remediation approaches
• Document findings—all within the violation record itself.

Together, these features evolve the compliance violations report into a dynamic collaboration platform, enabling organizations to efficiently discover, analyze, and resolve compliance violations in their groups and projects.

Compliance framework controls show accurate scan status: Compliance Management

GitLab compliance controls can be used in compliance frameworks. Controls are checks against the configuration or behavior of projects that are assigned to a compliance framework.

Previously, controls related to scanners (for example, checking if SAST is enabled) required your projects to have a passing pipeline in the default branch before the compliance centre displayed the success or failure status of your controls.

In GitLab 18.7, we have changed this behavior to show whether your controls have succeeded or failed based solely on scan completion, regardless of the overall pipeline status. This helps ease confusion because the compliance status of your controls reflects whether security scans ran and completed, not whether the entire pipeline passed.

Security risk management

New security dashboards enabled by default: Vulnerability Management

The new security dashboards have been updated and modernized. The dashboards were previously available on GitLab.com, and are now enabled by default on GitLab Dedicated and GitLab Self-Managed.

The new features include:

• A vulnerabilities over time chart that supports:
  • Filtering based on project or report type.
  • Grouping by report type and severity.
  • Direct links to vulnerabilities in the vulnerability report.
• A risk score module that calculates the estimated risk for a group or project based on a GitLab algorithm.

Please note that using the new dashboard requires ElasticSearch.

Advanced vulnerability management available in Self-Managed and Dedicated environments: Vulnerability Management

Advanced vulnerability management is available to all Ultimate customers and includes the following features:

• Grouping data by OWASP 2021 categories in the vulnerability report for a project or group.
• Filtering based on a vulnerability identifier in the vulnerability report for a project or group.
• Filtering based on the reachability value in the vulnerability report for a project or group.
• Filtering by policy violation bypass reason.

Warn mode in merge request approval policies: Security Policy Management

Security teams can now use warn mode to test and validate the impact of security policies before applying enforcement or to roll out soft gates for accelerating your security program. Warn mode helps to reduce developer friction during security policy rollouts, while continuing to ensure detected vulnerabilities are addressed.

When you create or edit a merge request approval policy, you can now choose between warn or enforce enforcement options.

Policies in warn mode generate informative bot comments without blocking merge requests. Optional approvers can be designated as points of contact for policy questions. This approach enables security teams to assess policy impact and build developer trust through transparent, gradual policy adoption.

Clear indicators in merge requests tell users when policies are in warn or enforce mode, and audit events track policy violations and dismissals for compliance reporting. Developers can bypass scan finding and license policy violations by providing a reasoning for the policy dismissal, creating a collaborative feedback loop between developers and security teams for more effective policy enablement.

When policy violations are detected on a project's default branch, policies identify vulnerabilities that violate the policy in the vulnerability reports for projects and groups. The dependency list for projects also displays badges that indicate license compliance policy violations.

Additionally, you can use the API to query a filtered list of policy violations on the default branch in a project.

Premium

Improved GitLab Duo and SDLC trends dashboard: DevOps Reports

The GitLab Duo and SDLC trends dashboard delivers improved analytics capabilities to measure the impact of GitLab Duo on software delivery. The dashboard now provides 6-month trend analysis across GitLab Duo feature adoption, pipeline performance, and common development metrics such as deployment frequency and mean time to merge.

You can now track code generation volumes and IDE or language trends for GitLab Duo Code Suggestions, and observe as your teams adopt new GitLab Duo Agent Platform flows. Enhanced user-level metrics enable teams to gain deeper insight into the key Duo features providing continuous value.

A new endpoint for instance-level AI usage is now available for instance administrators to extract all Duo data from either Postgres (3-month retention) or ClickHouse.

Powered by the ClickHouse integration, this dashboard delivers sub-second query performance across millions of data points. For self-managed instances, see improved recommendations and configuration guidance for ClickHouse integration.

Separate model selection for Agentic Chat and agents: Model Personalization

Separate models can now be selected for Agentic Chat and for all other agents for top-level groups or instances.

This provides more options for model selection for GitLab Duo Agent Platform.

Advanced search available for both merge request descriptions and comments: Global Search

Advanced search now returns matching results from both merge request descriptions and comments. Previously, users had to search merge request descriptions and comments separately.

This improvement provides a more streamlined and comprehensive search workflow for GitLab merge requests.

Support for AGENTS.md with GitLab Duo Chat (Agentic) in IDEs: Editor Extensions

GitLab Duo Chat now supports the AGENTS.md specification, an emerging standard for providing context and instructions to AI coding assistants.

Unlike custom rules that are only available to GitLab Duo, AGENTS.md files are also available for other AI coding tools to use. This makes your build commands, testing instructions, code style guidelines, and project-specific context available to any AI tool that supports the specification.

GitLab Duo Chat in your IDE automatically applies available instructions from AGENTS.md files in your repository, set at the user or workspace level. For monorepos, you can place AGENTS.md files in subdirectories to provide tailored instructions for different components.

AI agent and flow versioning: Duo Agent Platform

When you enable an agent or flow from the AI Catalog in your project, GitLab now pins it to a specific version.

This means your AI-powered workflows stay stable and predictable even as catalog items evolve, so you can test and validate new versions before you upgrade.

AI gateway timeout setting (self-managed only): Model Personalization

For GitLab Duo Self-Hosted, you can now configure a timeout value for requests to self-hosted models.

This value can range from 60 to 600 seconds.

Report agents and flows to administrators: AI Catalog

You can now report agents and flows to instance administrators when you encounter problematic content. Submit an abuse report that includes your feedback, and an administrator can choose to hide or delete the harmful item.

Use this feature to keep your agents and flows safe across your entire organization.

Configure foundational agent availability: Duo Agent Platform

You can now control which foundational agents are available in your top-level group or instance.

Turn all foundational agents on or off by default, or toggle individual agents to align with your organization's security and governance policies.

Data Analyst foundational agent powered by GLQL (Beta): Custom Dashboards Foundation

The Data Analyst Agent is a specialized AI assistant that helps you query, visualize, and surface data across the GitLab platform. It uses GitLab Query Language (GLQL) to retrieve and analyze data, then provides clear, actionable insights about your projects.

You can find example prompts and use cases in the documentation.

This agent is currently in beta status, so please share your thoughts in the feedback issue to help us improve and provide insight into where you'd like to see this go next.

Plan

Additional Planner Agent features available in beta: Portfolio Management

The Planner Agent now includes create and edit features in beta! The Planner Agent is a foundational agent built to support product managers directly in GitLab. Use the Planner Agent to create, edit, and analyze GitLab work items.

Instead of manually chasing updates, prioritizing work, or summarizing planning data, the Planner Agent helps you analyze backlogs, apply frameworks like RICE or MoSCoW, and surface what truly needs your attention. It's like having a proactive teammate who understands your planning workflow and works with you to make better, more efficient decisions.

Please provide your feedback in issue 576622.

Verify

Instance setting to control publishing of components to the CI/CD Catalog (self-managed only): Pipeline Composition, Component Catalog

Administrators of GitLab Self-Managed and GitLab Dedicated can now restrict which projects are allowed to publish components to the CI/CD Catalog. This new setting enables organizations to maintain a curated, trusted CI/CD Catalog by controlling what components can be published.

Administrators can now specify an allowlist of projects authorized to publish components. When the allowlist is populated with projects, only those projects can publish components. This prevents unauthorized or unapproved components from cluttering the list of published components and ensures all components meet organizational standards and security requirements.

This addresses a key governance challenge for enterprise customers who want to maintain control over their CI/CD component ecosystem while enabling their teams to discover and reuse approved components.

Core

Plan

Accessibility improvements for heading anchor links: Markdown

Heading anchor links now announce with the same text as their corresponding heading, improving the experience for screen reader users. The links also appear after the heading text, providing a cleaner visual presentation.

These changes make it easier for all users to understand and navigate to specific sections of documentation, issues, and other content.

Verify

Dynamic input options in CI/CD pipelines: Pipeline Composition

You can set up your CI/CD pipelines to make use of dynamic input selection when creating new pipelines through the intuitive web interface.

Now, with dynamic input options, you can configure your pipelines so that input selection options update dynamically based on previous selections. For example, when you select an input in one dropdown list, it automatically populates a list of related input options in a second dropdown list.

With CI/CD inputs, you can:

• Trigger pipelines with pre-configured inputs, reducing errors and streamlining deployments.
• Enable your users to select different inputs than the defaults from dropdown menus.
• Now have cascading dropdown lists where options dynamically update based on previous selections.

This dynamic capability enables you to create more intelligent, context-aware input configurations that guide you through the pipeline creation process, reducing errors and ensuring only valid combinations of inputs are selected.

GitLab Runner 18.7: GitLab Runner Core

We're also releasing GitLab Runner 18.7 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:

• Configurable taskscaler reservation throttling
• Enable FF_TIMESTAMPS by default

Bug Fixes:

• Shell executor fails on existing Git repository if a relative builds_dir is specified
• Authentication failure in GitLab Runner 18.6.0 on subsequent pipeline runs (SSH executor)
• Authentication failure in GitLab Runner 18.6.0 on subsequent pipeline runs (shell executor)
• Docker 29 API compatibility issues
• Variables that reference file variables no longer work in GitLab Runner 18.6.0 with the shell executor
• GitLab Runner now supports Windows 11 2025 (25H2)
• ECR credential helper is not working with the Docker Autoscaler executor
• Job timeouts now properly enforced in GitLab Runner

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

View child pipeline reports in merge requests: Continuous Integration (CI)

Teams using parent-child CI/CD pipelines previously had to navigate through multiple pipeline pages to check test results, code quality reports, and infrastructure changes, disrupting their merge request review workflow.

You can now view and download all reports in a unified view, including unit tests, code quality checks, Terraform plans, and custom metrics, without leaving the merge request.

This eliminates context switching and accelerates merge request velocity, giving teams the ability to deliver features faster without compromising quality.

Original source

Software supply chain security

Group Owners can update primary emails for enterprise users (SaaS only): System Access

Group owners can can now update the primary email address of enterprise users in their group. Updates can be made through the Users API. Previously, each enterprise user had to manually update their own email address. This change makes it easier to manage enterprise users at scale.

Ultimate

Software supply chain security

GitLab Security Analyst Agent available as a foundational agent: Vulnerability Management, Dependency Management

The GitLab Security Analyst Agent is now a foundational agent in GitLab Duo Agentic Chat. This means that users do not have to manually add the GitLab Security Analyst agent from the AI Catalog, and this agent is available by default for GitLab Self-Managed and GitLab Dedicated as well.

This specialized assistant provides AI-native vulnerability management and security analysis, helping you investigate findings, triage vulnerabilities, and navigate compliance requirements without any setup.

This feature is in beta, and we welcome your feedback in issue 576916.

Security risk management

Security dashboard upgrade (beta on GitLab.com): Vulnerability Management

The new security dashboards have been updated and modernized. The initial features in the beta release include:

A vulnerabilities over time chart that supports:
Filtering based on project or report type.
Grouping by report type and severity.
Direct links to vulnerabilities in the vulnerability report.

A risk score module that calculates the estimated risk for a group or project based on a GitLab algorithm.

The new security dashboards released in 18.6 are currently available on GitLab.com only.

Warn mode in merge request approval policies (Beta): Security Policy Management

Security teams can now use warn mode to test and validate the impact of security policies before applying enforcement, reducing developer friction during security policy rollouts.

When you create or edit a merge request approval policy, you can now choose between warn or enforce enforcement options.

Policies in warn mode generate informative bot comments without blocking merge requests. Optional approvers can be designated as points of contact for policy questions. This approach enables security teams to assess policy impact and build developer trust through transparent, gradual policy adoption.

Clear indicators in merge requests tell users when policies are in warn or enforce mode, and audit events track policy violations and dismissals for compliance reporting. Developers can dismiss vulnerabilities while providing reasoning for the dismissal, creating a collaborative approach to security policy management.

Security attributes (Beta): Security Asset Inventories

Security teams can now apply business context to projects by leveraging security attributes.

Security attributes are organized by categories including business impact (with structured pre-defined selections), application, business unit, internet exposure, and location. Alternatively, you can create your own attribute categories and define labels within those categories.

By applying these attributes across your projects, you can much more quickly search, filter, and identify which projects within the security inventory that require action based on risk posture and organizational context. You may now:

• Identify projects that are mission critical and requiring better scan coverage
• Review scan coverage by application or business unit
• Search and filter based on the attributes applied to your projects
• Quickly locate projects that contribute to applications which are publicly accessible/exposed

Exceptions to bypass merge request approval policies: Security Policy Management

Organizations can now designate specific users, groups, roles, or custom roles that can bypass merge request approval policies in case critical situations occur. This capability provides flexibility for emergency responses, while maintaining comprehensive audit trails and governance controls.

Emergency bypass with accountability: Designated users can bypass approval requirements during critical incidents, security hotfixes, or urgent production issues. When emergencies strike, authorized personnel can merge or push changes immediately while the system captures detailed justification and audit information for compliance review.

Key capabilities include:

• Documented bypass process: When authorized users invoke a policy bypass, they must provide detailed reasoning using an intuitive modal interface, ensuring every exception is properly documented with context.
• Comprehensive audit integration: Every bypass generates detailed audit events including user identity, policy context, reasoning, and timestamps for complete visibility into exception usage patterns.
• Flexible configuration: Define exception permissions for policies using YAML or UI configuration, supporting individual users, GitLab groups, standard roles, and custom roles.
• Git-based push exceptions: Users with pre-approved policy exceptions may push directly when invoking the push bypass option security_policy.bypass_reason.

This feature eliminates the need to entirely disable security policies during emergencies, providing a controlled path for urgent changes while preserving organizational governance and audit requirements.

Premium

Exact code search in limited availability: Global Search

With this release, exact code search is now in limited availability. You can use exact match and regular expression modes to search for code across an entire instance, in a group, or in a project. Exact code search is built on top of the open-source search engine Zoekt.

For GitLab.com, exact code search is enabled by default. For GitLab Self-Managed, an administrator must install Zoekt and enable exact code search.

This feature is in active development. We welcome your feedback in issue 420920!

Model selection for GitLab Duo Agentic Chat in VS Code and JetBrains IDEs: Editor Extensions, Model Personalization

Easily choose your preferred AI model right in GitLab Duo Chat, now available in the VS Code and JetBrains IDEs. Use the dropdown list in the GitLab Duo Chat panel to select among Claude, GPT, and other supported models. Model availability is managed by your organization admins, ensuring you have access to the right models for your workflow.

GitLab MCP server available in beta: MCP Server

The GitLab MCP server is available in beta. With the GitLab MCP server, you can use AI assistants like Claude Code, Cursor, and other MCP-compatible tools to interact with your GitLab projects, issues, merge requests, and pipelines, all without building custom integrations for each tool.

To get started, turn on beta and experimental features in your GitLab Duo settings.

The GitLab MCP server provides key tools covering issues, merge requests, and pipelines, and we continue to refine it based on user feedback. This feature might have incomplete functionality or bugs. Try it out and share feedback in issue 561564.

Advanced search available for both issue descriptions and comments: Global Search

Advanced search now returns matching results from both issue descriptions and comments. Previously, users had to search issue descriptions and comments separately. This improvement provides a more streamlined and comprehensive search workflow for GitLab issues.

Gemini 2.5 Flash model compatible with GitLab Duo Agent Platform for GitLab Duo Self-Hosted (self-managed only): Self-Hosted Models

You can now use the Gemini 2.5 Flash model on GitLab Duo Agent Platform with GitLab Duo Self-Hosted.

Plan

GitLab Duo Planner Agent now available by default: Team Planning

The GitLab Duo Planner Agent is now available by default in the agent dropdown in GitLab Duo Chat, eliminating the need to manually add it from the AI Catalog. With full context of your work items, epics, issues, and tasks, the Planner Agent can now assist you at both the group and project levels.

Get started with example prompts to see how the Planner Agent can help you break down complex work, create implementation plans, and organize your team's objectives.

This feature is in beta, and we welcome your feedback in issue 576622.

Create

Code Owners now supports inherited group memberships: Code Review Workflow, Source Code Management

Code ownership is critical for maintaining code quality and ensuring the right people review changes to sensitive parts of your codebase. However, managing Code Owners in organizations with complex group structures has been challenging. Previously, to reference a group in your CODEOWNERS file, that group had to be directly invited to each specific project, even if it was already a member of a parent group.

Code Owners now supports groups with inherited memberships as eligible approvers:
Groups with inherited access through parent group membership are recognized as valid code owners when Code Owners approvals are enabled.
No need to invite groups directly to every project.
Existing CODEOWNERS files continue to work without changes.
Same level of control over who can approve changes to critical code paths.
This change reduces administrative overhead while maintaining the security and approval requirements that Code Owners provide.

Webhook triggers for system-initiated approval resets: Code Review Workflow

Integrating GitLab with external systems through webhooks is critical for automated workflows and keeping teams informed about merge request status changes. However, when GitLab automatically resets approvals (such as when new commits are pushed to a merge request with "Reset approvals on push" enabled), external systems could not distinguish these system-initiated events from manual user actions.

GitLab now includes enhanced webhook payloads that clearly identify system-initiated approval resets. When approvals are automatically reset, webhooks now include:
A system field set to true.
A system_action field that provides specific context about why the reset occurred, such as approvals_reset_on_push or code_owner_approvals_reset_on_push.

This means your webhook integrations can now distinguish between manual approval changes and automatic system resets, enabling more sophisticated automation workflows that respond appropriately to the specific context of each approval change.

Core

Rate limit for listing project and group members: Groups & Projects

We've introduced rate limiting for the /api/v4/projects/:id/members/all and /api/v4/groups/:id/members/all endpoints to improve API stability and ensure fair resource usage across all users.

The GET /api/v4/projects/:id/members/all and GET /api/v4/groups/:id/members/all endpoints now have a rate limit of 200 requests per minute per user.

This change helps protect GitLab instances from excessive API usage that could impact performance for all users.

The limit of 200 requests per minute provides ample capacity for normal usage patterns while preventing potential abuse or unintentional resource exhaustion.

If your integrations or scripts use this endpoint, ensure they handle rate limit responses appropriately (HTTP 429) and implement retry logic with backoff as needed.

Most users should not be affected by this change under normal usage patterns.

Plan

The new GitLab UI: Designed for productivity: Design Management

Introducing a smarter, more intuitive GitLab UI that puts developer productivity first.

The new side-by-side design uses contextual panels to keep you in your workflow, reducing unnecessary clicks and helping teams work faster. Customize your workspace, maximize screen real estate, and enjoy a cleaner, more dynamic experience that adapts to your workflow.

GitLab is committed to continuous improvement, so please share your thoughts in the feedback issue and help shape the future of GitLab.

Create

Toggle draft merge request visibility on your homepage: Code Review Workflow

On your homepage, draft merge requests can clutter your merge request view and distract from work that's ready for action. Previously, you could not filter them out.

You can now hide draft merge requests from the Your merge requests section on your homepage by using the display preferences. When you hide draft merge requests:

• They are excluded from the active count.
• A footer displays the number of filtered draft merge requests.
• Your preference is saved automatically.

This change helps you focus on merge requests that need immediate attention.

New GitLab CLI features and improvements: GitLab CLI

The GitLab CLI (glab) provides new features and improvements to enhance your GitLab workflow from the command line:

• Enhanced authentication: Auto-detect GitLab URLs from git remotes during login, making it easier to authenticate against the correct GitLab instance.
• Flexible pipeline monitoring: View any pipeline by ID with the ci-view command.
• GPG key management: Manage GPG keys directly from the CLI with new commands.
• Project member management: Add, remove, and update project members from the command line.
• Improved Git integration: Enhanced git-credential plugin with support for all token types.
• Modern user interface: Updated prompt library for better confirmation dialogs and consistent GitLab theme across UI components.

For a full list of changes and updates, see CLI releases.

To get started with the GitLab CLI or update to the latest version, see the installation guide.

Webhook notifications for merge request review re-requests: Code Review Workflow

Webhook integrations are critical for automating workflows and keeping external systems synchronized with GitLab merge request activities. However, when reviewers were re-requested for merge requests, webhook consumers had no way to identify which specific reviewer was being re-requested, making it difficult to trigger appropriate notifications or automation.

Webhook payloads for merge requests now include a re_requested attribute in reviewer data that clearly indicates which reviewer was re-requested:

• Set to true for the specific reviewer being re-requested.
• Set to false for all other reviewers.

This improvement enables more precise automation around the merge request review process. Webhook consumers can send targeted notifications, update external tracking systems, and trigger appropriate workflows when reviews are re-requested.

Web IDE support for offline GitLab Self-Managed environments (self-managed only): Web IDE, Editor Extensions

GitLab Self-Managed administrators in offline or tightly controlled network environments can now configure a custom Web IDE extension host domain, enabling full Web IDE functionality without external internet access.

Previously, the Web IDE required connectivity to .cdn.web-ide.gitlab-static.net to load VS Code extensions and functionality. This requirement blocked Web IDE adoption for security-conscious organizations, government and public sector customers, and enterprises with strict network policies.

With this update, administrators can configure their GitLab instance to serve Web IDE assets directly, removing the dependency on external domains. You can now:

• Use the full Web IDE feature set in completely offline environments.
• Enable the Extension Marketplace with a custom extension registry service.
• Enable markdown preview, code editing, and GitLab Duo Chat within the Web IDE in isolated networks.

Verify

CI/CD Components can reference their own metadata: Pipeline Composition

Previously, CI/CD components couldn't reference their own metadata, such as version numbers or commit SHAs, within their configuration. This lack of information could cause you to use configuration with hardcoded values or complex workarounds. Writing configuration this way can lead to version mismatches when components build resources such as Docker images, because there's no way to automatically tag those resources with the component's compatible version.

In this release, we've introduced the ability to access component context with the spec:component keyword.

You can now build and publish versioned resources like Docker images when you release a component version, ensuring everything is in sync, eliminating manual version management, and preventing version mismatches.

Support dynamic job dependencies in needs:parallel:matrix: Pipeline Composition

parallel:matrix makes it possible to easily run multiple jobs in parallel with different requirements, for example to test code for multiple platforms at the same time. But if you wanted later jobs to use needs:parallel:matrix to depend on specific parallel jobs, the configuration was complex and inflexible.

Now, with the new $[[matrix.VARIABLE]] expression introduced as a Beta feature, users can create dynamic 1-1 dependencies which makes complex parallel:matrix configurations much easier to manage. This can help you create faster pipelines, with efficient artifact handling, better scalability, and cleaner configuration. This feature is particularly valuable for multi-platform builds, Terraform deployments across multiple environments, and any workflow requiring parallel processing across multiple dimensions.

GitLab Runner 18.6: GitLab Runner Core

We’re also releasing GitLab Runner 18.6 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:

• Implement minimal job confirmation API

Bug Fixes:

• GitLab Runner does not expand the variables in the Docker image platform option
• Helper sidecar container fails to upload cache to S3 bucket from another account
• Automatically canceled job continues execution and fails
• Missing UTF8 BOM in the generated PowerShell script allows remote code execution using merge request title with character Ä
• Intermittent Kubernetes API server request failures with Kubernetes executor
• When using a Kubernetes executor, jobs with large commit messages fail

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

Package

Helm chart registry: No more 1,000 chart limit: Package Registry

GitLab's Helm chart registry previously generated metadata responses on-the-fly, which created performance bottlenecks when repositories contained large numbers of charts. To maintain system stability, we enforced a hard limit of the 1,000 most recent charts. This limit caused frustrating 404 errors when platform teams tried to access older chart versions.

Platform engineers were forced to implement complex workarounds, like splitting charts across multiple repositories, manually managing chart retention policies, or maintaining separate chart storage solutions. These workarounds added operational overhead and fragmented deployment workflows, making it harder to maintain centralized chart governance.

In GitLab 18.6, we've eliminated the 1,000 chart limitation by pre-computing metadata responses and storing them in object storage. This architectural change delivers both unlimited chart access and improved performance, as metadata is generated once in background jobs rather than on every request.

Application security testing

Increased rule coverage for secret push protection and pipeline secret detection: Secret Detection

We've added support for 40 new rules to GitLab's pipeline secret detection. Some existing rules have also been updated to improve quality and reduce false positives. These changes are released in version 7.20.1 of the secrets analyzer.

Software supply chain security

Designate an account succession beneficiary (SaaS only): System Access

You can now designate an account beneficiary permission to manage your GitLab account if you are incapacitated or unavailable. To access your account, the beneficiary must provide appropriate legal documentation. This feature helps ensure the continuity of your work and projects while preventing unauthorized access.

Original source

Ultimate

Application security testing

DAST authentication scripts: DAST

You can now add scripts to your CI/CD configurations to automate DAST authentication workflows. Authentication scripts enable automating complex authentication flows, including support for time-based, one-time passwords (OTP MFA).

This enhancement helps your team maintain critical security controls while conducting thorough, automated security scans. By supporting real-world authentication scenarios, scripts reduce friction and ensure accurate security assessments of production software.

C/C++ support for Advanced SAST: SAST

We have added beta support for C/C++ to GitLab Advanced SAST.

To use this new cross-file, cross-function scanning support, enable C/C++ support.

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

Secret validity checks is in beta: Secret Detection

Pipeline secret detection alerts you to exposed credentials, like passwords or API keys, in your projects. However, until GitLab 18.5, you had to manually check whether each detection represented an active token. This could make effectively triaging detections difficult and time consuming.

Now that validity checks is in beta, enable it to display the status of detected GitLab secrets. Active secrets can be used to impersonate legitimate activity, so you should rotate them as soon as possible. To watch validity checks in action, see the validity checks playlist.

Customizable detection logic for Advanced SAST: SAST

You can now create custom security detection rules tailored to your organization's specific security requirements and coding patterns with GitLab Advanced SAST. This feature enables your security teams to define custom vulnerability patterns beyond the predefined ruleset, allowing them to detect application-specific security issues.

For more information, see Customize rulesets.

Advanced SAST diff-based scanning in merge requests: SAST

You can now perform diff-based scans that analyze only the code changes in a merge request with GitLab Advanced SAST, significantly reducing scan times compared to full repository scans. By scanning just the Git diff rather than the entire codebase, your teams can integrate security testing more seamlessly into their development workflow without sacrificing speed or adding friction to the merge request process.

We are working to enable this performance improvement by default; this is tracked in issue 546359.

Dependency scanning in limited availability: Software Composition Analysis

In GitLab 18.5, we released a new dependency scanning template that works with the dependency scanning analyzer.

The analyzer now generates a dependency scanning report containing all component vulnerabilities.

Scan Execution Policy (SEP) and Pipeline Execution Policy (PEP) support the new template.

To use the new template, import Jobs/Dependency-Scanning.v2.gitlab-ci.yml.

This feature is available on GitLab.com and self-managed instances, though it's marked as limited availability because official support for self-managed is not yet available.

GitLab.com users can use it immediately.

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

Static reachability in limited availability and experimental Java support: Software Composition Analysis

In GitLab 18.5, we released limited availability support for static reachability.

This release focuses on improving JS/TS coverage support, fixing bugs, and providing experimental support for Java.

Static reachability enriches Software Composition Analysis (SCA) results by scanning project source code to identify open source dependencies that are in use.

Data produced by static reachability can be used as part of users' triage and remediation decision making. Static reachability data can also be used with CVSS and EPSS scores, as well as KEV indicators to provide a more focused view of identified vulnerabilities.

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

Software supply chain security

GitLab Security Analyst Agent for Duo Agent Catalog (beta): Vulnerability Management, Dependency Management

Agents in GitLab Duo Agent Platform can be used to perform tasks and answer complex questions within GitLab. Users can either create custom agents to accomplish specific tasks, like creating merge requests or reviewing code, or discover GitLab agents using the AI Catalog.

In GitLab 18.5, we are releasing the GitLab Security Analyst Agent as a beta feature, available in the AI Catalog. To use the GitLab Security Analyst Agent in specific projects, select and enable the agent in GitLab Duo Agentic Chat. The agent can perform the following tasks:

• List all vulnerabilities in a given project.
• Get detailed vulnerability information, including CVE data and EPSS scores.
• Confirm and dismiss vulnerabilities.
• Update vulnerability severity levels.
• Revert vulnerability status back to detected.
• Create vulnerability issues, or link vulnerabilities to existing issues.

With the GitLab Security Analyst Agent, users can perform tedious security workflows through AI-powered automation and intelligent analysis, enabling engineers to focus on genuine threats while the GitLab Security Analyst Agent handles repetitive assessment and documentation. Please note that the GitLab Security Analyst Agent using GitLab Duo Chat is only available for Ultimate customers with the GitLab Duo add-on.

This feature is in beta, and we welcome your feedback in issue 576916.

Instance-wide compliance and security policy management (self-managed only): Compliance Management, Security Policy Management

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 security policies. For example, when all groups share the same pipeline execution policy.

With GitLab 18.5, we introduce compliance and security policy groups to centralize the management of security policies and compliance frameworks on an instance for GitLab Self-Managed and Dedicated instances. With this release, 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 instance.

With a compliance and security policy group, you have a single source of truth where you can manage and edit your compliance frameworks and security policies.

Security and compliance users within the group can then apply compliance frameworks and security policies to all the projects across the instance.

Compliance and security policy groups make it easier to manage and enforce your compliance and security needs across your 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 and Dedicated customers. GitLab.com customers can manage frameworks and policies centrally within a single top-level group or namespace using security policy projects.

Learn more about compliance and security policy groups for compliance frameworks and security policies.

New vulnerability management features in GitLab Duo Agentic Chat: Vulnerability Management, Dependency Management

GitLab Duo Agentic Chat is an enhanced version of GitLab Duo Chat. It searches, retrieves, and combines information from multiple sources across your GitLab projects to provide more thorough and relevant answers. A few of its use cases include the ability to search through projects, read and list files, and autonomously create and change files based on the prompt provided to GitLab Duo Chat.

In GitLab 18.5, the Agentic Chat use case expands to include managing vulnerabilities from your security scanners. By adding vulnerability management tools to Agentic Chat, this transforms tedious security workflows through AI-powered automation and intelligent analysis, enabling security professionals to efficiently triage, manage, and remediate vulnerabilities through natural language commands.

This eliminates hours of manual clicking through vulnerability dashboards and streamlining complex bulk operations that previously required custom scripts or tedious manual work.

With the new vulnerability management tools added to GitLab Duo Chat, Ultimate users with GitLab Duo can perform the following:

• List all vulnerabilities in a given project.
• Get detailed vulnerability information, including CVE data and EPSS scores.
• Confirm and dismiss vulnerabilities.
• Update vulnerability severity levels.
• Revert vulnerability status back to detected.
• Create vulnerability issues, or link vulnerabilities to existing issues.

These tools transform security workflows from reactive manual triage into intelligent remediation, letting engineers focus on genuine threats while AI handles repetitive assessment and documentation. Vulnerability management using GitLab Duo Chat is only available for Ultimate customers with the GitLab Duo add-on.

Control requests for external control statuses: Compliance Management

External controls can be attached to requirements when creating compliance frameworks in GitLab.

By default, GitLab automatically requests the status of external controls from external systems every 12 hours during compliance scans, setting the control status to 'pending'. External systems then respond by using the external controls API to update the status to 'pass' or 'fail'.

In GitLab 18.5, you can now disable this automatic 12-hour ping by turning off the Ping enabled setting when configuring external controls. When the 12-hour ping is disabled:

• GitLab will not automatically request status updates from external systems.
• The external control displays a Disabled badge in the compliance framework UI.
• You have complete control over when external control statuses are updated using the external controls API.

This prevents the system from resetting the external control statuses to 'pending' and gives you full control over status update timing.

Show only active vulnerabilities in the dependency list: Dependency Management

Previously, the dependency list included some dismissed vulnerabilities.

To provide you with a more useful representation of the vulnerabilities in the dependency list, the project dependency list now includes only active vulnerabilities in the detected and confirmed states.

Security risk management

Expose original severity from the vulnerabilities API: Vulnerability Management

The vulnerabilities GraphQL API now exposes the original severity of vulnerabilities.

This allows you to determine what the severity of the vulnerability was before severity overrides were applied.

Time windows for merge request approval policies: Security Policy Management

To provide further flexibility in security vulnerability comparisons, we have introduced time windows in merge request approval policies. If the security reports for the most recent baseline are not yet available, this new policy configuration allows you to use previously completed security reports, as long as the reports are not older than the age that you specify as the time window.

Development teams can now avoid unnecessary delays when baseline security scans are stuck or taking too long, such as in very busy projects. By configuring a time window, merge requests that don't introduce new vulnerabilities can proceed without waiting for the latest pipeline to complete, improving workflow efficiency.

To use this feature, create or edit a merge request approval policy and specify the security_report_time_window parameter (in minutes) in your approval policy configuration

The system will compare your merge request's security results against the latest pipeline using the security reports created within the specified time window, allowing for faster approvals when no new vulnerabilities are introduced.

Refreshed security finding statuses in the pipeline Security tab: Vulnerability Management

Previously, in the Security tab for a pipeline, if you dismissed an vulnerability, the vulnerability was not immediately removed from the list.

Status updates in the security tab of a pipeline page are now updated after they are changed.

Exceptions to bypass merge request approval policies: Security Policy Management

Organizations can now designate specific users, groups, roles, or custom roles that can bypass merge request approval policies in case critical situations occur. This capability provides flexibility for emergency responses, while maintaining comprehensive audit trails and governance controls.

Emergency bypass with accountability: Designated users can bypass approval requirements during critical incidents, security hotfixes, or urgent production issues. When emergencies strike, authorized personnel can merge or push changes immediately while the system captures detailed justification and audit information for compliance review.

Key capabilities include:

• Documented bypass process: When authorized users invoke a policy bypass, they must provide detailed reasoning using an intuitive modal interface, ensuring every exception is properly documented with context.
• Comprehensive audit integration: Every bypass generates detailed audit events including user identity, policy context, reasoning, and timestamps for complete visibility into exception usage patterns.
• Flexible configuration: Define exception permissions for policies using YAML or UI configuration, supporting individual users, GitLab groups, standard roles, and custom roles.
• Git-based push exceptions: Users with pre-approved policy exceptions may push directly when invoking the push bypass option security_policy.bypass_reason.

This feature eliminates the need to entirely disable security policies during emergencies, providing a controlled path for urgent changes while preserving organizational governance and audit requirements.

Premium

GPT-5 now available as a model option for GitLab Duo Agentic Chat: Model Personalization

OpenAI GPT-5 is now available as a GitLab AI Vendor model when selecting a model for GitLab Duo Agent Platform. When configured by Owners of a top-level group on GitLab.com and instance Administrators on Self-Managed and Dedicated, end-users can select to use GPT-5 with GitLab Duo features. Top-level owners and administrators can continue to set organization-wide model preferences through namespace or instance settings, or allow end-user to choose from all available GitLab AI Vendor models.

To get started using GPT-5, select your preferred model from the model dropdown list in GitLab Duo Chat.

Additional triggers for CLI agents: Duo Agent Platform

You can now trigger CLI agents using additional events to give you more flexibility and control over where and when your agents take action across your projects. Along with the existing mention trigger, you can use:

• Assign: Trigger agents when a merge request or issue is assigned.
• Assign reviewer: Trigger agents when a reviewer is added to a merge request.

GitLab Duo Agent Platform for GitLab Duo Self-Hosted now in beta (self-managed only): Self-Hosted Models

GitLab Duo Agent Platform is now in beta for GitLab Duo Self-Hosted. This feature is available to all Self-Managed GitLab Duo Enterprise customers. Self-Managed instance administrators using AWS Bedrock or Azure OpenAI can configure Anthropic Claude or OpenAI GPT models for use with GitLab Duo Agent Platform. Self-Hosted administrators can also configure compatible models to use with Gitlab Duo Agent Platform.

Codestral now supported for GitLab Duo Chat (Classic) (self-managed only): Self-Hosted Models

You can now use Mistral Codestral on Gitlab Duo Self-Hosted for classic Duo Chat. This model is supported for Gitlab Duo Self-Hosted customers on GitLab Self-Managed instances.

GPT OSS Models compatible with GitLab Duo Agent Platform for GitLab Duo Self-Hosted (self-managed only): Self-Hosted Models

You can now use GPT OSS models on GitLab Duo Agent Platform with Gitlab Duo Self-Hosted.

Plan

GitLab Duo Planner, a specialized agent and Product Manager team member (beta): Portfolio Management

Collaborate with GitLab Duo Planner, a GitLab Duo agent built to support product managers directly within GitLab. Instead of manually chasing updates, prioritizing work, or summarizing planning data, GitLab Duo Planner helps you analyze backlogs, apply frameworks like RICE or MoSCoW, and surface what truly needs your attention. It's like having a proactive teammate who understands your planning workflow and works with you to make better, faster decisions. This feature is currently in beta. Please provide feedback in issue 576622.

Configure status lifecycles for issues and tasks: Team Planning

Previously, issues and tasks were required to share the same set of configured statuses. In this release, we've added support for configuring status lifecycles, enabling you to define distinct workflows for issues and tasks in your projects. With status mapping built into the workflow, you can seamlessly transition an issue or task to a new set of statuses with no bulk editing required when changing work item types.

Share your feedback and help us improve the feature by contributing to our feedback issue with your use cases and suggestions.

Package

Maven virtual registry now available in beta: Virtual Registry

GitLab 18.5 introduces a comprehensive web-based interface for Maven virtual registry management. Previously, platform engineers could only configure and manage virtual registries through API calls, which makes routine maintenance tasks cumbersome and requires specialized knowledge.

This web-based approach significantly reduces operational overhead for platform engineering teams. Common tasks, like clearing stale cache entries, reordering upstreams for performance optimization, and testing connectivity are now point-and-click operations. Development teams gain better visibility into their dependency configuration, enabling more informed discussions about build performance and security policies.

The Maven virtual registry remains in beta for GitLab Premium and Ultimate customers. Current beta limitations include a maximum of 20 virtual registries per top-level group and 20 upstreams per virtual registry.

We invite enterprise customers to participate in the Maven virtual registry beta program to help shape the final release. Please consider sharing feedback and suggestions in issue 543045.

Core

Pick up where you left off on the new personal homepage: Navigation

You can now access a new personal homepage that consolidates all your important GitLab activities in one place, making it easier to pick up where you left off. The homepage brings together your to-do items, assigned issues, merge requests, review requests, and recently viewed content, helping you navigate GitLab's large surface area and stay focused on what matters the most to you.

Enhanced Admin area groups list (self-managed only): Groups & Projects

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

• Delayed deletion protection: Group deletions now follow the same safe deletion flow used throughout GitLab, preventing accidental data loss.
• Faster interactions: Filter, sort, and paginate groups without page reloads for a more responsive experience.
• Consistent interface: The groups list now matches the look and behavior of other group 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 group management will automatically appear in all group lists throughout the platform.

Updated navigation experience for groups: Groups & Projects

We've made changes to the group overview list to deliver a more consistent and efficient experience across GitLab.

These improvements make it easier to navigate your groups and projects while providing more valuable information at a glance:

• Richer project information: Projects now display stars, forks, issues, merge requests, and relevant dates, giving you a complete activity overview at a glance.
• Streamlined actions: Edit or delete groups and projects directly from the overview using the actions menu. Archived and pending deletion items appear in the Inactive tab.
• Consistent experience: The group overview now matches the look and behavior of other group and project lists throughout GitLab for a more intuitive experience.

These enhancements save time by putting more information and actions at your fingertips. This update also lays the groundwork for future features like bulk editing and advanced filtering options.

Improved inactive item management for groups and projects: Groups & Projects

The Inactive tab now consistently displays all inactive items in one unified location across GitLab. This includes archived projects, projects pending deletion, and groups pending deletion.

This tab is available on the group overview page, as well as in group and project lists throughout Your work, Explore, and the Admin area.

All users with the appropriate permissions can view inactive items, while only group owners and project owners and maintainers can take further actions on them.

As part of this update, a new active parameter is now available in both the Projects and Groups REST APIs, and GraphQL APIs.

Managing inactive content is a critical part of maintaining a GitLab instance.

This update makes it easier to find and recover content that was archived or is pending deletion, allowing you to maintain better control over your GitLab resources while reducing the risk of accidentally losing valuable work.

The clear separation of active from inactive content also provides a more focused search experience when navigating through groups and projects across all areas of GitLab.

Plan

Format markdown tables in the plain text editor: Markdown

Misaligned markdown tables are difficult to read and edit, even though they render correctly.

The new Reformat table feature in the plain text editor's toolbar realigns table columns with a single click, preserving alignment settings and indentation. To use it:

• Select any markdown table in wiki pages, issues, or merge requests.
• From the More options menu, select Reformat table.

This makes documentation maintenance faster and collaboration easier when working with complex tables.

View child task completion in issues: Team Planning

You can now track the progress of issues directly from the child items widget, giving you a status overview at a glance. This enhancement provides real-time visibility into potential bottlenecks when work is already in progress, helping you quickly identify at-risk items and make timely adjustments before sprint deadlines are threatened.

Verify

Variable expansion in environment deployment_tier: Environment Management

You can now use CI/CD variables in the environment:deployment_tier field, making it easier to dynamically configure deployment tiers based on pipeline conditions.

GitLab Runner 18.5: GitLab Runner Core

We're also releasing GitLab Runner 18.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.

Bug fixes:

• Runner update fails on vanilla Kubernetes after updating runner operator from 1.39 to 1.41
• Some container labels have duplicate prefixes

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

Application security testing

Increased rule coverage for secret push protection and pipeline secret detection: Secret Detection

New rules have been added to the GitLab pipeline secret detection. Some existing rules have also been updated to improve quality and reduce false positives. These changes are released in version 7.15.0 of the secrets analyzer.

Original source

Create

Bypass confirmation for enterprise users when reassigning placeholders (SaaS only): Importers

Users with the Owner role for a group can now bypass user confirmation when reassigning placeholders to active enterprise users in that group. This way, enterprise users do not have to keep checking their emails to confirm reassignments. After the time limit for the setting is reached, email confirmation requests are sent again for all new reassignments.

Enterprise users still receive notification emails after the reassignment is complete, ensuring transparency throughout the process.

Ultimate

Expanded AWS region support for GitLab Dedicated (self-managed only): GitLab Dedicated, Switchboard

GitLab Dedicated now supports deployment in all AWS regions, enabling you to select from an expanded list of regions for your primary, secondary, and backup deployment location.

This expansion is enabled by AWS's rollout of io2 disks across all regions, which meet GitLab Dedicated's standards for high availability and disaster recovery.

All newly available regions can be selected when provisioning your GitLab Dedicated instance in Switchboard.

Application security testing

Significantly faster Advanced SAST scanning: SAST

Every minute counts when you're enabling security scans in your merge requests and pipelines.

We routinely ship performance improvements for Advanced SAST, targeting both the engine and its detection rules.

In this release, we're highlighting a specific improvement that cuts scan runtime by as much as 78% in our benchmark and real-world tests.

We've added caching in a performance-sensitive part of the scanning process, leading to significantly faster scans in large repositories.

This improvement is automatically enabled in Advanced SAST analyzer version 2.9.6 and later.

You can see which analyzer version you're using by checking scan job logs.

Operational Container Scanning severity threshold configuration: Software Composition Analysis

You can now configure Operational Container Scanning (OCS) to only return vulnerabilties at or above a certain severity level.

After you set a severity threshold, vulnerabilities below the severity you choose are no longer returned in the Vulnerability Report, API payloads, and other reporting mechanisms.

This can help you focus on the vulnerabilities you want to remediate.

To enable this filtering, set a severity_threshold in your OCS configuration.

We gratefully acknowledge this community contribution from John Walsh.

To learn more about contributing to GitLab, check out the Community Contribution program.

Security risk management

Vulnerability details shows the auto-resolve pipeline ID

When troubleshooting vulnerabilities that have been automatically resolved, and later redetected, it can be helpful to compare the current pipeline to the pipeline where the vulnerability was resolved.

If a vulnerability is automatically resolved, the vulnerability notes in the vulnerability details page now include the pipeline ID where it occurred.

Premium

GitLab Duo Model Selection now generally available: Model Personalization

GitLab Duo Model Selection is now generally available, giving organizations greater control over which AI models power their development workflows.

Owners of top-level groups on Gitlab.com and administrators on Self-Managed and Dedicated can now choose a specific model from a variety of GitLab AI model vendors for use with their GitLab Duo features, accessed through the GitLab-hosted AI gateway.

GitLab users that belong to multiple namespaces on GitLab.com can now also set a default namespace to ensure consistent AI model preferences across all development contexts. For more information on GitLab Duo Model Selection, read the blog.

End user model selection now available with GitLab Duo: Model Personalization

GitLab Duo model selection for end-users is now in public beta on Gitlab.com. Users can now select their preferred model for GitLab Duo Agentic Chat directly in the GitLab UI, giving developers personalized control over their AI assistance experience.

When allowed by namespace owners on GitLab.com, end-users can choose from available GitLab AI Vendor models for use with GitLab Duo Agentic Chat. Namespace owners can continue to set organization-wide model preferences through namespace settings, or allow end-user model selection.

To get started, look for the model dropdown in GitLab Duo Agentic Chat to select your preferred model. Note that changing models will start a fresh conversation, and your preferences will be remembered for future sessions.

GitLab Duo context exclusion: Duo Agent Platform, Duo Chat, Code Suggestions, Vulnerability Management

GitLab Duo context exclusion allows you to control which project content is excluded as context for GitLab Duo. This is helpful to protect sensitive information such as password files and configuration files. You can exclude individual files, specific directories, specific file types, or any combination of these.

This feature is currently in beta. Provide feedback on GitLab Duo context exclusion in issue 566244.

GitLab Duo AI Catalog: Duo Agent Platform, Duo Chat

The GitLab Duo AI Catalog is a centralized hub for discovering and managing AI agents that perform complex tasks like creating merge requests and answering technical questions. You can:

• Browse agents created by the GitLab team and community.
• Create custom agents for your projects.
• Share agents across projects through GitLab Duo Chat (Agentic).

This feature is an experiment and controlled by the global_ai_catalog feature flag:

• For GitLab.com, contact support to enable it for your group.
• For GitLab Self-Managed, enable it in the Admin panel or use the Rails console with Feature.enable(:global_ai_catalog).

To provide feedback, see the feedback issue.

GitLab Duo Agent Platform now available on GitLab Duo Self-Hosted (self-managed only): Self-Hosted Models

GitLab Duo Self-Hosted customers can now access the GitLab Duo Agent Platform in experimental status. The GitLab Duo Workflow Service is now integrated into the existing self-hosted AI gateway Docker image and provides support for AI agents and workflow automation. Administrators can configure a single model for use across all agents.

For more information about the power of GitLab Duo Agent Platform, read the blog.

Automatic Duo Code Review for groups and applications: Code Review Workflow

You can now use group or application settings to enable automatic Duo Code Review for multiple projects. This can help you quickly enable Duo Code Review for all projects in a group, rather than individually enabling specific projects.

This feature is currently available in GitLab.com, and we plan to make it available for GitLab Self-Managed in a future release. Provide feedback in issue 517386.

Additional supported models for GitLab Duo Self-Hosted (self-managed only): Self-Hosted Models

GitLab Self-Managed customers with GitLab Duo Enterprise can now use additional supported models with Gitlab Duo. OpenAI GPT-5 is now supported on Azure OpenAI. Open source OpenAI GPT OSS 20B and 120B aer also now supported on vLLM and Azure OpenAI. To leave feedback on using these models with GitLab Duo Self-Hosted, see issue 523918.

Duo Code Review on GitLab Duo Self-Hosted is generally available (self-managed only): Code Suggestions, Self-Hosted Models

GitLab Duo Code Review on GitLab Duo Self-Hosted is now generally available. Use Code Review on GitLab Duo Self-Hosted to accelerate your development process without compromising on data sovereignty. When Code Review reviews your merge requests, it identifies potential bugs and suggests improvements for you to apply directly. Use Code Review to iterate on and improve your changes before you ask a human to review. This feature includes support for Mistral, Meta Llama, Anthropic Claude, and OpenAI GPT model families.

Provide feedback on Code Review in issue 517386.

Plan

Issue boards now show complete epic hierarchies: Portfolio Management

You can now view all issues from child epics when filtering by a parent epic in issue boards, bringing consistency with how the Issues page already works. This improvement helps you better track and visualize your complete epic hierarchy without missing any issues nested in child epics, making your project management workflow more efficient and reliable.

Core

GitLab Knowledge Graph: Duo Agent Platform, Duo Chat, Code Suggestions, Vulnerability Management

The GitLab Knowledge Graph provides rich code intelligence across your codebase. Developers can understand and navigate their projects with greater context, making it easier to plan changes, perform impact analysis, and work with GitLab Duo agents to accelerate development tasks.

The GitLab Duo Agent Platform leverages the Knowledge Graph to increase the accuracy of AI agents. By mapping files and definitions across a codebase, the Knowledge Graph provides enhanced context that allows Duo agents to understand relationships across your entire local workspace—unlocking faster and more precise responses to complex questions.

This release of the Knowledge Graph focuses on local code indexing, where the CLI turns your codebase into a live, embeddable graph database for RAG. You can install it with a simple one-line script, parse local repositories, and connect via MCP to query your workspace.

Our vision for the Knowledge Graph project is two-fold: building a vibrant community edition that developers can run locally today, which will serve as the foundation for a future, fully integrated Knowledge Graph Service within GitLab.com and self-managed instances.

This feature is in beta status. Provide feedback in issue 160.

Publish OpenTofu modules and providers to the GitLab container registry with CI/CD templates: Infrastructure as Code

The GitLab container registry now supports the media types to

host OpenTofu modules and providers.

Version 3.1.0 of the

OpenTofu CI/CD component supports

a new provider-release template to deploy an OpenTofu provider into the GitLab registry

using the OCI format. Now, you can host private OpenTofu providers directly in GitLab.

In addition, the module-release template now supports a new type input that you can set to oci

to deploy the OpenTofu module in the GitLab registry using the OCI format.

Plan

Configure how to view issues from the Issues page: Portfolio Management

You now have full control over your listing page view, choose which metadata appears and whether to open work items in a drawer, making it easier to focus on the information that matters most to you.

Previously, all metadata fields were always visible, which could make scanning through work items overwhelming. Now you can customize your view by turning on or off specific fields like assignees, labels, dates, and milestones.

With the new toggle that switches between the drawer view and full-page navigation you can quickly review details while maintaining context of your list, or open the full page when you need more screen space for detailed editing and comprehensive navigation.

Enhanced parent filtering for epic and issue lists: Portfolio Management

We've replaced the "epic" filter on the Issues and Epics pages with a more flexible "parent" filter. This change lets you filter by any parent work item, not just epics. You can now easily find child tasks by filtering by their parent issue, or find issues by filtering by their parent epic, giving you better visibility into your work hierarchy across both issue and epic lists.

Text editors toolbar parity: Markdown

The GitLab plain text editor now includes the same formatting options as the rich text editor. The plain text editor toolbar has been updated with a "More options" menu that provides access to advanced formatting tools like:

• Code blocks
• Details blocks
• Horizontal rules
• Mermaid diagrams
• PlantUML diagrams
• Table of contents

Both editors now have consistent button placement and separators, making it easier to switch between editing modes while maintaining access to familiar formatting options.

Verify

Simulate CI/CD Pipelines against different branch: Pipeline Composition

Previously, when using the pipeline editor and validating your changes using the Validate tab, you could only run a simulation for the default branch. In this release, we've expanded this capability. You can now select any branch to simulate pipelines against. This improvement gives you greater flexibility in testing and validating your pipelines. You can ensure they perform as expected across different cases, including your stable branches or feature branches.

GitLab Runner 18.4: GitLab Runner Core

We’re also releasing GitLab Runner 18.4 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:

• FIPS runners fail to start jobs with GitLab Runner 18.2.1
• The chown command for runners with custom ConfigMap & security context constraints (SCC) fails after Operator v1.37.0 upgrade on OpenShift 4.16.27
• Reinstate FF_RETRIEVE_POD_WARNING_EVENTS in GitLab 17.x.x releases due to early removal in 17.2
• All GitLab Runner jobs fail due to filesystem permission errors
• Build jobs fail sporadically with permission denied error
• Gitlab Runner Helm chart upgrade broke the variables
• Enabling FF_USE_FASTZIP does not enable fastzip
• GitLab Runner encounters an UnsupportedOperation error when trying to stop Spot instances created with one-time requests
• Long polling for GitLab Runners does not work properly in Kubernetes deployed environments
• Allow admins to override image:kubernetes:user value

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

Application security testing

Pipeline secret detection now excludes certain files and directories by default: Secret Detection

Pipeline secret detection now automatically excludes certain file types and directories if they have a low likelihood of containing secrets, improving scan performance. These changes are released in analyzer version 7.11.0.

Secret detection analyzer Git fetching improvements: Secret Detection

Version 7.12.0 of the secret detection analyzer adds significant improvements to the way Git commits are fetched. The analyzer now parses --depth and --since options passed from SECRET_DETECTION_LOG_OPTIONS, so you can further specify how many commits you want to scan. The analyzer also selects appropriate fetch strategies based on context, which prevents a known issue where potentially millions of commits were unnecessarily fetched, even with shallow depth configurations.

This enhancement reduces job timeouts, decreases resource consumption, and provides more predictable scan performance. Experience faster secret detection scans, especially in large repositories, with clearer logging that matches the actual fetching behavior.

Software supply chain security

CI/CD job tokens can authenticate Git push requests: System Access

You can now allow CI/CD job tokens generated in your project to authenticate Git push requests to the project’s repository. Enable this with the Job token permissions settings in the UI, or alternatively with the ci_push_repository_for_job_token_allowed parameter in the project's REST API endpoint.

Enhanced controls for who can download job artifacts: Artifact Security

In GitLab 16.11, we added the artifacts:access keyword enabling users to control whether artifacts can be downloaded by all users with access to the pipeline, only users with the Developer role or higher, or no user at all.

In this release, you can now restrict who can download artifacts to only the Maintainer role or higher, giving you one more option for controlling who can download job artifacts.

Original source

Software supply chain security

Enterprise user enhancements (SaaS only): System Access

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.

Ultimate

Application security testing

Improved file location information for Dependency Scanning analyzer: Software Composition Analysis

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.

User-defined source for license information: Software Composition Analysis

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.

Concise DAST job output: DAST

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.

Software supply chain security

Surfacing violations of compliance framework controls (Beta): Compliance Management

Previously, the compliance violations report provided a high-level view of merge request activity for all projects in a group. The available compliance violations related to separation of duty concerns, such as:

• Detecting when an author of a merge request approved their own merge request.
• When a merge request was merged with fewer than two approvals.

However, user feedback revealed that users found violation classifications confusing and difficult to understand, due to not aligning well with actual compliance use cases.

GitLab 18.3 significantly enhances the violations report by expanding beyond separation of duty to include violations of compliance controls and requirements in compliance frameworks.

Each custom compliance framework control has an associated audit event that provides detailed context about violations: who committed the violation, when it occurred, and how to fix it.

This includes the user's name and IP address, plus actionable remediation suggestions.

These improvements give compliance managers more powerful and relevant context to ensure their organization adheres to specific compliance frameworks, while providing reassurance that non-compliance can be effectively identified, rectified, and prevented.

Custom admin role (self-managed only): Permissions

The custom admin role brings granular permissions to the Admin area for GitLab Self-Managed and GitLab Dedicated instances. Instead of granting full access, administrators can now create specialized roles that access only the specific functions needed by users. This feature helps organizations implement the principle of least privilege for administrative functions, reduce security risks from overprivileged access, and improve operational efficiency.

If you have questions, want to share your implementation experience, or would like to engage directly with our team about potential improvements, see the feedback issue.

Instance level compliance and policy management (Beta) (self-managed only): Compliance Management, Security Policy Management

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.

Security risk management

Grant pipeline execution policies access to CI/CD configurations via API: Security Policy Management

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.

Group by OWASP 2021 in the vulnerability report: Vulnerability Management

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.

Scan execution policy templates: Security Policy Management

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.

Security policy audit events: Security Policy Management

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.

Service account and access token exceptions for approval policies: Security Policy Management

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.

Premium

Code Review available on GitLab Duo Self-Hosted (Beta) (self-managed only): Code Suggestions, Self-Hosted Models

You can now use GitLab Duo Code Review on GitLab Duo Self-Hosted. This feature is in beta on GitLab Duo Self-Hosted, with support for Mistral, Meta Llama, Anthropic Claude, and OpenAI GPT model families.

Use Code Review on GitLab Duo Self-Hosted to accelerate your development process without compromising on data sovereignty. When Code Review reviews your merge requests, it identifies potential bugs and suggests improvements for you to apply directly. Use Code Review to iterate on and improve your changes before you ask a human to review.

Provide feedback on Code Review in issue 517386.

Customize instructions for GitLab Duo Code Review: Code Review Workflow

Enforce consistent code review standards across your projects with custom instructions for GitLab Duo Code Review. Define specific review criteria for different file types using glob patterns, ensuring language-specific conventions are applied where they matter most.

With custom instructions, you can:

• Describe your team's code review standards
• Use glob patterns to define file-specific instructions
• Observe clearly labeled feedback that references your custom instructions

Simply create a .gitlab/duo/mr-review-instructions.yaml file in your repository with your custom instructions. GitLab Duo will automatically incorporate these instructions into its reviews, citing the specific instruction group when providing feedback.

Help us improve this feature by sharing your thoughts and suggestions in our feedback issue.

Bring your own models to GitLab Duo Self-Hosted (Beta) (self-managed only): Self-Hosted Models

GitLab Duo Self-Hosted now enables you to bring your own model to use with GitLab Duo features. This feature is in beta, and available to all GitLab Self-Managed customers with GitLab Duo Enterprise. Instance administrators can configure any compatible model for use with a supported GitLab Duo feature.

This feature makes GitLab Duo Self-Hosted more flexible, but GitLab cannot guarantee that all GitLab Duo features will work with every compatible model. Instance administrators are responsible for validating the compatibility and performance of their chosen model. GitLab does not provide technical support for issues specific to your chosen model or platform.

Hybrid model selection on GitLab Duo Self-Hosted (Beta) (self-managed only): Self-Hosted Models

You can now use a mix of GitLab AI vendor models and privately configured self-hosted models on GitLab Duo Self-Hosted. This feature is in beta and available on GitLab Self-Managed to all GitLab Duo Enterprise customers.

With hybrid models on GitLab Duo Self-Hosted, GitLab Self-Managed instance administrators can now choose between a self-hosted model and self-hosted AI gateway, or a GitLab AI vendor model and the GitLab-hosted AI gateway, on a feature-by-feature basis. This enables administrators to balance their security and scalability requirements. To provide feedback on hybrid model selection, see issue 561048.

More models available for use with GitLab Duo Self-Hosted (self-managed only): Self-Hosted Models

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.

Plan

OAuth apps support SSO authentication: Pages, System Access

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.

Bulk edit epic assignees, milestones, and more: Portfolio Management

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.

Create

Faster workspace startup with shallow cloning: Workspaces

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.

Software supply chain security

AWS Secrets Manager support for GitLab CI/CD: Secrets Management

Secrets stored in AWS Secrets Manager can now be easily retrieved and used in CI/CD jobs. Our new integration with AWS simplifies the process of interacting with AWS Secrets Manager through GitLab CI/CD, helping our AWS customers streamline build and deploy processes!

Thank you to Markus Siebert and Henry Sachs who helped build this feature through GitLab's Co-Create program!

SAML SSO support for session timeout attribute: System Access

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.

Additional service account email configuration options: System Access

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.

Core

Duo Agent Platform in Visual Studio (Beta): Editor Extensions

We are excited to announce the public beta release of the Duo Agent Platform for Visual Studio! With this release, Visual Studio users can now access Duo Agent Platform's advanced AI-powered capabilities directly within their IDE.

The Duo Agent Platform brings two powerful features to your workflow:

• Agentic chat: Quickly accomplish conversational tasks such as creating and editing files, searching your codebase with pattern matching and grep, and getting instant answers about your code—all without leaving Visual Studio.
• Agent flows: Tackle larger, more complex tasks with comprehensive planning and implementation support. Agent flows help you turn high-level ideas into architecture and code, leveraging GitLab resources like issues, merge requests, commits, CI/CD pipelines, and security vulnerabilities.

Both features offer intelligent search across documentation, code patterns, and project information, empowering you to move seamlessly from quick edits to in-depth project analysis.

Try the Duo Agent Platform beta in Visual Studio today and experience a new level of productivity and AI assistance in your development workflow.

New CLI commands for GitLab-managed OpenTofu and Terraform states: GitLab CLI, Infrastructure as Code

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.

Kubernetes 1.33 support: Deployment Management

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.

New navigation experience for groups in Your work: Groups & Projects

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.

Enhanced Admin area projects list (self-managed only): Groups & Projects

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.

Plan

Embedded views (powered by GLQL): Markdown, Wiki, Team Planning

This release introduces embedded views, powered by GLQL, to general availability. Create and embed dynamic, queryable views of GitLab data directly where your work lives: in wiki pages, epic descriptions, issue comments, and merge requests.

Embedded views provide a stable foundation for teams to track work progress without navigating between multiple locations. Query issues, merge requests, epics, and other work items using familiar syntax, then display the results as tables or lists with customizable fields and filtering.

Embedded views transform static documentation into living dashboards that stay current with your project data, helping teams maintain context and improve collaboration across their workflows.

We welcome your feedback as we continue to enhance embedded views. Please share your thoughts and suggestions in our feedback issue.

Control unique domains default for GitLab Pages sites: Pages

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.

Enhancements to wiki functionality: Wiki

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.

Create

Migration by direct transfer: Importers

Migration by direct transfer is now generally available. To migrate GitLab groups and projects between GitLab instances by direct transfer, you can use the GitLab UI or the REST API.

Compared to migration by uploading an export file, direct transfer:

• Works more reliably with large projects.
• Supports migrations with a larger version gap between the source and destination instances.
• Offers better insights into the migration process and results.

On GitLab.com, migration by direct transfer is enabled by default. On GitLab Self-Managed and GitLab Dedicated, an administrator must enable the feature.

New Web IDE source control operations: Web IDE

We're excited to announce additional source control functionalities in the Web IDE. You can manage your Git workflow more efficiently without leaving your browser. In the Source Control panel, you can now:

• Create and delete branches.
• Create a branch from any existing branch as your base.
• Amend your last commit for quick fixes.
• Force push changes directly from the interface.

These enhancements bring Git operations right to your fingertips. For information about the functionalities available to you, see Use source control.

Verify

GitLab Runner 18.3: GitLab Runner Core

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.

Software supply chain security

Fine-grained permissions for CI/CD job tokens: Permissions

Pipeline security just got more flexible. Job tokens are ephemeral credentials that provide access to resources in pipelines. Until now, these tokens inherited full permissions from the user, often resulting in unnecessarily broad access capabilities.

With our new fine-grained permissions for job tokens feature, you can now precisely control which specific resources a job token can access within your projects. This allows you to implement the principle of least privilege in your CI/CD workflows, granting only the minimal access necessary for jobs to complete their tasks when accessing your projects with the CI/CD job token.

We're actively working to add additional fine-grained permissions to reduce reliance on long-lived tokens in pipelines.

SSH key security warnings: System Access

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.

Original source

Ultimate

Package

Improve security with immutable container tags (Beta): Container Registry

Container registries are critical infrastructure for modern DevSecOps teams.

However, even with protected container tags, organizations still face a challenge:

After a tag is created, users with sufficient permissions can alter it.

This creates risks for teams that rely on specific tagged versions of container images for production stability.

Any modification—even by authorized users—can introduce unintended changes or compromise deployment integrity.

With immutable container tags, you can protect container images from unintended changes.

After a tag is created that matches an immutable rule, no one can modify the container image.

You can now:

• Create up to 5 total protection rules per project (combining both protected and immutable rules) using RE2 regex patterns.
• Protect critical tags like latest, semantic versions (for example, v1.0.0), or release candidates from any modification.
• Ensure immutable tags are automatically excluded from cleanup policies.

Immutable container tags require the next-generation container registry, which is enabled by default on GitLab.com.

For GitLab Self-Managed instances, you must enable the metadata database
to use immutable container tags.

Application security testing

Container Scanning support for multi-architecture container images: Software Composition Analysis

Container Scanning now ships with Linux Arm64 container image variants. When running
on a Linux Arm64 runner, the analyzer will no longer require emulation, resulting in a faster
analysis. In addition, you can now scan multi-architecture images by
setting the TRIVY_PLATFORM environment variable to the platform you want to scan.

Static reachability support for JavaScript: Software Composition Analysis

Composition Analysis now supports Static Reachability for JavaScript libraries.

You can use the data produced by static reachability as part of your triage and remediation
decision making. Static reachability data can also be used with EPSS, KEV, and CVSS scores
to provide a more focused view of your vulnerabilities.

Improved support for verifying successful DAST login: DAST

Previously, the DAST_AUTH_SUCCESS_IF_AT_URL variable required an exact URL match to verify successful authentication. This worked well for applications with static landing pages, but posed difficulties for applications where post-login URLs contain dynamic elements for each login.

Now, you can use wildcard patterns in the DAST_AUTH_SUCCESS_IF_AT_URL variable to match dynamic URL patterns. This enhancement provides the flexibility needed to verify authentication success even when the exact URL changes between sessions.

DAST support for time-based one-time password MFA: DAST

Dynamic Analysis now supports time-based one-time password (TOTP) multi-factor authentication.

You can run DAST scans on projects with TOTP MFA enabled to ensure comprehensive security testing.

This enhancement delivers more accurate scan results by testing applications in configurations that mirror
production environments where MFA is deployed.

Software supply chain security

New group overview compliance dashboard: Compliance Management

The compliance center is the central location for compliance teams to manage their compliance status
reporting, violations reporting, and compliance frameworks for their group.

The new group overview compliance dashboard gives compliance managers an aggregated view on compliance
information across all of the projects in a group. This first iteration displays the following information:

• % of projects covered by a certain compliance framework.
• % of failed requirements for all projects in a group.
• % of failed controls for all projects in a group.
• The specific frameworks that require 'attention'.

With this new group overview, compliance managers now have a single unified view that
provides them with a clear high-level picture, of their compliance posture.

Deactivate streaming to an audit streaming destination: Audit Events

Previously, there was no way to temporarily deactivate streaming to an audit streaming destination. You might
want to do this for a number of reasons, including to troubleshoot stream connectivity or to make changes to
configuration without deleting the configuration and starting again.

With GitLab 18.2, we've added the ability to toggle an audit stream as active or inactive. When the audit stream
is inactive, audit events are no longer streamed to the chosen destination. When reactivated, audit events are
again streamed to the chosen destination.

Filter functionality for all audit streaming destinations: Compliance Management

Previously, certain audit streaming destinations did not have all of the available filtering capability.

We now support filter functionality for all destinations via the UI, including the ability to filter:

• By audit event type.
• By groups or projects.

This change also means that audit event destinations such as AWS and GCP can now filter through audit events.

Credentials inventory now includes service account tokens: System Access

GitLab now supports service account tokens in the credentials inventory, giving you better visibility and control over the various authentication methods used across your software supply chain. The credentials inventory provides a complete picture of credentials used across your organization.

Custom admin role in beta (self-managed only): Permissions

The custom admin role brings granular permissions to the Admin Area for GitLab Self-Managed and GitLab Dedicated instances. Instead of granting full access, administrators can now create specialized roles that access only the specific functions needed by users. This feature helps organizations implement the principle of least privilege for administrative functions, reduce security risks from overprivileged access, and improve operational efficiency.

We're actively seeking community feedback on this feature. If you have questions, want to share your implementation experience, or would like to engage directly with our team about potential improvements, please visit our feedback issue.

Security risk management

Download a PDF export of security reports

To communicate the state and progress of your vulnerability management efforts to other stakeholders,
you can now export the security dashboard for each project or group as a PDF document.

Centralized Security Policy Management (Beta) (self-managed only): Security Policy Management

In large organizations where compliance is critical, teams often struggle with fragmented policies
scattered across multiple projects and groups. Without centralized visibility, ensuring consistent
enforcement becomes a time-consuming challenge while increasing compliance risk.

Centralized security policy management introduces a unified approach to creating, managing,
and enforcing security policies across your entire GitLab organization through a single designated
compliance and security policy (CSP) group. This allows security teams to:

• Define policies once and apply everywhere: Create instance-wide security policies once through the CSP and automatically enforce the policies across all groups and projects.
• Configure business unit policies: Top-level groups can configure their own distinct set of policies while inheriting organization policies from the CSP group.
• Ensure adherence to principle of least privilege: Establish a central policy management layer enforced for the instance.

This beta release establishes the foundational framework for centralized policy management,
with support for all existing security policy types, configurable for groups, projects, or instance.

Vulnerability ID added to vulnerability report CSV export

Previously, the CSV export of the vulnerability report did not include vulnerability IDs.

You can now find the ID of each vulnerability listed in the CSV export.

Reachability filter in the vulnerability report: Vulnerability Management

Users can now filter data in the vulnerability report to include only reachable vulnerabilities.

Reachable vulnerabilities represent vulnerabilities that are both:

• On the Common Vulnerabilities and Exposures (CVE) list.
• Part of a library that is explicitly imported.

Vulnerability GraphQL API returns additional information: Vulnerability Management

You can now use the GraphQL API to determine the pipeline when the vulnerability was
introduced and when it was last detected. The Vulnerability GraphQL API now includes:

• initialDetectedPipeline: Use to retrieve additional commit information about when the vulnerability was introduced, such as the author's user name.
• latestDetectedPipeline: Use to retrieve additional commit information about when the vulnerability was removed, such as the commit SHA.

Source branch pattern exceptions for approval policies: Security Policy Management

Previously, teams using GitFlow often faced approval deadlocks when merging release/* branches to main,
as most contributors had already participated in release development and then couldn't serve as approvers.

Branch pattern exceptions in merge request approval policies solve this by automatically bypassing approval
requirements for specific source-target branch combinations.

Configure strict approvals for feature-to-main merges while allowing streamlined release-to-main workflows.

Key capabilities:

• Pattern-based configuration: Define source branch patterns like release/* or hotfix/*
  that bypass approval requirements
• Seamless integration: Branch exceptions integrate directly into existing merge request approval
  policies and are configurable through the UI or policy.yml file.

This eliminates the need for complex workarounds while preserving the security benefits of merge request
approval policies for standard development workflows.

Display dependency paths: Dependency Management

Previously, it was difficult to determine whether a dependency was a direct dependency, or a transient dependency imported by a descendant of the dependency.

You can now determine whether a library is primarily or transitively imported using the new dependency paths feature. You can find dependency paths on the project and group dependency list as well as in the vulnerability details. This capability allows developers to determine the most efficient path to a fix depending on how the library is imported.

Security Inventory for comprehensive asset visibility now in beta: Security Asset Inventories

AppSec teams need comprehensive visibility into their organization's security posture across all assets. Previously, GitLab's security workflows focused primarily on project-level scanner configuration and project-level vulnerabilities, making it difficult to understand coverage gaps and make efficient, risk-based prioritization decisions.

Security Inventory provides a centralized view of the security posture across your GitLab instance, enabling AppSec teams to:

• Get complete visibility into security coverage across projects and groups
• Identify assets that lack security scanning or have configuration gaps
• Make informed, risk-based decisions about where to focus security efforts
• Track security posture improvements over time

This feature helps bridge the gap between individual project security and organization-wide security strategy, giving you the asset inventory foundation needed for effective security program management.

Premium

Duo Agent Platform in the IDE (Beta): Editor Extensions

The Duo Agent Platform brings agentic chat and agent flows directly into VS Code and JetBrains IDEs, enabling natural conversation-based interaction with your codebase and GitLab projects.

Agentic chat is designed for quick, conversational tasks like creating and editing files, searching across your codebase with pattern matching and grep, and getting immediate answers about your code.

Agent flows handle larger implementations and comprehensive planning, taking high-level ideas from concept to architecture while accessing GitLab resources including issues, merge requests, commits, CI/CD pipelines, and security vulnerabilities.

Both provide intelligent search capabilities for documentation, code patterns, and project discovery to help you accomplish everything from quick edits to complex project analysis.

The platform also supports Model Context Protocol (MCP) for connecting to external data sources and tools, allowing AI features to leverage context beyond GitLab.

Learn more in our blog GitLab Duo Agent Platform Public Beta: Next-gen AI orchestration and more.

To get started, see the Duo Agent Platform documentation,
VS Code setup guide,
and JetBrains setup guide.

Group and project controls for Premium and Ultimate with GitLab Duo: Code Suggestions, Duo Chat

GitLab Premium and Ultimate users can now change the availability of Code Suggestions and GitLab Duo Chat in the IDE for groups and projects. Previously, you could change the availability for the instance or top-level group only.

Mistral Small now available for GitLab Duo Self-Hosted (self-managed only): Self-Hosted Models

You can now use Mistral Small on Gitlab Duo Self-Hosted. This model is available on GitLab Self-Managed instances, and is the first fully compatible open source model for GitLab Duo Chat and Code Suggestions on GitLab Duo Self-Hosted.

Plan

Custom workflow statuses for issues and tasks: Team Planning

Move beyond the basic open/closed system with configurable status that lets you track work items through
your team's actual workflow stages.

Instead of relying on labels, you can now define custom statuses that accurately
reflect your process. With configurable statuses, you can:

• Define custom workflows that match your team's actual process.
• Replace workflow labels with proper statuses that are easier to find, update, and report on.
• Clarify completion outcomes beyond closing an issue using "Done" or "Canceled".
• Filter and report accurately on work item status for better project insights.
• Use status in issue boards with automatic updates when issues move between columns.
• Bulk update status across multiple work items for efficient workflow management.
• Track dependencies with status visibility for linked work items.

Custom workflow statuses also support quick actions in comments and automatically syncs with GitLab's
open/closed system.

Help us improve this feature by sharing your thoughts and suggestions in our
feedback issue.

Configure epic display preferences: Portfolio Management

You now have full control over which metadata appears when you view your list of
work items, making it easier to focus on the information that matters most to you.

Previously, all metadata fields were always visible, which could make scanning through work
items overwhelming. Now you can customize your view by turning on or off specific fields
like assignees, labels, dates, and milestones.

Open epics in a drawer or the full page on the Epics page: Portfolio Management

You can now choose how epics open from the list page with a new toggle that switches between drawer view and
full-page navigation.

Use the drawer to quickly review epic details while maintaining context of your epic list,
or open the full page when you need more screen space for detailed editing and comprehensive navigation.

Assign milestones to epics for enhanced long-term planning: Portfolio Management

You can now assign milestones directly to epics, creating a natural planning cascade from strategic initiatives down to execution. This enhancement helps you align longer-term planning cadences, like quarterly planning or SAFe program increments, with epics. At the same time, you can keep iterations focused on development sprints.

With this clear hierarchy in place, you can reduce administrative overhead and gain better visibility into how your strategic initiatives progress against organizational timeframes.

Assign epics to team members: Portfolio Management

You can now assign epics to individuals, making it clear who is responsible for overseeing strategic initiatives. Epic assignees help you identify ownership at the portfolio level, enabling faster decision-making and clearer accountability for long-term objectives. Teams can quickly see who to contact about epic progress, dependencies, or scope changes.

Create

Map workspace Kubernetes agents for the instance (self-managed only): Workspaces

GitLab administrators can now map enabled workspace Kubernetes agents for the instance. Users can then create workspaces from any group or project in that instance.

This significantly increases workspace scalability by allowing organizations to provision workspace Kubernetes agents once, and make those agents accessible to all current and future projects across the entire instance.

Core

Administrators can reassign contributions without user confirmation (self-managed only): Importers

Administrators can now reassign contributions from placeholder users to active users without user confirmation.

This feature addresses a key challenge for larger organizations where the process stalled when users did not check their emails to approve reassignments.

On GitLab instances where user impersonation is enabled, administrators can maintain data integrity while streamlining user management workflows.

Users still receive notification emails after the reassignment is complete, ensuring transparency throughout the process.

Reassign from placeholder users to inactive users (self-managed only): Importers

Previously, administrators could reassign contributions and memberships from placeholder users to active users only.

On GitLab Self-Managed, administrators can now also reassign contributions and memberships from placeholder users to inactive users.

This feature permits you to preserve the contribution history and membership information of blocked, banned, or deactivated users on your GitLab instance.

Administrators must first enable this setting and, when enabled, this setting streamlines user management by
skipping user confirmation during reassignment while maintaining secure access control.

Plan

Sorting and pagination for GLQL views: Wiki, Team Planning

This release introduces enhanced sorting and pagination for GLQL views, making it easier to work with large datasets.

You can now sort by key fields including due dates, health status, and popularity to quickly find the most relevant items. The new "Load more" pagination system provides better control over data loading, replacing overwhelming full-page results with manageable chunks that load on demand.

These improvements help teams efficiently navigate complex project data and focus on what matters most at any given moment.

Work item references and editor improvements for GitLab Flavored Markdown: Markdown

You can now reference issues, epics, and work items using a unified [work_item:123] syntax in GitLab Flavored Markdown. This new syntax works alongside existing reference formats like #123 for issues and &123 for epics, and supports cross-project references with [work_item:namespace/project/123].

The plain text editor also includes a new preference to maintain cursor indentation when you press Enter, making it easier to write structured content like nested lists and code blocks.

Create

New merge request homepage: Code Review Workflow

Managing code reviews across multiple projects can be overwhelming when you're juggling dozens of merge requests
as both an author and reviewer.

The new merge request homepage transforms how you navigate your review workload
by intelligently prioritizing what needs your attention right now, with two powerful viewing modes:

• Workflow view organizes merge requests by their review state, grouping work by its stage in the code review workflow.
• Role view groups your merge requests by whether you're the author or reviewer, giving you a clear separation of responsibilities.

The Active tab shows merge requests requiring attention, Merged displays recently completed work,
and Search provides comprehensive filtering capabilities.

The new homepage also expands your visibility by combining both authored and assigned merge requests,
ensuring you never miss work that's been delegated to you.

Verify

Trigger jobs can mirror the downstream pipeline status: Pipeline Composition

Previously, trigger jobs using strategy:depend had limitations when dealing with complex pipeline states such as manual jobs, blocked pipelines, or retried pipelines with changing statuses during execution. This could make it seem like the downstream pipeline was actively running, when it was actually blocked on a manual job.

The new strategy:mirror keyword provides more nuanced status reporting by mirroring the exact real-time status of the downstream pipeline. Statuses include intermediate states like running, manual, blocked, and canceled. This gives teams complete visibility into the current state of their downstream pipeline without breaking the existing workflow.

GitLab Runner 18.2: GitLab Runner Core

We’re also releasing GitLab Runner 18.2 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:

• Runners fail in FIPS mode after you upgrade to GitLab Runner 18.1.0
• Unable to start job pods with FF_USE_DUMB_INIT_WITH_KUBERNETES_EXECUTOR
• The ubi-fips image is not the default helper image flavor for GitLab Runner FIPS
• Runners remain offline for an extended period after you disable GitLab maintenance mode

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

Application security testing

Improved archive file support for Container Scanning: Software Composition Analysis

GitLab 18.2 brings improved archive file scanning support to Container Scanning.

If a vulnerability in a particular package is found in multiple images, you now see a vulnerability attributed to each scanned image.

Original source

Software supply chain security

Compromised password detection for native GitLab credentials (SaaS only): System Access

GitLab.com now performs a secure check of your account credentials when you sign in to GitLab.com.

If your password is part of a known leak, GitLab displays a banner and sends you an email notification.

These notifications include instructions for how to update your credentials.

For maximum security, GitLab recommends using a unique, strong password for GitLab, enabling two-factor authentication, and regularly reviewing your account activity.

Note: This feature is only available for native GitLab usernames and passwords. SSO credentials are not checked.

Ultimate

Application security testing

DAST detection parity with secret detection default rules: DAST

The DAST analyzer now automatically ingests the same default secret detection rules that are used by GitLab's Secret Detection analyzer. This improvement ensures consistency in the types of secrets detected by both.

PHP support for Advanced SAST: SAST

We have added PHP support to GitLab Advanced SAST.

To use this new cross-file, cross-function scanning support, enable Advanced SAST.

If you have already enabled Advanced SAST, PHP support is automatically activated.

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

Software supply chain security

Define a Name for external custom controls: Compliance Management

Previously, you couldn't define a name for an external custom control when creating a custom compliance framework, which made it difficult to identify external controls when listed alongside GitLab controls.

We've now added a Name field as part of the workflow when defining an external custom control, so you can create multiple external custom controls and clearly define each one with its own unique name.

Pagination for requirements in compliance frameworks UI: Compliance Management

When creating a compliance framework, you can specify a maximum of 50 requirements.

However, it becomes very difficult to navigate a compliance framework with this many requirements because they consume a lot of space in the user interface.

In this release, we have introduced pagination for requirements to make it easier for users to navigate, find, and select requirements when there is a large number of them attached to a compliance framework.

UI performance and filtering improvements for compliance center: Compliance Management

We have continued to improve the UI performance and filtering options provided by the compliance center. In this release, we have:

• Improved the UI speed and performance of the Edit Framework page, especially where there are many requirements and projects on the page.
• Introduced new filtering options so that you can group by requirement, project, or framework in the Compliance status report tab in the compliance center.

By delivering these improvements, we continue to ensure that the compliance center and associated functions continue to perform at scale for customers who regularly use the compliance center.

Control status pop-up in the compliance status report: Compliance Management

Controls in the compliance status report have three different statuses:

• Pass
• Fail
• Pending

No matter the number of controls that are attached to the requirement, if at least one control was 'pending', the entire requirement row was shown as 'pending' as well. This deviated from the established UX pattern for visualizing failed controls, where the requirement would show the number of controls associated with the requirement, even when there was at least one control that fails.

To provide further context and information for 'pending' controls, we now provide a hover over pop-up on the requirement row status, with the status of each control listed. You can now understand which controls are pending, and which are potentially succeeding and failing, rather than just seeing a single status for 'pending'.

Increased SAST coverage for Duo Vulnerability Resolution: Vulnerability Management

Previously, you had to manually resolve detected vulnerabilities with these Common Weakness Enumeration (CWE) identifiers:

• CWE-78 (Command Injection)
• CWE-89 (SQL Injection)

Now, Duo Vulnerability Resolution can automatically fix these vulnerabilities.

Security risk management

Filter by component version in the dependency list

The dependency lists now supports filtering by a component's version number. You can select multiple versions (for example, version=1.1,1.2,1.4) but ranges are not supported. This feature is available in both groups and projects.

Variable precedence controls in pipeline execution policies: Security Policy Management

Security teams often strike a delicate balance between security assurance and developer experience. It's critical to ensure security scans are properly enforced, but security analyzers can require specific inputs from development teams to properly execute. With variable precedence controls, security teams now have granular control over how variables are handled in pipeline execution policies through the new variables_override configuration option.

Using this new configuration, you can now:

• Enforce container scanning policies that allow project-specific container image paths (CS_IMAGE).
• Allow lower risk variables like SAST_EXCLUDED_PATHS while blocking high risk variables like SAST_DISABLED.
• Define globally shared credentials that are secured (masked or hidden) with global CI/CD variables, such as AWS_CREDENTIALS, while allowing project-specific overrides where appropriate through project-level CI/CD variables.

This powerful feature supports two approaches:

• Lock variables by default (allow: false): Lock all variables except specific ones you list as exceptions.
• Allow variables by default (allow: true): Allow variables to be customized, but restrict critical risks by listing them as exceptions.

To improve traceability and troubleshooting when a pipeline execution policy is the source of an CI/CD job, we're also introducing job logs to help developers and security teams identify the jobs executed by a policy. The job logs provide details on the impact of variable overrides to help you understand if variables are overridden or locked by policies.

Real-world impact

This enhancement bridges the gap between security requirements and flexibility for developers:

• Security teams can enforce standardized scanning while allowing project-specific customizations.
• Developers maintain control over project-specific variables without requesting policy exceptions.
• Organizations can implement consistent security policies without disrupting development workflows.

By solving this critical variable control challenge, GitLab enables organizations to implement robust security policies without sacrificing the flexibility teams need to deliver software efficiently.

Premium

Multiple matches per file in code search

Exact code search (in beta) now consolidates multiple search results from the same file into a single view. This improvement:

• Preserves context between adjacent matches instead of displaying isolated lines.
• Reduces visual clutter by eliminating duplicate content when matches are close together.
• Enhances navigation by clearly showing the number of matches per file.
• Improves readability by displaying code as you would see it in your editor.

With this change, finding and understanding code patterns across your repositories is now more efficient.

Plan

Epic support for GitLab Query Language views Beta: Wiki, Team Planning

We've made a significant improvement to GitLab Query Language (GLQL) views. You can now use epic as a type in your queries to search for epics across groups, and query by parent epic!

This is a huge step forward for our planning and tracking capabilities, making it easier than ever to query and organize at the epic level.

Create

Enhanced CODEOWNERS file validation with permission checks: Source Code Management

GitLab now provides enhanced validation for CODEOWNERS files that goes beyond basic syntax checking. When viewing a CODEOWNERS file, GitLab automatically runs comprehensive validations to help you identify both syntax and permission issues before they affect your merge request workflows.

The enhanced validation checks the first 200 unique user and group references in your CODEOWNERS file, and verifies that:

• All referenced users and groups have access to the project.
• Users have the necessary permissions to approve merge requests.
• Groups have at least Developer-level access or higher.
• Groups contain at least one user with merge request approval permissions.

This proactive validation helps prevent approval workflow disruptions by catching configuration issues early, ensuring your Code Owners can actually fulfill their review responsibilities when merge requests are created.

Custom workspace initialization with postStart events: Workspaces

GitLab workspace now supports custom postStart events in your devfile, allowing you to define commands that automatically execute after workspace startup. Use these events to:

• Set up development dependencies.
• Configure your environment.
• Run initialization scripts that prepare your project for immediate productivity without manual intervention.

Duo Code Review is now generally available: Code Review Workflow

Duo Code Review is now generally available and ready for production use. This AI-powered code review assistant transforms the traditional code review process by providing intelligent, automated feedback on your merge requests. It helps identify potential bugs, security vulnerabilities, and code quality issues before human reviewers get involved, making the entire review process more efficient and thorough. It includes:

• Automated initial review: Duo Code Review analyzes your code changes and provides comprehensive feedback on potential issues, improvements, and best practices.
• Interactive refinement: Mention @GitLabDuo in merge request comments to get targeted feedback on specific changes or questions.
• Actionable suggestions: Many suggestions can be applied directly from your browser, streamlining the improvement process.
• Context-aware analysis: Leverages understanding of the changed files to provide relevant, project-specific recommendations.

To request a code review:

• In your merge request, add @GitLabDuo as a reviewer using the /assign_reviewer @GitLabDuo quick action, or assign GitLab Duo directly as a reviewer.
• Mention @GitLabDuo in comments to ask specific questions or request focused feedback on any discussion thread.
• Enable automatic reviews in your project settings to have GitLab Duo automatically review all new merge requests.

Duo Code Review helps teams maintain higher code quality standards while reducing the time spent on manual review cycles. By catching issues early and providing educational feedback, it serves as both a quality gate and a learning tool for development teams.

Watch an overview of Duo Code Review in action from our beta release.

Share your experience and feedback in issue 517386 to help us continue improving this feature.

Package

Maven virtual registry now available in beta: Virtual Registry

The Maven virtual registry simplifies Maven dependency management in GitLab. Without the Maven virtual registry, you must configure each project to access dependencies from Maven Central, private repositories, or the GitLab package registry. This approach slows builds with sequential repository queries and complicates security auditing and compliance reporting.

The Maven virtual registry addresses these issues by aggregating multiple upstream repositories behind a single endpoint. Platform engineers can configure Maven Central, private registries, and GitLab package registries through one URL. Intelligent caching improves build performance and integrates with GitLab's authentication systems. Organizations benefit from reduced configuration overhead, faster builds, and centralized access control for improved security and compliance.

The Maven virtual registry is currently available in beta for GitLab Premium and Ultimate customers on both GitLab.com and GitLab Self-Managed. The GA release will include additional capabilities, such as a web-based user interface for registry configuration, shareable upstream functionality, lifecycle policies for cache management, and enhanced analytics. Current beta limitations include a maximum of 20 virtual registries per top-level groups and 20 upstreams per virtual registry, with API-only configuration available during the beta period.

We invite enterprise customers to participate in the Maven virtual registry beta program to help shape the final release. Beta participants will receive early access to the capabilities, direct engagement with GitLab product teams, and priority support during evaluation. To join the beta program, express interest and provide your use case details in issue 498139, and share feedback and suggestions in issue 543045.

Software supply chain security

Subscribe to service account pipeline notifications: System Access

You can now subscribe to notifications for pipeline events triggered by service accounts. Notifications are sent when the pipeline passes, fails, or is fixed. Previously, these notifications were only sent to the service account's email address if the service account has a valid custom email address.

Thank you Densett, Gilles Dehaudt, Lenain, Geoffrey McQuat, and Raphaël Bihoré for your contribution!

Core

New accessLevels argument for projectMembers in GraphQL API: Groups & Projects

We're excited to announce the addition of the accessLevels argument to the projectMembers field in our GraphQL API. Use this argument to filter project members by access level directly from an API call. Previously, you had to fetch an entire list of project members and apply filters locally, which added significant computational overhead. Now, analyzing project permissions and generating ownership graphs is faster and more resource-efficient. This enhancement is particularly valuable to organizations managing large-scale deployments with complex permission structures.

Create

Enhanced merge request review experience with review panel: Code Review Workflow

When you review a merge request, it can be valuable to see all of the comments and feedback you've provided before you submit your review. Previously, this experience was fragmented between the final comment and an additional pop-up to see your pending comments, making it hard to get the complete overview.

When conducting code reviews, you can now access a dedicated drawer that consolidates all your pending draft comments in one organized view. The enhanced review panel moves the review submission interface to a more accessible location, and provides a numbered badge showing your pending comment count. When you open the panel, you'll see all your draft comments organized in a scrollable list, making it easier to review and manage your feedback before submitting.

View downstream pipeline job logs in VS Code: Editor Extensions

The GitLab Workflow extension for VS Code now displays job logs from downstream pipelines directly in your editor. Previously, viewing logs from child pipelines required switching to the GitLab web interface.

This feature was developed through the GitLab Co-create program. Special thanks to Tim Ryan for making this contribution!

Verify

GitLab Runner 18.1: GitLab Runner Core

We're also releasing GitLab Runner 18.1 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:

If you upgrade to GitLab 17.10 or 17.11, runners might receive a 404 response when they request jobs.

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

Software supply chain security

View inactive personal access tokens: System Access

GitLab automatically deactivates access tokens after they expire or are revoked. You can now review these inactive tokens. Previously, access tokens were no longer visible after they became inactive. This change enhances traceability and security of these token types.

Filter for bot and human users (self-managed only): System Access

Established GitLab instances can often have large numbers of human and bot users. You can now filter the users list in the Admin area by user type. Filtering users can help you:

• Quickly identify and manage human users separately from automated accounts.
• Perform targeted administrative actions on specific user types.
• Simplify user auditing and management workflows.

ORCID identifier in user profile: User Profile

GitLab now supports ORCID identifiers in user profiles, making GitLab more accessible and valuable for researchers and the academic community. ORCID (Open Researcher and Contributor ID) provides researchers with a persistent digital identifier that distinguishes them from other researchers and supports automated linkages between researchers and their professional activities, ensuring their work is properly recognized.

This feature was developed as a community contribution by Thomas Labalette and Erwan Hivin, master students at Artois University, under the supervision of Daniel Le Berre, addressing a long-standing request from the academic community.

Achieve SLSA Level 1 compliance with CI/CD components: Artifact Security

You can now achieve SLSA Level 1 compliance using GitLab's new CI/CD components for signing and verifying SLSA-compliant artifact provenance metadata generated by GitLab Runner. The components wrap Sigstore Cosign functionality in reusable modules that can be easily integrated into CI/CD workflows.

Original source

Rate limits for Groups, Projects, and Users API (SaaS only): Groups & Projects

We have added API rate limits for projects, groups, and users to improve platform stability and performance for all users. These changes are in response to increased API traffic that has been affecting our services.

The limits have been carefully set based on average usage patterns and should provide sufficient capacity for most use cases. If you exceed these limits, you'll receive a "429 Too Many Requests" response.

For complete details about specific rate limits and implementation information, please read the related blog post.

Ultimate

Internal releases available for GitLab Dedicated (self-managed only): GitLab Dedicated

GitLab Dedicated customers with strict security requirements and compliance obligations require the highest level of protection for their development environments.

Today, we're introducing Internal Releases, a new private release that allows us to remediate GitLab Dedicated instances for critical vulnerabilities before public disclosure, ensuring GitLab Dedicated customers are never exposed to them.

This new capability delivers immediate protection for critical vulnerabilities found in GitLab parallel to response for GitLab.com. This new process does not require customer action.

Software supply chain security

New permissions for custom roles: Permissions

You can create custom roles with the Manage protected environments permission. Custom roles allow you to grant only the specific permissions users need to complete their tasks. This helps you define roles that are tailored to the needs of your group, and can reduce the number of users who need the Owner or Maintainer role.

Security risk management

Exclude packages from license approval rules: Security Policy Management

In merge request approval policies, this new enhancement to license approval policies gives legal and compliance teams more control over which packages can use specific licenses. You can now create exceptions for pre-approved packages, even when they use licenses that would normally be blocked by your organization's policies.

Previously, in license approval policies, if you blocked a license like AGPL-3.0, it was blocked for all packages across your organization. This created challenges when:

Your legal team pre-approved specific packages with otherwise restricted licenses.
You needed to use the same package across hundreds of projects.
Different teams required different license exceptions.

With this release, you can maintain strict license governance while allowing necessary exceptions, significantly reducing approval bottlenecks and manual reviews. For example, you can:

Define package-specific exceptions to your license approval rules using Package URL (PURL) format.
Allow specific packages (or package versions) to use otherwise restricted licenses.
Block specific packages (or package versions) from using generally allowed licenses.

To add exceptions, follow this workflow when you create or edit a license approval policy:

In your group, go to Security & Compliance > Policies
Create or edit a license approval policy.
Find the new package exception options in the visual editor or configure them in YAML mode.
Choose between allowlist or denylist mode for the licenses.
Add specific licenses to your policy.
For each license, define package exceptions in PURL format (for example, pkg:npm/@angular/[email protected]).
Specify whether to include or exclude these packages from the license rule.

The policy then enforces your license rules while respecting the defined exceptions, giving you granular control over license compliance across your organization.

Configure Jira issues from vulnerabilities using the Jira integration API

Previously, you had to configure the integration to create Jira issues from vulnerabilities from the Project settings page.

You can now configure this integration from the project integrations API, which allows you to automate the setup.

Improved traceability of redetected vulnerabilities

Previously, when a resolved vulnerability was redetected and changed status, the vulnerability details did not provide information to indicate when and why the status change occurred.

GitLab now adds a system note to the vulnerability history when resolved vulnerabilities change status because they appeared in a new scan. This additional information helps users understand why vulnerabilities have changed status.

Bulk add vulnerabilities to issues from the vulnerability report: Vulnerability Management

With this release you can now bulk add vulnerabilities to new or existing GitLab issues from the vulnerability report. You may now associate multiple issues and vulnerabilities together. Additionally, related vulnerabilities are now listed within the issue page.

Premium

GitLab Premium and Ultimate with Duo: Code Suggestions, Duo Chat

We're excited to announce GitLab Premium with Duo and GitLab Ultimate with Duo. GitLab Premium and Ultimate now include AI-native features.

GitLab's AI-native features include Code Suggestions and Chat within the IDE. Development teams can use these features to:

Analyze, understand, and explain code
Write secure code faster
Quickly generate tests to maintain code quality
Easily refactor code to improve performance or use specific libraries

Repository X-Ray now available on GitLab Duo Self-Hosted (self-managed only): Self-Hosted Models

You can now use Repository X-Ray with Code Suggestions on GitLab Duo Self-Hosted. This feature is in beta for GitLab Duo Self-Hosted, and is generally available on GitLab Self-Managed instances.

List only Enterprise users for contributions reassignment on GitLab.com: Importers

In this release we've improved the placeholder users mapping experience by narrowing down the user selection dropdown to only Enterprise users associated with the top-level group.

Previously, when reassigning users' contributions after an import to GitLab.com, you would see in the dropdown list all active users on the platform, making it difficult to identify the correct user, especially when SCIM provisioning had modified usernames. Now, if your top-level group uses the Enterprise users feature, the dropdown list will display only users claimed by your organization, significantly reducing the potential for errors during user reassignment.

The same scoping is also applied to CSV-based reassignment, preventing accidental assignment to users outside your organization.

Create

Automatic reviews with Duo Code Review: Code Review Workflow

Duo Code Review provides valuable insights during the review process, but currently requires you to manually request reviews on each merge request.

You can now configure GitLab Duo Code Review to run automatically on merge requests by updating your project's merge request settings. When enabled, Duo Code Review automatically reviews merge requests unless:

The merge request is marked as draft.
The merge request contains no changes.

Automatic reviews ensure that all code in your project receives a review, consistently improving code quality across your codebase.

Code Suggestions prompt caching: Code Suggestions

Code Suggestions now includes prompt caching. Prompt caching significantly improves code completion latency by avoiding the re-processing of cached prompt and input data. The cached data is never logged to any persistent storage, and you can optionally disable prompt caching in the GitLab Duo settings.

Improved Duo Code Review context: Code Review Workflow

Duo Code Review now provides more comprehensive context for improved analysis.

The key improvements are:

Includes a merge request's title and description to better understand the purpose of proposed changes.
Examines all diffs simultaneously to recognize cross-file relationships and reduce false positives.
Provides the full content of changed files to understand how modifications fit within existing code patterns.

These enhancements reduce inaccurate suggestions and deliver more relevant and higher quality code reviews.

Create a workspace from merge requests: Workspaces

You can now create a workspace directly from a merge request with the new Open in Workspace option. This feature automatically configures a workspace with the merge request's branch and context, allowing you to:

Review code changes in a fully configured environment.
Run tests on the merge request branch to verify functionality.
Make additional modifications to the merge request without local setup.

Shared Kubernetes namespace for workspaces: Workspaces

You can now create GitLab workspaces in a shared Kubernetes namespace. This removes the need to create a new namespace for every workspace and eliminates the requirement to give elevated ClusterRole permission to the agent. With this feature, you can more easily adopt workspaces in secure or restricted environments, offering a simpler path to scale.

To enable shared namespaces, set the shared_namespace field in your agent configuration file to specify the Kubernetes namespace you want to use for all workspaces.

Thank you to the half dozen community contributors who helped build this feature through GitLab's Co-Create program!

Software supply chain security

Display and filter archived projects in the compliance projects report: Compliance Management

In the compliance projects report, you can view the compliance frameworks applied to projects within a group or subgroup.

However, the report lacked the ability to show whether a project is archived or not, which could be useful information for managing compliance across active and archived projects.

As such, we've added an indicator to show whether a project is archived. This will provide you with better visibility and context when reviewing compliance frameworks across both active and archived projects.

This feature includes:

An archived status badge for each project in the compliance projects report to show whether a project is archived.
A filter that allows you to toggle between archived, non-archived, or all projects.

Disable user invitations: System Access

You can now remove the ability to invite members to groups or projects.

On GitLab.com, this setting is configured by Owners of groups with enterprise users and applies to any sub-groups or projects within the top-level group. No user can send invites while this setting is enabled.

On GitLab Self-Managed, this setting is by administrators and applies to the entire instance. Administrators can still invite users directly.

This feature helps organizations maintain strict control over membership access.

LDAP authentication with GitLab username (self-managed only): System Access

LDAP users can now authenticate requests with their GitLab username. Previously, if the GitLab username didn't match their LDAP username, GitLab returned an authentication error. This change helps users maintain separate naming conventions in GitLab and LDAP systems without disrupting approval workflows.

Support for SHA256 SAML certificates: System Access

GitLab now automatically detects and supports both SHA1 and SHA256 certificate fingerprints for Group SAML authentication. This maintains backward compatibility with existing SHA1 fingerprints while adding support for more secure SHA256 fingerprints. This upgrade is essential to prepare for the upcoming ruby-saml 2.x release that will make SHA256 the default.

Core

Improved pod status visualizations in the dashboard for Kubernetes

You can use the dashboard for Kubernetes to monitor your deployed applications. Until now, pods with container errors like CrashLoopBackOff or ImagePullBackOff were displayed with a "Pending" or "Running" status, which makes it difficult to identify problematic deployments without using kubectl.

In GitLab 18.0, error states in the UI show a specific container's status, similar to the kubectl output. Now, you can quickly identify and troubleshoot failing pods without leaving the GitLab interface.

Support for multiple workspaces in the GitLab for Slack app (self-managed only): Integrations

The GitLab for Slack app now supports multiple workspaces for GitLab Self-Managed and GitLab Dedicated customers. Enabling multiple workspaces allows organizations with federated Slack environments to maintain seamless GitLab integrations across all their workspaces. To enable support for multiple workspaces, configure the GitLab for Slack app as an unlisted distributed app.

Delete groups and placeholder users: Importers

In GitLab 18.0, when you delete a top-level group, placeholder users associated with the group are deleted as well. If placeholder users are associated with other projects, they are only removed from the top-level group.

This way, unnecessary placeholder users are removed without disrupting the history or attributions of other projects.

GitLab chart 9.0 released with breaking changes (self-managed only): Cloud Native Installation, Omnibus Package

Breaking change: Support for PostgreSQL 14 and 15 has been removed. Make sure you are running PostgreSQL 16 before upgrading.

Breaking change: The bundled Prometheus chart was updated from 15.3 to 27.11. Along with the Prometheus chart upgrade, the Prometheus version was updated from 2.38 to 3.0. Manual steps are required to perform the upgrade. If you have Alertmanager, Node Exporter, or Pushgateway enabled, you must also update your Helm values. For more information, see the migration guide.

Breaking change: The default NGINX controller image was updated from version 1.3.1 to 1.11.2. If you're using the GitLab NGINX chart, and you have set your own NGINX RBAC rules, new RBAC rules must exist. For more information, see the upgrade guide for more information.

Deletion protection available for all users: Groups & Projects

Project and group delayed deletion is now available for all GitLab users, including those on our Free tier. This essential safety feature adds a grace period (7 days on GitLab.com) before deleted groups and projects are permanently removed. This feature allows recovery from accidental deletions without complex recovery operations.

By making data safety a core feature, GitLab can help better protect your work against data loss events.

Delayed project deletion for user namespaces: Groups & Projects

Delayed project deletion is now available for projects in user namespaces (personal projects). Previously, this safeguard against accidental data loss was only available for group namespaces. When you delete a project in your user namespace, it will now enter a "pending deletion" state for the duration configured in your instance settings (7 days on GitLab.com), rather than being immediately deleted. This creates a recovery window during which you can restore the project if needed.

We hope this enhancement provides greater peace of mind when managing your personal projects in GitLab.

New active parameter for Groups and Projects REST APIs: Groups & Projects

We've added a new active parameter to our Groups and Projects REST APIs that simplifies filtering groups based on their status. When set to true, only non-archived groups or projects not marked for deletion are returned. When set to false, only archived groups or projects marked for deletion are returned. If the parameter is undefined, no filtering is applied. This enhancement helps you efficiently manage your workflows by targeting specific statuses through simple API calls.

Thank you @dagaranupam for adding this parameter to the Projects API.

Plan

GitLab Query Language views enhancements: Wiki, Team Planning

We've made significant improvements to GitLab Query Language (GLQL) views. These improvements include support for:

The >= and <= operators for all date types
The View actions dropdown in views
The Reload action
Field aliases
Aliasing columns to a custom name in GLQL tables

We welcome your feedback on this enhancement, and on GLQL views in general, in issue 509791.

Pages template improvements: Pages

GitLab provides templates for popular static site generators. We've taken a deep dive into available templates using a scoring framework, and refined the list to include only the most popular templates.

Refining templates available for GitLab Pages streamlines the website creation process. Use templates to launch professional-looking sites with minimal technical expertise. Enhanced templates also provide modern, responsive designs, eliminating the need for custom development work.

Create

View open merge requests targeting files: Source Code Management

Previously, when working on code files, you had no visibility into who else might be modifying the same file in other branches. This lack of awareness led to merge conflicts, duplicated work, and inefficient collaboration.

Now you can easily identify all open merge requests that modify the file you're viewing in the repository. This feature helps you:

Identify potential merge conflicts before they happen.
Avoid duplicating work that's already in progress.
Improve collaboration by providing visibility into in-flight changes.

A badge displays the number of open merge requests modifying the file, and hovering over it reveals a popover with the list of these merge requests.

Verify

New CI/CD analytics view for projects in limited availability: Fleet Visibility

The redesigned CI/CD analytics view transforms how your development teams analyze, monitor, and optimize pipeline performance and reliability. Developers can access intuitive visualizations in the GitLab UI that reveal performance trends and reliability metrics. Embedding these insights in your project repository eliminates context-switching that disrupts developer flow. Teams can identify and address pipeline bottlenecks that drain productivity.

This enhancement leads to faster development cycles, improved collaboration, and data-driven confidence to optimize your CI/CD workflows in GitLab.

GitLab Runner 18.0: GitLab Runner Core

We’re also releasing GitLab Runner 18.0 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:

Add ConfigurationError and ExitCodeInvalidConfiguration to the GitLab Runner build error classifications
Improve cloud provider error messages for failed cache uploads to cloud storage

Bug Fixes:

GitLab Runner can use cached images even when disallowed

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

Application security testing

Security scanners now support MR pipelines: API Security, Container Scanning, DAST, Fuzz Testing, SAST, Secret Detection, Software Composition Analysis

You can now choose to run Application Security Testing (AST) scanners in merge request (MR) pipelines.

To minimize the impact to your pipelines, this is as an opt-in behavior you can control.

Previously, the default behavior depended on whether you used the Stable or Latest CI/CD template edition to enable a scanner:

In Stable templates, scan jobs ran in branch pipelines only. MR pipelines weren't supported.
In Latest templates, scan jobs ran in MR pipelines when an MR was open, and ran in branch pipelines if there was no associated MR. You couldn't control this behavior.

Now, a new option, AST_ENABLE_MR_PIPELINES, allows you to control whether to run jobs in MR pipelines.

The default behavior for both Stable and Latest templates remains the same. Specifically:

Stable templates continue to run scan jobs in branch pipelines by default, but you can set AST_ENABLE_MR_PIPELINES: "true" to use MR pipelines instead when an MR is open.
Latest templates continue to run scan jobs in MR pipelines by default when an MR is open, but you can set AST_ENABLE_MR_PIPELINES: "false" to use branch pipelines instead.

This improvement affects all security scanning templates except for API Discovery (API-Discovery.gitlab-ci.yml), which currently defaults to MR pipelines.

We also changed the API Discovery template to align with other Stable templates in GitLab 18.0 and use branch pipeline by default.

Software supply chain security

Limit maximum user session length (self-managed only): System Access

Administrators can now choose if the maximum length of a user session is computed from the initial sign-in or from the last activity. Users are notified that the session is ending, but cannot prevent the session from expiring or extend the session. This feature is disabled by default.

Thank you John Parent for your contribution!

Granular permissions for job tokens in beta: Permissions

Pipeline security just got more flexible. Job tokens are ephemeral credentials that provide access to resources in pipelines. Until now, these tokens inherited full permissions from the user, often resulting in unnecessarily broad access capabilities.

With our new fine-grained permissions for job tokens beta feature, you can now precisely control which specific resources a job token can access within a project. This allows you to implement the principle of least privilege in your CI/CD workflows, granting only the minimal access necessary for each job to complete its tasks.

We're actively seeking community feedback on this feature. If you have questions, want to share your implementation experience, or would like to engage directly with our team about potential improvements, please visit our feedback issue.

Monitor

Event data collection (self-managed only): Application Instrumentation

In GitLab 18.0, we are enabling event-level product usage data collection from GitLab Self-Managed and GitLab Dedicated instances. Unlike aggregated data, event-level data provides GitLab with deeper insights into usage, allowing us to improve user experience on the platform and increase feature adoption. For detailed instructions on how to adjust data sharing settings, please refer to our documentation.

Original source

Configure SAML single sign-on with multiple identity providers in Switchboard (self-managed only): GitLab Dedicated, Switchboard

You can now configure SAML single sign-on (SSO) for your GitLab Dedicated instance for up to ten identity providers (IdPs).

All SAML configuration options available for GitLab Dedicated instances can be configured for each individual IdP.

If you had previously configured multiple IdPs, you can now view and edit all existing SAML configurations directly in Switchboard.

Ultimate

Open files as context now available on GitLab Duo Self-Hosted Code Suggestions (self-managed only): Self-Hosted Models

On Gitlab Duo Self-Hosted, you can now use files open in tabs in your IDE as context when using Code Suggestions.

Select individual models for AI-powered features on GitLab Duo Self-Hosted (self-managed only): Self-Hosted Models

On GitLab Duo Self-Hosted, you can now select and configure individual supported models for each GitLab Duo feature and sub-feature on your GitLab Self-Managed instance.

To leave feedback, go to issue 524175.

Llama 3 models generally available for GitLab Duo Chat and Code Suggestions (self-managed only): Self-Hosted Models

Llama 3 models are now generally available with Gitlab Duo Self-Hosted to support GitLab Duo Chat and Code Suggestions.

To leave feedback on using these models with GitLab Duo Self-Hosted, see issue 523918.

More GitLab Duo features now available on GitLab Duo Self-Hosted (self-managed only): Self-Hosted Models

You can now use more GitLab Duo features with GitLab Duo Self-Hosted in your GitLab Self-Managed instance. The following features are available in beta:

• Root Cause Analysis
• Vulnerability Explanation
• Vulnerability Resolution
• AI Impact Dashboard
• Discussion Summary
• Merge Request Commit Message
• Merge Request Summary
• GitLab Duo for the CLI

Code Review Summary is also available on GitLab Duo Self-Hosted as an experiment.

GitLab Duo with Amazon Q is generally available (self-managed only): Code Suggestions

We're excited to announce general availability for GitLab Duo with Amazon Q, a joint offering that brings together the comprehensive GitLab AI-powered DevSecOps platform with autonomous Amazon Q AI agents in a single, integrated solution. GitLab Duo with Amazon Q integrates AI agents directly into development workflows, allowing developers to accelerate key tasks without switching tools. Acting as intelligent assistants within the GitLab DevSecOps platform, these agents automate time-consuming processes like code generation, testing, reviews, and Java modernization, helping teams focus on innovation while maintaining security and quality standards.

GitLab Duo with Amazon Q provides major benefits for development teams:

• Streamline feature development from idea to code: use /q dev, which will convert an issue description directly into merge-ready code in minutes.
• Modernize legacy code without the headache: use /q transform to automate the entire Java modernization process.
• Accelerate code reviews without sacrificing quality: use /q review to get instant, intelligent feedback on code quality and security directly in merge requests.
• Automate testing to ship with confidence: use /q test to generate comprehensive unit tests that understand your application logic.

Application security testing

Increased rule coverage for secret push protection and pipeline secret detection: Secret Detection

GitLab secret detection has received significant updates, including 17 new secret push protection rules and 12 new pipeline secret detection rules. Some existing rules have also been updated to improve quality and reduce false positives. For details, see v0.9.0 in the change log.

Static reachability beta with Python support: Software Composition Analysis

The Composition Analysis team has released beta support for static reachability for Python. This beta release focuses on enhancing stability, observability, and provides a better user experience via easier configuration.

Static reachability enriches software composition analysis (SCA) results. Powered by GitLab Advanced SAST, static reachability scans project source code to identify which open source dependencies are in use.

You can use the data produced by static reachability as part of your triage and remediation decision making. Static reachability data can also be used with CVSS and EPSS scores, as well as KEV indicators to provide a more focused view of your vulnerabilities.

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

Dynamic analysis support for reflected XSS checks: DAST

The Dynamic Analysis team has introduced a check for CWE-79. This work allows our DAST scanner to check for reflected XSS attacks.

Checking for Reflective XSS is on by default. To turn off this check, in you configuration, set DAST_FF_XSS_ATTACK: false.

If you have questions or feedback, see issue 525861.

Software supply chain security

Customize compliance frameworks with requirements and compliance controls: Compliance Management

Previously, compliance frameworks in GitLab could be created as a label to identify that your project has certain compliance requirements or needs additional oversight. This label could then be used as a scoping mechanism to ensure that security policies could be enforced on all projects within a group.

In this release, we are introducing a new way for compliance managers to get more in-depth compliance monitoring in GitLab through 'requirements'.

With requirements, as part of a custom compliance framework, you can define specific requirements from a number of different compliance standards, laws, and regulations that must be followed as an organization.

We are also expanding the number of compliance controls (previously known as compliance checks) that we offer from five to over 50! These 50 out-of-the-box (OOTB) controls can be mapped to the compliance framework requirements.

These controls check particular project, security, and merge request settings across your GitLab instance to help you meet requirements under a number of different compliance standards, laws, and regulations such as SOC2, NIST, ISO 27001, and the GitLab CIS Benchmark.

Adherence to these controls is reflected in standard adherence report, which is redesigned to take into account requirements and the mapping of controls to those requirements.

In addition to expanding our OOTB controls, we now allow users to map requirements to external controls, which can be for items, programs, or systems that exist outside the GitLab platform. These mappings allow you to use the GitLab compliance centre as the single source of truth when it comes to your compliance monitoring and audit evidence needs.

Security risk management

CycloneDX export for the project dependency list: Dependency Management

Many organizations now require a software bill of materials (SBOM) to meet regulatory requirements and help further increase the security of the software supply chain. Previously, you could only export your dependency list as a JSON or CSV file from GitLab. Now, GitLab can generate your SBOM by exporting your dependency list in the widely-adopted CycloneDX format.

To download an SBOM directly as a CycloneDX file, in the dependency list, select Export > Export as CycloneDX (JSON).

Email delivery for dependency list and vulnerability report export: Dependency Management

Previously, when exporting the dependency list or the vulnerability report, you had to remain on the page until the export completed before you could download the report.

Now, you are notified by email with a download link when the dependency list or vulnerability report export is complete.

Export dependency list in CSV format: Dependency Management

Previously, you could not export a dependency list from GitLab as CSV file. Now, when you download a dependency list, you can select the new CSV option to export the list in this format.

Tool filter replaced with Scanner and Report Type filters: Vulnerability Management

Previously, the tool search filter in the vulnerability report allowed you to filter results based on a single group of tools that included the type of scanner (like ESLint or Gemnasium) and the type of report (like SAST or container scanning).

To help you find the appropriate tools more easily, we've replaced the tool filter with the scanner filter and the report type filter. You can now filter your search based on each of these types of tools separately.

Premium

GitLab Duo Chat now uses Anthropic Claude Sonnet 3.7: Duo Chat

GitLab Duo Chat now uses Anthropic Claude Sonnet 3.7 as the base model, replacing Claude 3.5 Sonnet for answering most questions.

Claude 3.7 Sonnet has strongly improved coding and reasoning capabilities, making it even better at explaining code, generating code, processing text data, and answering complex DevSecOps questions. You'll notice more detailed and accurate Chat responses in these areas.

This upgrade applies to all Chat features, and ensures a consistent and improved experience across the entire Chat interface.

Manage multiple conversations in GitLab Duo Chat: Duo Chat

Multiple conversations with GitLab Duo Chat is now available in GitLab Self-Managed instances in the web UI. You can create new conversations, browse your conversation history, and switch between conversations without losing context.

For your privacy, conversations with no activity for 30 days are automatically deleted, and you can manually delete any conversation at any time. On GitLab Self-Managed, administrators can reduce how long conversations are retained for.

Share your experience with us in issue 526013.

SAML verification for contribution reassignment when importing to GitLab.com: Importers

In this milestone, we've added SAML verification checks to contribution reassignment when importing to GitLab.com. These checks prevent reassignment errors in groups where SAML SSO is enabled.

If you import to GitLab.com and use SAML SSO for GitLab.com groups, all users must link their SAML identity to their GitLab.com account before you can reassign contributions and memberships.

When you reassign contributions to users who have not verified their SAML identity, you'll receive error messages. These messages explain the steps to take to help ensure your group memberships are attributed correctly.

Geo - New replicables view (self-managed only): Disaster Recovery, Geo-replication

We are introducing a new look and feel for the replicables view in Geo. The new experience better aligns with the rest of GitLab and provides a more streamlined and less cluttered interface to review the synchronization and verification status of Geo secondary sites. In addition, there is now a click-through detailed view for each replicable item, providing information such as the primary and secondary checksums, error details, and much more. This information will make troubleshooting Geo synchronization issues much easier.

Plan

Set work in progress limits by weight: Team Planning

You can now set work in progress limits by weight in addition to issue count, giving you more flexibility in managing your team's workload.

Control the flow of work based on the complexity or effort of each task, rather than just the number of issues. Teams that use issue weights to represent effort can now ensure they don't overcommit by limiting the total weight of issues in a given board list.

Use this feature to optimize your team's productivity and create a more balanced workflow that accounts for varying task complexity.

Epic, issue, and task custom fields: Team Planning

With this release, you can configure text, number, single-select, and multi-select custom fields for issues, epics, tasks, objectives, and key results. While labels have been the primary way to categorize work items up to this point, custom fields provide a more user-friendly approach for adding structured metadata to your planning artifacts.

Custom fields are configured in your top-level group and cascade to all subgroups and projects.

You can map fields to one or more work item types and filter by custom field values in the issues and epics lists.

Create

Use imported files as context in Code Suggestions: Code Suggestions

GitLab Duo Code Suggestions can now use imported files in your IDE to enrich and improve the quality of suggestions. Imported files provide additional context about your project. Imported file context is supported for JavaScript and TypeScript files.

GitLab Eclipse plugin available in beta: Editor Extensions

We're thrilled to announce the beta release of the GitLab Eclipse plugin, now available in the Eclipse Marketplace. This powerful new plugin extends GitLab's Duo features directly into your Eclipse IDE, giving you seamless access to Duo Chat and AI-powered code suggestions.

As the plugin is currently in beta, we're actively improving features, including expanding authentication options, and refining the final user experience. Your feedback is invaluable. Please share your thoughts to help us make the GitLab Eclipse plugin even better by adding your feedback in issue 162.

Software supply chain security

Assign projects when creating compliance frameworks: Compliance Management

In the past, you couldn't assign new compliance frameworks to projects without navigating to the Projects tab in the compliance center after creating the compliance framework. This situation created unnecessary friction to creating new compliance frameworks in your groups.

In GitLab 17.11, when creating a compliance framework, we introduced a new step that provides the option of assigning multiple projects to the compliance framework before it is created.

This new feature:

• Helps keep you in the compliance framework creation workflow.
• Provides guidance for you to understand that compliance frameworks work together with projects in a group to monitor and enforce compliance adherence for the entire group.

Token statistics for service account management: System Access

The token management interface for service accounts now includes a helpful statistics dashboard that provides at-a-glance information about your token inventory. This information can help you assess the state of your tokens and identify tokens that require attention.

The statistics dashboard includes four key metrics:

• Active tokens: View the total number of active tokens
• Expiring tokens: Identify tokens that expire in the next two weeks
• Revoked tokens: Track tokens that were manually revoked
• Expired tokens: Monitor tokens that have previously expired

Thank you Chaitanya Sonwane for your contribution!

Service accounts UI: System Access

You now can use a dedicated space to create and manage service accounts in the GitLab UI. This interface allows you to create, monitor, and control automated access to your GitLab resources. Previously, this functionality was only available in the API.

Automated Duo Pro and Duo Enterprise seat assignment: System Access

You can now automatically assign a Duo Pro or Duo Enterprise seat to users with SAML Group Sync. As long as the GitLab group has available Duo Pro or Duo Enterprise seats, any user mapped from the identity provider is automatically assigned a seat. This reduces the effort to manage seat assignments.

Core

Kubernetes 1.32 support: Deployment Management

This release adds full support for Kubernetes version 1.32, released in December 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.

You can read more about our Kubernetes support policy and other supported Kubernetes versions.

All auto-disabled webhooks now automatically re-enable: Webhooks

With this release, webhooks that return 4xx errors are now automatically re-enabled. All errors (4xx, 5xx, or server errors) are treated the same way, allowing for more predictable behavior and easier troubleshooting. This change was announced in this blog post.

Failing webhooks are temporarily disabled for one minute, extending to a maximum of 24 hours. After a webhook fails 40 consecutive times, it now becomes permanently disabled.

Webhooks that were permanently disabled in GitLab 17.10 and earlier underwent a data migration.

For GitLab.com, these changes apply automatically.

For GitLab Self-Managed and GitLab Dedicated, these changes affect only those instances where the auto_disabling_webhooks ops flag is enabled.

Thanks to Phawin for this community contribution!

Ghost user contributions auto-mapped during imports: Importers

Previously, ghost user contributions would create placeholder references that required manual reassignment, creating extra work during migrations.

Now, importers using new contributions and membership mapping functionality, migration by direct transfer, GitHub, Bitbucket Server and Gitea importers, handle ghost user contributions more intelligently.

When importing content to GitLab, contributions previously made by the ghost user on the source instance are now automatically mapped to the ghost user on the destination instance.

This enhancement eliminates the creation of unnecessary placeholder users for ghost user contributions, reducing clutter in user mapping interface and simplifying the migration process.

Filter placeholder users in Admin area: Importers

Previously, placeholder users created during imports appeared mixed with regular users without clear distinction in the Admin area Users page.

With this release, administrators can now filter for placeholder accounts from the search box in the Users page in the Admin area. To do this, select Type in the dropdown list, then choose Placeholder.

Placeholder user limits appear in group usage quotas: Importers

For imports to GitLab.com, placeholder users are limited per top-level group. These limits depend on your GitLab license and number of seats. With this release, it's possible to check your placeholder user usage and limits for a top-level group in the UI.

To view your current usage and limits:

• On the left sidebar, select Search or go to and find your group. This group must be at the top level.
• Select Settings > Usage Quotas.
• Select the Import tab.

Linux package improvements (self-managed only): Omnibus Package

In GitLab 18.0, the minimum-supported version of PostgreSQL will be version 16. To prepare for this change, on instances that don't use PostgreSQL Cluster, upgrades to GitLab 17.11 will attempt to automatically upgrade PostgreSQL to version 16.

If you use PostgreSQL Cluster or opt out of this automated upgrade, you must manually upgrade to PostgreSQL 16 to be able to upgrade to GitLab 18.0.

Plan

Improved wiki sidebar styling: Wiki

The custom wiki sidebar now features improved styling with reduced heading sizes and better left-padding for lists. These ergonomic enhancements improve the readability of custom navigation created through the _sidebar wiki page.

Custom sidebars help teams organize their wiki content in a way that makes sense for their unique knowledge base structure. With this styling update, the sidebar is now easier to scan, creating a clearer visual hierarchy that helps team members find relevant information more quickly.

Display last comment as a column in GLQL views: Wiki, Team Planning

GLQL views now support displaying the last comment on an issue or merge request as a column. By including lastComment as a field in your GLQL query, you can see the most recent updates without leaving your current context.

Previously, you had to open each issue or merge request individually to view the last comment, which was time consuming and made it difficult to get a quick overview of progress. This improvement helps teams maintain momentum by providing at-a-glance visibility into ongoing conversations and status updates.

We welcome your feedback on this enhancement and GLQL views in general on our feedback issue.

Nuxt project template for GitLab Pages: Pages

GitLab provides templates for the most popular Static Site Generators (SSGs), and you can now create a GitLab Pages site using Nuxt, a powerful framework built on Vue.js. Nuxt is particularly valuable for teams looking to build modern, performant web applications with less configuration overhead.

This addition expands your options for quickly launching a Pages site with built-in CI/CD pipelines and a modern development experience, without spending time on initial setup and configuration.

New issue look now generally available: Team Planning

As of this release, the new issue look is generally available and replaces the legacy issue experience. Issues now share a common framework with epics and tasks, featuring real-time updates and workflow improvements:

• Drawer view: You can open items from lists or boards in a drawer for quick viewing without leaving your current context. A button at the top lets you expand to a full-page view.
• Change type: Convert types between epics, issues, and tasks using the “Change type” action (replaces “Promote to epic”)
• Start date: Issues now support start dates, aligning their functionality with epics and tasks.
• Ancestry: The complete hierarchy is above the title and the Parent field in the sidebar. To manage relationships, use the new quick action commands /set_parent, /remove_parent, /add_child, and /remove_child.
• Controls: All actions are now accessible from the top menu (vertical ellipsis), which remains visible in the sticky header when scrolling.
• Development: All development items (merge requests, branches, and feature flags) related to an issue or task are now consolidated in a single, convenient list.
• Layout: UI improvements create a more seamless experience between issues, epics, tasks, and merge requests, helping you navigate your workflow more efficiently.
• Linked items: Create relationships between tasks, issues, and epics with improved linking options. Drag and drop to change link types and toggle the visibility of labels and closed items.

Create

Extension marketplace for Web IDE on self-managed instances: Web IDE

We're thrilled to announce the launch of the extension marketplace in the Web IDE for self-managed users. With the extension marketplace, you can discover, install, and manage third-party extensions to enhance your development experience.

By default, the GitLab instance is configured to use the Open VSX extension registry. To activate this, follow the enable with default extension registry steps.

If you want to use your own or custom registry, you also have the option to connect a custom extension registry. This provides you with more flexibility to manage available extensions.

After enabling the extension marketplace, individual users must still opt in to use it. They can do this by going to the Integrations section in their Preferences settings.

It's important to note that some extensions require a local runtime environment and are not compatible with the web-only version. Despite this, you can still choose from thousands of available extensions to boost your productivity and customize your workflow.

Verify

Improved pipeline graph visualization for failed jobs: Pipeline Composition

You can now quickly identify failed jobs in the pipeline graph with new visual indicators. Failed job groups are highlighted in the pipeline graph, and failed jobs are grouped at the top of each stage. This improved visualization helps you troubleshoot pipeline failures without having to search through complex pipeline structures.

Force-cancel CI/CD jobs stuck in canceling state: Continuous Integration (CI)

CI/CD jobs can occasionally get stuck in the 'canceling' state, blocking deployments or access to shared resources.

Users with the Maintainer role can now force-cancel these stuck jobs directly from the job logs page, ensuring problematic jobs can be properly terminated.

Improved runner management in projects: Fleet Visibility

You can now manage runners more efficiently in your projects. Runners are displayed in a single-column layout and organized in their own lists instead of the previous two-column view.

This improved organization makes it simpler to find and manage runners, with new features including a list of assigned projects, runner managers, and jobs that a runner has run. For information about additional runner management improvements planned for GitLab 18.0, see issue 33803.

GitLab Runner 17.11: GitLab Runner Core

We’re also releasing GitLab Runner 17.11 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:

• Code sign GitLab Runner Windows executables

Bug Fixes:

• Cleaning Git configuration in GitLab Runner 17.10.0 results in an error
• The FF_DISABLE_UMASK_FOR_KUBERNETES_EXECUTOR flag doesn't disable the umask command

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

CI/CD pipeline inputs: Pipeline Composition

CI/CD variables are essential for dynamic CI/CD workflows, and are used for many things, including as environment variables, context variables, tool configuration, and matrix variables. But developers sometimes rely on CI/CD variables to inject pipeline variables into pipelines to manually modify pipeline behavior, which have some risks due to the higher precedence of pipeline variables.

In GitLab 17.11 and later, you can now use inputs to safely modify pipeline behavior instead of using pipeline variables, including in scheduled pipelines, downstream pipelines, triggered pipelines, and other cases. Inputs provide developers with a more structured and flexible solution for injecting dynamic content at CI/CD job runtime. After you switch to inputs, you can completely disable access to pipeline variables.

We'd greatly appreciate it if you could try it out and share your feedback through this dedicated issue.

Package

Docker Hub authentication UI for the dependency proxy: Container Registry

We're excited to announce UI support for Docker Hub authentication in the GitLab Dependency Proxy. This feature was initially introduced in GitLab 17.10 with GraphQL API support only, and now includes a user interface for easier configuration.

With this enhancement, you can now configure Docker Hub authentication directly from your group settings page, helping you:

• Avoid pipeline failures due to rate limits.
• Access private Docker Hub images.
• Store your Docker Hub credentials, personal access token, or organization access tokens securely.

This streamlined approach makes it easier to maintain uninterrupted access to Docker Hub images in your CI/CD pipelines without using the GraphQL API.

Enhance security with protected container tags: Container Registry

Container registries are critical infrastructure for modern DevSecOps teams. Until now, GitLab users with the Developer role or higher could push and delete any container tag in their projects, creating risks of accidental or unauthorized changes to production-critical container images.

With protected container tags, you now have fine-grained control over who can push or delete specific container tags. You can:

• Create up to five protection rules per project.
• Use RE2 regex patterns to protect tags like latest, semantic versions (for example, v1.0.0), or stable release tags (for example, main-stable).
• Restrict push and delete operations to Maintainer, Owner, or Administrator roles.
• Prevent protected tags from being removed by cleanup policies.

This feature requires the next-generation container registry, which is already enabled by default on GitLab.com. For GitLab Self-Managed instance, you'll need to enable the metadata database to use protected container tags.

Safeguard your registry with protected Maven packages: Package Registry

We're thrilled to introduce support for protected Maven packages to enhance the security and stability of your GitLab package registry. Accidental modification of packages can disrupt the entire development process. With protected packages, you can safeguard your most important dependencies against unintended changes.

In GitLab 17.11, you can now protect Maven packages by creating protection rules. If a package matches a protection rule, only specified users can push new versions of the package. Package protection rules prevent accidental overwrites, improve compliance with regulatory requirements, and reduce the need for manual oversight.

Protected packages support for Maven and other package formats are all community contributions from gerardo-navarro and the Siemens crew. Thank you, Gerardo, and the rest of the crew from Siemens for their many contributions to GitLab! If you want to learn more about how Gerardo and the Siemens crew contributed this change, check out this video in which Gerardo shares his learnings and best practices for contributing to GitLab based on his experience as an external contributor.

Software supply chain security

Enhanced sorting options for access tokens: System Access

There are now additional sorting options for access tokens in the UI and API. These sorting options complement GitLab's existing token management capabilities, giving you more control over your access token inventory, and helping you better maintain access token security. The new sorting options include:

• Sort by expiration date (ascending): View the tokens that expire soonest.
• Sort by expiration date (descending): View the tokens with the longest remaining lifetime.
• Sort by last used date (ascending): View the tokens that have not been used recently.
• Sort by last used date (descending): View the tokens used most recently.

Security risk management

Store and filter a source value for CI/CD jobs: Security Policy Management

GitLab 17.11 introduces a new feature that allows users to verify the origin of build artifacts by tracking the source attribute of CI/CD jobs. This enhancement is particularly valuable for security and compliance workflows. For example, organizations can implement software supply chain security measures or require verifiable evidence of security scans for compliance purposes.

Jobs in GitLab now store and display a source value that identifies whether they originated from:

• A scan execution policy
• A pipeline execution policy
• A regular pipeline

You can access the source attribute on the Build > Jobs page with a new filter option, using the Jobs API, or through the ID token claims for artifact verification.

With this new feature, you can now:

• Verify the authenticity of security scan results.
• Filter jobs by source type to quickly identify policy-enforced scans.
• Implement cryptographic verification of artifacts using the new ID token claims.
• Ensure compliance requirements are met with proper audit trails.

Security and compliance teams can leverage this feature to:

• View only policy-enforced jobs using the new filter on the Jobs page.
• Automate tasks by accessing the source field in the Jobs API.
• Implement artifact verification using the new ID token claims:
  • job_source: Identifies the job's origin.
  • job_policy_ref_uri: Points to the policy file (for policy-defined jobs).
  • job_policy_ref_sha: Contains the git commit SHA of the policy.

Monitor

Pre-deployment opt-out toggle to disable event data sharing: Application Instrumentation

In GitLab 18.0, we plan to enable event-level product usage data collection from GitLab Self-Managed and GitLab Dedicated instances. Unlike aggregated data, event-level data provides GitLab with deeper insights into usage, allowing us to improve user experience on the platform and increase feature adoption.

Starting in GitLab 17.11, you will have the ability to opt out of event data collection before it starts, effectively allowing you to choose participation in advance. For more information and details about how to opt-out please see our documentation.

Original source

Manage multiple conversations in GitLab Duo Chat (SaaS only): Duo Chat

Maintaining context across different topics in GitLab Duo Chat is now easier with multiple conversations. You can create new conversations, browse your conversation history, and switch between conversations.

Previously, starting a new conversation meant losing the context of your existing chat. Now, you can manage multiple conversations on different topics. Each conversation maintains its own context, so for example, you can ask follow-up questions about code explanations in one conversation, whilst preparing a work-plan in another conversation.

When you need to revisit previous discussions, select the new chat history icon to see all your recent conversations. Conversations are automatically organized by most recent activity, making it easy to pick up where you left off.

For your privacy, conversations with no activity for 30 days are automatically deleted, and you can manually delete any conversation at any time.

This feature is currently available only on GitLab.com in the web UI. It is not available in GitLab Self-Managed instances, nor in IDE integrations.

Share your experience with us in issue 526013.

Expanded AWS Regions available for GitLab Dedicated failover instances (self-managed only): GitLab Dedicated, Switchboard

GitLab Dedicated customers can now select from an expanded list of AWS regions when choosing where to host their failover instance for disaster recovery.

Expanding failover support to additional regions enables GitLab Dedicated customers to fully use the disaster recovery functionality of GitLab Dedicated regardless of which AWS region they need to use to satisfy their data residency needs.

These newly available regions are only available for hosting failover instances as they do not fully support certain AWS features that GitLab Dedicated relies on.

Ultimate

Select models for AI-powered features on GitLab Duo Self-Hosted (self-managed only): Self-Hosted Models

On GitLab Duo Self-Hosted, you can now select individual supported models for each GitLab Duo Chat sub-feature on your self-managed instance. Model selection and configuration for Chat sub-features is now in beta.

To leave feedback, go to issue 524175.

AI Impact Dashboard available on GitLab Duo Self-Hosted Code Suggestions (self-managed only): Self-Hosted Models, Value Stream Management, DORA Metrics

You can now use the AI Impact Dashboard with GitLab Duo Self-Hosted Code Suggestions on your self-managed instance to help you understand the impact of GitLab Duo on your productivity. The AI Impact Dashboard is in beta with GitLab Duo Self-Hosted, and you can use this feature with your self-managed instance and Visual Studio Code, Microsoft Visual Studio, JetBrains, and Neovim IDEs.

Use the AI Impact Dashboard to compare AI usage trends with metrics like lead time, cycle time, DORA, and vulnerabilities. This allows you to measure how much time is saved in your end-to-end workstream using GitLab Duo Self-Hosted, whilst staying focused on business outcomes rather than developer activity.

Please leave feedback on the AI Impact Dashboard in issue 456105.

Meta Llama 3 models available for GitLab Duo Self-Hosted Code Suggestions and Chat (self-managed only): Self-Hosted Models

You can now use select Meta Llama 3 models with GitLab Duo Self-Hosted. These models are in beta for GitLab Duo Self-Hosted to support GitLab Duo Chat and Code Suggestions.

Please leave feedback on using these models with GitLab Duo Self-Hosted in issue 523912.

Root Cause Analysis available on Gitlab Duo Self-Hosted (self-managed only): Self-Hosted Models

You can now use GitLab Duo Root Cause Analysis on GitLab Duo Self-Hosted. This feature is in beta for GitLab Self-Managed instances using GitLab Duo Self-Hosted, with support for Mistral, Anthropic, and OpenAI GPT model families.

With Root Cause Analysis on GitLab Duo Self-Hosted, you can troubleshoot failed jobs in CI/CD pipelines faster without compromising data sovereignty. Root Cause Analysis analyzes the failed job log, quickly determines the root cause of the job failure, and suggests a fix for you.

Note: This feature currently has limited functionality, and full functionality is planned for 17.11.

Additional information is available in troubleshooting documentation and in issue 527128.

Please leave feedback on Root Cause Analysis for GitLab Duo Self-Hosted in issue 523912.

Plan

New insights into GitLab Duo Code Suggestions and GitLab Duo Chat trends: Value Stream Management

The AI comparison metrics panel on the AI Impact Dashboard now provides month-over-month (MoM) tracking for GitLab Duo Code Suggestions acceptance rate and GitLab Duo Chat usage (MoM%). These new trend-based insights complement the existing Duo Code Suggestions and Duo Chat tiles, which provide a 30-day snapshot of these metrics.

With these additional metrics, managers can better measure the AI impact on their software development processes and identify patterns, by comparing Code Suggestions acceptance rate and Duo Chat usage with other SDLC metrics over time.

New visualization of DevOps performance with DORA metrics across projects: Value Stream Management, DORA Metrics

We are excited to introduce the Projects by DORA metric panel, a new addition to the Value Streams Dashboard. This table lists all projects in the top-level group, with breakdown into the four DORA metrics. Managers can use this table to identify high, medium, and low-performing projects. This information can also help make data-driven decisions, allocate resources effectively, and focus on initiatives that enhance software delivery speed, stability, and reliability.

The DORA metrics are available out-of-the-box in GitLab, and now together with the DORA Performers score panel executives have a complete view into their organization's DevOps health top to bottom.

Create

Duo Code Review available in beta: Code Review Workflow

Code review is an essential activity of software development. It ensures that contributions to a project maintain and improve code quality and security, and is an avenue of mentorship and feedback for engineers. It's also one of the most time-consuming activities in the software development process.

Duo Code Review is the next evolution of the code review process.

Duo Code Review can accelerate your development process. When it performs an initial review on your merge request, it can help identify potential bugs and suggest further improvements - some of which you can apply directly from your browser. Use it to iterate on and improve your changes before you add another human to the loop.

Try it out:
To start a code review immediately, add @GitLabDuo as a reviewer to your merge request.
To refine feedback on your changes, mention @GitLabDuo in a comment.

You can track future progress for Duo Code Review in epic 13008 and related child epics. Feedback can be provided in issue 517386.

Application security testing

Dependency Scanning support for pub (Dart) package manager: Software Composition Analysis

Dependency Scanning has added support for pub, the official package manager for Dart. Support for this has been added to our Dependency Scanning latest template and CI/CD component.

This addition was a community contribution from one of our users, Alexandre Laroche. The GitLab Composition Analysis team appreciates this contribution to improve our product, many thanks, Alexandre. If you are interested in learning more about contributing to GitLab please check out our Community Contribution program.

Software supply chain security

Sort access tokens in Credentials Inventory: System Access

You can now sort personal, project, and group access tokens in the Credentials Inventory by owner, created date, and last used date. This helps you to locate and identify your access tokens more quickly.

Thank you Chaitanya Sonwane for your contribution!

Security risk management

Handling of needs statements in pipeline execution policies for compliance: Security Policy Management

To strengthen your control over pipeline execution, jobs enforced in the .pipeline-policy-pre reserved stage are now required to complete before jobs in subsequent stages can begin, regardless of whether the job defines any needs statements. Previously, jobs defined in the .pipeline-policy-pre stage and jobs in subsequent pipelines with a needs statement both started as soon as the pipeline executed. With this enhancement, jobs in subsequent stages must wait for the .pipeline-policy-pre to complete before starting any other jobs without dependencies, helping you enforce ordered execution and ensuring compliance within the security policies.

Our customers rely on reserved stages to enforce compliance and security checks before developer jobs run. A common use case is to enforce a security or compliance check that fails the entire pipeline if the check does not pass. Allowing jobs to run out of order could bypass this enforcement and weaken policy intent. This improvement provides you with a more consistent approach to compliance enforcement.

To inject jobs at the beginning of the pipeline without overriding needs behavior, configure the jobs to use a custom stage with the new custom stages feature that we introduced in 17.9.

Change the severity of a vulnerability: Vulnerability Management

When triaging vulnerabilities, you need the flexibility to adjust severity levels based on your organization's unique security context and risk tolerance. Until now, you had to rely on the default severity levels assigned by security scanners, which might not accurately reflect the risk level for your specific environment.

Now you can manually change the severity of specific vulnerability occurrences to better align with your organization's security needs. This allows you to:

• Adjust the severity level of any vulnerability to Critical, High, Medium, Low, Info, or Unknown.
• Change multiple vulnerabilities' severity at once from the vulnerability report.
• Easily identify which vulnerabilities have custom severity levels through visual indicators.

All severity changes are tracked in the vulnerability history and audit events and can only be overridden by your team members who have at least the Maintainer role for the project, or a custom role with the admin_vulnerability permission. This feature gives security teams more flexibility and control over vulnerability prioritization.

Premium

GitLab Duo Chat is now resizable: Duo Chat

In the GitLab UI, you can now resize the Duo Chat drawer. This makes it easier to view code outputs, or keep Chat open whilst working with GitLab in the background.

Create

Path exclusions for CODEOWNERS: Source Code Management, Code Review Workflow

When teams configure a CODEOWNERS file, it's common to include broad matching patterns for paths and file types. These broad configurations can be problematic if your documentation, automated build files, or other patterns don't require a specified Code Owner.

You can now configure the CODEOWNERS file with path exclusions to ignore certain paths. This is helpful when you want to exclude specific files, or paths from requiring a Code Owner approval.

Configurable squash settings in branch rules: Source Code Management, Code Review Workflow

Different Git workflows require different strategies for handling commits when merging between branches. In previous versions of GitLab, you could only set a single strategy for whether commits should be squashed when merging and how strongly that should be enforced. This setup could be error-prone or require developers to make specific choices to follow the project convention for different branch targets.

You can now configure squash settings for each protected branch through branch rules. For example, you can:

• Require squashing when merging from your feature branch to the develop branch to keep history clean.
• Disable squashing when merging from the develop branch to main branch when you want the commit history to remain intact.

This flexibility ensures consistent commit history across your project while respecting the unique needs of each branch in your workflow, all without requiring manual developer intervention.

Package

Package registry adds audit events: Package Registry

Package registry operations are now logged as audit events so teams can track when packages are published or deleted to meet compliance requirements.

Before this release, there was no built-in way to track who published or made changes to packages. Teams had to create their own tracking systems or manually document package changes to maintain logs of these activities. Now, each audit event shows who made a change, when it happened, how they were authenticated, and exactly what changed in the package.

Audit events for projects are stored either in a group namespace or the project itself for individual project Owners. Groups can turn off audit events to manage storage needs.

Software supply chain security

Select a compliance framework as default from the dropdown list on the Frameworks page: Compliance Management

Users can set a default compliance framework in the GitLab compliance centre, which is applied to all new and imported projects that are created in that group. A default compliance framework has a default label to help users identify it.

To make it easier to set a compliance framework as default, we are introducing the ability for users to set a framework as default by using the framework dropdown list on the list frameworks page in the compliance center of a top-level group. This feature isn't available in the compliance center of subgroups nor projects.

Map OmniAuth profile attributes to user (self-managed only): User Management

You can now map the Organization and Title profile attributes from an OmniAuth identity provider (IdP) to a user's GitLab profile. This allows the IdP to be the single source of truth for these attributes, and users can no longer change them.

Core

Timestamps of when placeholder users were created: Importers

Previously, when you imported groups or projects, you could not see when placeholder users were created.

With this release, we've added timestamps so you can track the progress of your migration and troubleshoot any issues as they occur.

Bulk edit to-do items: Notifications

You can now efficiently manage your To-Do List with our improved bulk editing feature. Select multiple to-do items and mark them as done or snooze them in one go, giving you more control over your tasks and helping you stay organized with less effort.

Snooze to-do items: Notifications

You can now snooze notifications in your To-Do List, allowing you to temporarily hide items and focus on what's most important right now. Whether you need an hour to concentrate or want to revisit a task tomorrow, you'll have fine-grained control over when notifications reappear, helping you manage your workflow more effectively.

Request reassignment by using a CSV file: Importers

With this release, user contribution mapping now supports bulk reassignment by using a CSV file.

If you have a large user base with many placeholder users, group members with the Owner role can:

• Download a prefilled CSV template.
• Add GitLab usernames or public emails from the destination instance.
• Upload the completed file to reassign all contributions at once.

This method eliminates tedious manual reassignment through the UI.

To further streamline large-scale migrations, API support for CSV-based reassignment is now also available.

New navigation experience for projects in Your Work: Groups & Projects

We're excited to announce significant improvements to the project overview in Your Work, designed to streamline how you discover and access your projects. This update introduces a more intuitive tab-based navigation system that better reflects how users interact with their projects.

The new Contributed tab (previously Yours) now displays all projects you've contributed to, including your personal projects, making it easier to track your development activity.

Find your individual projects faster with the Personal tab, now prominently featured in the main navigation.

Access team projects through the Member tab (formerly All), showing all projects where you have membership.

The Inactive tab (previously Pending deletion) now provides a comprehensive view of both archived projects and those pending deletion.

Further, if you have the appropriate permissions, you can now edit or delete a project directly from the Your Work projects overview.

These changes reflect our commitment to creating a more efficient and user-friendly GitLab experience. The new layout helps you focus on the projects that matter most to your work, reducing the time spent navigating between different project categories.

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

Improved project creation permission settings: Groups & Projects

We've improved the project creation permission settings to make them more clear, intuitive, and aligned with our security principles. The improved settings include:

• Renamed the "Default project creation protection" dropdown to "Minimum role required for project creation" to clearly reflect the setting's purpose.
• Renamed the "Developers + Maintainers" dropdown option to "Developers" for consistency across the platform.
• Reordered the dropdown options from most restrictive to least restrictive access level.

These changes make it easier to understand and configure which roles can create projects within your groups, helping administrators enforce appropriate access controls more confidently.

Thank you @yasuk for this community contribution!

Plan

Authenticate to private Pages with an access token: Pages

You can now authenticate to private GitLab Pages sites programmatically using access tokens, making it easier to automate interactions with your Pages content. Previously, accessing restricted Pages sites required interactive authentication through the GitLab UI.

This powerful enhancement increases productivity while maintaining security, giving developers more flexibility in how they interact with and distribute private Pages content.

GitLab Query Language views Beta: Wiki, Team Planning

Tracking and understanding work in progress across GitLab previously required navigating multiple locations, reducing team efficiency and consuming valuable time.

This release introduces GitLab Query Language (GLQL) views Beta so you can create dynamic, real-time work tracking directly in your existing workflows.

GLQL views embed live data queries in Markdown code blocks throughout Wiki pages, epic descriptions, issue comments, and merge requests.

Previously available as an experiment, GLQL views now enter beta with support for sophisticated filtering using logical expressions and operators across key fields, including assignee, author, label, and milestone. You can customize your view's presentation as tables or lists, control which fields appear, and set result limits to create focused, actionable insights for your team.

Teams can now maintain context while accessing the information they need, creating shared understanding, and improving collaboration — all without leaving their current workflow.

We welcome your feedback on GLQL views as we continue to enhance this feature.

Enhanced markdown experience: Markdown

GitLab Flavored Markdown has been enhanced with several powerful improvements:

• Improved math and image handling:
  • Disable math rendering limits in your group or self-hosted instance to handle more complex mathematical expressions.
  • Control image dimensions precisely using pixel values or percentages to better manage content layout.
• Enhanced editor experience:
  • Continue lists automatically when pressing Enter/Return.
  • Shift text left or right using keyboard shortcuts.
  • Create clear term-definition pairs using description list syntax.
  • Adjust video widths flexibly.
• Better content organization:
  • Navigate content more easily with auto-expanding summary quick views (add +s to URLs).
  • See referenced issue titles render automatically (add + to URLs).
  • Organize content modularly using include syntax.
  • Create visually distinct callouts and warnings using alert boxes.

These improvements make GitLab Flavored Markdown more powerful for teams creating and maintaining documentation while offering greater flexibility in how content is presented and organized.

New issues look now in beta: Team Planning

Issues now share a common framework with epics and tasks, featuring real-time updates and workflow improvements:

• Drawer view: Open items from lists or boards in a drawer for quick viewing without leaving your current context. A button at the top lets you expand to full page view.
• Change type: Convert types between epics, issues, and tasks using the "Change type" action (replaces "Promote to epic")
• Start date: Issues now support start dates, aligning their functionality with epics and tasks.
• Ancestry: The complete hierarchy is above the title and the Parent field in the sidebar. To manage relationships, use the new quick action commands /set_parent, /remove_parent, /add_child, and /remove_child.
• Controls: All actions are now accessible from the top menu (vertical ellipsis), which remains visible in the sticky header when scrolling.
• Development: All development items (merge requests, branches, and feature flags) related to an issue or task are now consolidated in a single, convenient list.
• Layout: UI improvements create a more seamless experience between issues, epics, tasks, and merge requests, helping you navigate your workflow more efficiently.
• Linked items: Create relationships between tasks, issues, and epics with improved linking options. Drag and drop to change link types and toggle the visibility of labels and closed items.

Description templates for epics, issues, tasks, objectives and key results: Portfolio Management

You can now streamline your workflow and maintain consistency across your projects with description templates for work items (epics, tasks, objectives, and key results).

This powerful addition allows you to create standardized templates, saving you time and ensuring all crucial information is included every time you create a new work item.

Create

Ignore specific revisions in Git blame: Source Code Management

When browsing the history of a repository, there might be commits that aren't relevant to otherwise meaningful changes in the project. This can happen during:

• Refactors where you change from one library to another without changing functionality.
• Implementation of code formatters or linters that require standardizing the entire codebase.

When you look through the history of a project with blame, these kinds of commits make it difficult to understand the changes that occurred. Git supports identifying these commits with a .git-blame-ignore-revs file in your project. GitLab now allows you to toggle the blame view to show or hide these specific revisions in the "Blame preferences" dropdown list, making it easier to understand the history of your project.

Verify

GitLab Runner 17.10: GitLab Runner Core

We’re also releasing GitLab Runner 17.10 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:
Perform Autoscaler executor health check before instance usage
Expand Docker executor volumes
Add Docker excecutor configuration for device addition for services

Bug Fixes:
The Windows gitlab-runner-helper image fails due to invalid volume specification for the `/opt/step-runner' path
Repository mirroring for RPM packages is not working properly in GitLab Runner 17.7.0 and later
Running git submodule update --remote in GitLab CI/CD returns an error

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

Package

Docker Hub authentication for the dependency proxy: Container Registry

The GitLab Dependency Proxy for container images now supports authentication with Docker Hub, helping you avoid pipeline failures due to rate limits and giving you access to private images.

Starting April 1, 2025, Docker Hub will enforce stricter pull limits (100 per 6-hour window per IPv4 address or IPv6 /64 subnet) for unauthenticated users. Without authentication, your pipelines might fail once these limits are reached.

With this release, you can configure Docker Hub authentication through the GraphQL API using your Docker Hub credentials, personal access token, or organization access tokens. Support for UI configuration will be available in GitLab 17.11.

Software supply chain security

Wider distribution for token expiration notifications: System Access

Previously, access token expiry notification emails were only sent to direct members of the group and project in which the token was expiring. Now, these notifications are also sent to inherited group and project members, if the setting is enabled. This wider distribution makes it easier to manage the token before expiry.

Identify and revoke tokens with token information API (self-managed only): System Access

GitLab administrators can now use a unified API to identify and revoke tokens. Previously, administrators had to use endpoints related to the specific type of token. This API allows revocation regardless of the type. For a list of supported token types, see the Token information API.

Thank you Nicholas Wittstruck and the team from Siemens for your contribution!

Configurable token duration with GitLab OIDC provider (self-managed only): System Access

When using GitLab as an OpenID Connect (OIDC) provider, you can now configure the duration of ID tokens with the id_token_expiration attribute. Previously, ID tokens had a fixed expiration time of 120 seconds.

Thank you Henry Sachs for your contribution!

Extended webhook triggers for expiring tokens: System Access

You can now trigger webhook events 60 and 30 days before a project or group access token expires. Previously, these webhook events only triggered 7 days before expiry. This is an optional setting that matches the existing email notification schedule for expiring tokens.

Original source

Software supply chain security

Use API to disable 2FA for individual enterprise users (SaaS only): System Access

You can now use the API to clear all two-factor authentication (2FA) registrations for an individual enterprise user. Previously, this was only possible in the UI. Using the API allows for automated and bulk operations, saving time when 2FA resets need to be done at scale.

Ultimate

Gitlab Duo Self-Hosted is generally available (self-managed only): Self-Hosted Models

You can now host selected large language models (LLMs) in your own infrastructure and configure those models as the source for GitLab Duo Code Suggestions and Chat. This feature is now generally available on self-managed GitLab environments with applicable licensing.

With GitLab Duo Self-Hosted, you can use models hosted either on-premise or in a private cloud as the source for GitLab Duo Chat or Code Suggestions. We currently support open-source Mistral models on vLLM or AWS Bedrock, Claude 3.5 Sonnet on AWS Bedrock, and OpenAI models on Azure OpenAI. By enabling self-hosted models, you can leverage the power of generative AI while maintaining complete data sovereignty and privacy.

Please leave feedback in issue 512753.

Plan

Speed up adding new child items by keeping the form open: Portfolio Management

We've streamlined the process of creating multiple child items by keeping the form open after each submission, making it easier to add multiple entries without extra clicks. This update saves you time and ensures a smoother workflow when managing your tasks.

Application security testing

Configure DAST scans through the UI with full control: DAST

To effectively test complex applications, security teams need flexibility when they configure DAST scans. Previously, DAST scans configured through the UI had limited configuration options, which prevented successful scanning of applications with specific security requirements. This meant you had to use pipeline-based scans even for quick security assessments.

You can now configure DAST scans through the UI with the same granular control available in pipeline-based scans. This includes:

• Full authentication configuration, including custom headers and cookies
• Precise crawl settings like maximum pages, maximum depth, and excluded URLs
• Advanced scan timeouts and retry attempts
• Custom scanner behavior, like maximum links to crawl and DOM depth
• Targeted scanning modes for specific vulnerability types

Save these configurations as reusable profiles to maintain consistent security testing across your applications. Every configuration change is tracked with audit events, so you know when scan settings are added, edited, or removed.

This enhanced control helps you run more effective security scans while maintaining compliance using detailed audit trails. Instead of spending time managing pipeline configurations, you can quickly launch the right scan for each application to find and fix vulnerabilities faster.

Enable Dependency Scanning using SBOM for Cargo, Conda, Cocoapods and Swift projects: Software Composition Analysis

In GitLab 17.9 the Composition Analysis team starts the transition to Dependency Scanning using SBOM with the new Dependency Scanning analyzer. This analyzer will be a replacement for Gemnasium, which will reach end of support in 18.0, remaining available for use through GitLab 19.0.

The Dependency Scanning using SBOM approach will better support customers through expansion of language support, a tighter integration and experience within the GitLab platform, and a shift towards industry standard report types (SBOM-based scanning and reporting). As of GitLab 17.9, the new Dependency Scanning analyzer will be enabled by default in the latest Dependency Scanning CI/CD template (Dependency-Scanning.latest.gitlab-ci.yml) for the following project and file types:

• C/C++/Fortran/Go/Python/R projects using conda with a conda-lock.yml file.
• Objective-C projects using Cocoapods with a podfile.lock file.
• Rust projects using Cargo with a cargo.lock file.
• Swift projects using Swift with a package.resolved file.

With this change we are introducing a new CI/CD variable: DS_ENFORCE_NEW_ANALYZER which is set to false by default.

This approach ensures that all existing customers of the latest template continue to use the Gemnasium analyzer by default and it enables automatically the new Dependency Scanning analyzer for the file types listed above.

Existing customers who wish to migrate to the new Dependency Scanning analyzer can set DS_ENFORCE_NEW_ANALYZER to true (at the project, group, or instance level). You can read more about this change in the deprecation announcement and the associated migration guide.

Customers who want to entirely prevent the use of the new Dependency Scanning analyzer must set the CI/CD variable DS_EXCLUDED_ANALYZERS to dependency-scanning.

License scanning support for Swift packages: Software Composition Analysis

In GitLab 17.9, we added support for license scanning on Swift packages. This will allow users who use Swift within their projects to better understand the licensing of their Swift packages.

This data is available to composition analysis users through the Dependency List, SBOM reports, and GraphQL API.

Multi-core Advanced SAST offers faster scans: SAST

GitLab Advanced SAST now offers multi-core scanning as an opt-in feature to improve performance.

This can reduce scan duration significantly, especially for larger codebases.

To enable it, set the SAST_SCANNER_ALLOWED_CLI_OPTS CI/CD variable to --multi-core N, where N is the desired number of cores to use.

You should only set this variable on the gitlab-advanced-sast job, not any other jobs.

Check the documentation for important guidance on how to select the right value.

We're working to enable this performance improvement by default; this is tracked in issue 517409.

Software supply chain security

Search and filter the Credentials Inventory: System Access

You can now use search and filter capabilities in the Credentials Inventory. This makes it easier to identify tokens and keys which fall within certain user-defined parameters, including tokens that expire within a certain window. Previously, the entries in the Credentials Inventory were presented as a static list.

New permissions for custom roles: Permissions

You can create custom roles with the Read compliance dashboard permission. Custom roles allow you to grant only the specific permissions users need to complete their tasks. This helps you define roles that are tailored to the needs of your group, and can reduce the number of users who need the Owner or Maintainer role.

Security risk management

EPSS, KEV, and CVSS data for vulnerability risk prioritization: Vulnerability Management

We've added support for the following vulnerability risk data:

• Exploit Prediction Scoring System (EPSS)
• Known Exploited Vulnerabilities (KEV)
• Common Vulnerabilities and Exposures (CVE)

You can now efficiently prioritize risk across your dependency and container image vulnerabilities using this data. You can find the data in the Vulnerability Report and in the Vulnerability Details page.

Enforce custom stages in pipeline execution policies: Security Policy Management

We're excited to introduce a new capability for pipeline execution policies that allows you to enforce custom stages into your CI/CD pipelines in Inject mode. This feature provides greater flexibility and control over your pipeline structure while maintaining security and compliance requirements, supplying you with:

• Enhanced pipeline customization: Define and inject custom stages at specific points in your pipeline, allowing for more granular control over job execution order.
• Improved security and compliance: Ensure that security scans and compliance checks run at the most appropriate times in your pipeline, such as after build but before deployment.
• Flexible policy management: Maintain centralized policy control while allowing development teams to customize their pipelines within defined guardrails.
• Seamless integration: Custom stages work alongside existing project stages and other policy types, providing a non-disruptive way to enhance your CI/CD workflows.

How does it work?

The new and improved inject_policy strategy for pipeline execution policies allows you to define custom stages in your policy configuration. These stages are then intelligently merged with your project's existing stages using a Directed Acyclic Graph (DAG) algorithm, ensuring proper ordering and preventing conflicts.

For example, you can now easily inject a custom security scanning stage between your build and deploy stages.

The inject_policy stage replaces inject_ci which will be deprecated, allowing you to opt into the inject_policy mode to gain the benefits. The inject_policy mode will become the default when configuring policies with Inject in the policy editor.

Block deletion of active security policy projects: Security Policy Management

To ensure secure management of security policies and prevent disruption to enabled and enforced policies, we've added protection to prevent deletion of security policy projects that are in active use.

If a security policy project is linked to any groups or projects, the links must be removed before the security policy project can be deleted.

Dependency list filter by component in projects: Dependency Management

On the Dependencies list in a project, you can now filter by the package name using the Component filter.

Previously, you could not search for packages in the Dependencies list for a project level. Now, setting the Component filter will find packages that contain the specified string.

Filter by identifier in the project Vulnerability Report: Vulnerability Management

In the Vulnerability Report for a project, you can now filter the results by vulnerability identifier so you can find specific vulnerabilities (like CVEs or CWEs) that are in your project.

You can use the identifier in conjunction with other filters like the severity, status, or tool filters. The vulnerability identifier filter is limited to reports with 20,000 vulnerabilities or less.

Support custom roles in merge request approval policies: Permissions, Security Policy Management

We've made merge request approval policies more flexible by adding the ability to assign custom roles as approvers.

You can now tailor approval requirements to match your organization’s unique team structures and responsibilities, ensuring the right roles are engaged in the review process based on the policy. For example, require approval from AppSec Engineering roles for security reviews and Compliance roles for license approvals.

Support merge request variables in pipeline execution policies: Security Policy Management

Pipeline execution policies now support additional merge request variables, allowing you to create more sophisticated policies that take into account information related to the merge request. This provides more targeted and efficient control over CI/CD enforcement. The following variables are now supported:

• CI_MERGE_REQUEST_SOURCE_BRANCH_SHA
• CI_MERGE_REQUEST_TARGET_BRANCH_SHA
• CI_MERGE_REQUEST_DIFF_BASE_SHA

With this enhancement, you can:

• Implement advanced security scans that compare changes between source and target branches, ensuring thorough code review and vulnerability detection.
• Create dynamic pipeline configurations that adapt based on the specifics of each merge request, streamlining your development process.

Premium

GitLab-managed Kubernetes resources: Environment Management, Deployment Management

Deploy your applications to Kubernetes with more control and automation using GitLab-managed Kubernetes resources. Previously, you had to manually configure Kubernetes resources for each environment. Now, you can use GitLab-managed Kubernetes resources to automatically provision and manage these resources.

With GitLab-managed Kubernetes resources, you can:

• Automatically create namespaces and service accounts for new environments
• Manage access permissions through role bindings
• Configure other required Kubernetes resources

When your developers deploy applications, GitLab automatically creates the necessary Kubernetes resources based on the provided resource templates, streamlining your deployment process and maintaining consistency across environments.

Restrict users from making their profile private (self-managed only): User Management, User Profile

Users can choose to make their user profile public or private.

Administrators can now control whether users have the option to make profiles private across their GitLab instance. In the Admin Area, "Allow users to make their profiles private" controls this setting. This setting is enabled by default, allowing users to choose private profiles.

Plan

Run multiple Pages sites with parallel deployments: Pages

You can now create multiple versions of your GitLab Pages sites simultaneously with parallel deployments. Each deployment gets a unique URL based on your configured prefix. For example, with a unique domain your site would be accessible at project-123456.gitlab.io/prefix, or without a unique domain at namespace.gitlab.io/project/prefix.

This feature is especially helpful when you need to:

• Preview design changes or content updates.
• Test site changes in development.
• Review changes from merge requests.
• Maintain multiple site versions (for example, with localized content).

Parallel deployments expire after 24 hours by default to help manage storage space, though you can customize this duration or set deployments to never expire. For automatic cleanup, parallel deployments created from merge requests are deleted when the merge request is merged or closed.

Enhancing workflow visibility: new insights into merge request review time: Value Stream Management, Code Review Workflow

To improve development workflow tracking, Value Stream Analytics (VSA) has been extended with a new event - Merge request last approved at. The merge request approval event marks the end of the review phase and the start of the final pipeline run or merge stage. For example, to calculate the total merge request review time, you can create a VSA stage with Merge request reviewer first assigned as the start event and Merge request last approved at as the end event.

With this enhancement, teams gain deeper insights into opportunities to optimize review times, which help reduce the overall cycle time of development, leading to faster software delivery.

Create

Add project files to Duo Chat in VS Code and JetBrains IDEs: Editor Extensions, Duo Chat

Add your project files directly to Duo Chat in VS Code and JetBrains to unlock more powerful, context-aware AI assistance.

By adding project files, Duo Chat gains deep understanding of your specific codebase, enabling it to provide highly contextual and accurate responses. This context awareness gives you more relevant code explanations, precise debugging help, and suggestions that seamlessly integrate with your existing codebase. We welcome your feedback on this new, exciting feature. Please share your thoughts in our feedback issue.

Workspaces container support with Sysbox: Workspaces

GitLab workspaces now supports building and running containers directly in your development environment. When your workspace runs on a Kubernetes cluster configured with Sysbox, you can build and run containers without additional configuration.

Introduced in GitLab 17.4 as part of our sudo access feature, this capability enables you to maintain your complete container workflow in your GitLab workspace environment.

Create workspaces without a custom devfile: Workspaces

Previously, setting up a workspace required creating a devfile.yaml configuration file. GitLab now provides you with a default file that includes common development tools. This enhancement:

• Removes configuration barriers.
• Enables you to create a workspace quickly from any project.
• Includes common development tools pre-configured and ready to use.
• Lets you focus on development instead of configuration.

Start developing and create a workspace immediately without additional setup or configuration steps.

Workspace extensions now support proposed APIs: Workspaces

Workspace extensions now support enabling proposed APIs, improving compatibility and reliability in production environments. This update allows extensions that depend on proposed APIs to run without errors, including critical development tools like the Python Debugger. The change expands API access while maintaining stability.

Software supply chain security

Apply a compliance framework by using a project's compliance center: Compliance Management

In GitLab 17.2, we released the ability for group owners to apply and remove compliance frameworks for all projects

in a group by using the group's compliance center.

We have expanded this to now allow group owners to also apply and remove compliance frameworks at the project level.

This will make it even easier for group owners to apply and monitor compliance frameworks at the project level.

The ability to apply and remove compliance frameworks at the project level is only available for group owners and

not project owners.

OAuth application authorization audit event: Audit Events

Previously, when a user authorized an OAuth application, no audit event was generated. However, this event is important for security teams to

monitor the OAuth applications authorized by users on a specific GitLab instance.

With this release, GitLab now provides a User authorized an OAuth application audit event to track when users successfully authorize OAuth

applications. This new audit event further improves your ability to audit your GitLab instance.

Email notifications for service accounts: System Access

You can now set a custom email address to receive email notifications for service accounts. When a custom email address is specified when creating a service account, GitLab sends notifications to that address. Each service account must use a unique email address. This can help you monitor processes and events more effectively.

Thank you Gilles Dehaudt, Étienne Girondel, Kevin Caborderie, Geoffrey McQuat, Raphaël Bihore from the SNCF Connect & Tech team for your contribution!

Support for additional group memberships with multiple OIDC providers (self-managed only): System Access

You can now configure additional group memberships when using multiple OIDC providers. Previously, if you configured multiple OIDC providers, you were limited to a single group membership.

Custom expiration date for rotated service account tokens: System Access

When rotating an access token for a service account, you can now use the expires_at attribute to set a custom expiration date. Previously, tokens automatically expired seven days after rotation. This allows for more granular management of token lifetimes, enhancing your ability to maintain secure access controls.

Core

Simplified access to deployments within project environments: Environment Management

Have you ever struggled to get an overview of your deployments within a project? You can now view recent deployment details in the environments list without having to expand each environment. For each environment, the list shows your latest successful deployment and, if different, your most recent deployment attempt.

Composite identity for more secure AI connections: Duo Workflow

Previously, a request to GitLab could only be authenticated as a single user. With composite identity, we have now made it possible to authenticate a request as a service account and a user simultaneously.

AI agent use cases often require permissions to be based on the user who initiated the tasks in a system, while simultaneously showing a distinct identity that's separate from the initiating user. A composite identity is our new identity principal, which represents an AI agent's identity. This identity is linked with the identity of the human user who requests actions from the agent.

Whenever an AI agent action attempts to access a resource, a composite identity token is used. This token belongs to a service account, and is also linked with the human user who is instructing the agent. The authorization checks that run on the token take into account both principals before granting access to a resource. Both identities need to have access to the resource, otherwise access is denied.

This new functionality enhances our ability to protect resources stored in GitLab.

For more information about how the composite identity for service accounts can be used, see the documentation.

Implement OCI-based GitOps with the FluxCD CI/CD component: Container Registry, Deployment Management, Component Catalog

Have you ever wondered how to implement GitOps best practices with GitLab? The new FluxCD component makes it easy. Use the FluxCD component to package Kubernetes manifests into OCI images and store the images in OCI-compatible container registries. You can optionally sign the images and trigger an immediate FluxCD reconciliation.

Get started with the GitLab integration with Kubernetes: Deployment Management

In this release, we added new Kubernetes Getting started guides that show you how to use GitLab to deploy applications to Kubernetes directly and with FluxCD. These easy-to-follow tutorials don't require in-depth Kubernetes knowledge to complete, so both novice and experienced users can learn how to integrate GitLab and Kubernetes.

To supplement the Kubernetes Getting started guides, we also included a series of recommendations for integrating GitLab into Kubernetes environments.

Discover and migrate certificate-based Kubernetes clusters

The certificate-based Kubernetes integration will be turned off on GitLab.com for all users between May 6, 2025 9:00 AM UTC and May 8, 2025 22:00 PM UTC, and will be removed from GitLab Self-Managed instances in GitLab 19.0 (expected in May 2026).

To help users migrate, we added a new cluster API endpoint that group Owners can query to discover any certificate-based clusters registered to a group, subgroup, or project. We also updated the migration documentation to provide instructions for different types of use cases.

We encourage all GitLab.com users to check if they are affected, and to plan their migrations as soon as possible.

Manage project integrations from a group with the REST API: API, Integrations

Previously, you could manage project integrations from a group in the GitLab UI only. With this release, it's possible to manage these integrations with the REST API too.

Thanks to Van for their initial community contribution, which was subsequently picked up and completed by GitLab.

Group sharing visibility enhancement: Groups & Projects

We're excited to announce expanded visibility for group sharing across GitLab. Previously, while you could see shared projects on a group's overview page, you couldn't see which groups your group had been invited to join. Now you can view both Shared projects and Shared groups tabs on the group overview page, giving you a complete view of how your groups are connected and shared throughout your organization. This makes it easier to audit and manage group access across your organization.

We welcome feedback about this change in epic 16777.

Plan

Wiki page comments: Wiki

You can now add comments directly on wiki pages, transforming your documentation into an interactive collaboration space.

Comments and threads on wiki pages help teams:

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

With wiki comments, teams can maintain living documentation that evolves alongside their projects through direct feedback and discussion.

Control access to GitLab Pages for groups: Pages

You can now restrict GitLab Pages access at the group level. Group owners can enable a single setting to make all Pages sites in a group and its subgroups visible only to project members. This centralized control simplifies security management without modifying individual project settings.

Change work item type to another: Portfolio Management

You can now easily change the type of your work items, giving you the flexibility to manage your projects more efficiently.

Work items GraphQL API - additional query filters: Portfolio Management

The Work Items GraphQL API now includes additional query filters that let you filter by:

• Created, updated, closed, and due dates
• Health status
• Weight

These new filters give you more control when querying and organizing work items through the API.

Verify

Automatic CI/CD pipeline cleanup: Continuous Integration (CI) Scaling

In the past, if you wanted to delete older CI/CD pipelines, you could only do this through the API.

In GitLab 17.9, we have introduced a project setting that allows you to set a CI/CD pipeline expiry time.

Any pipelines and related artifacts older than the defined retention period are deleted.

This can help reduce the disk usage in projects that run lots of pipelines that generate large artifacts, and even improve overall performance.

GitLab Runner 17.9: GitLab Runner Core

We're also releasing GitLab Runner 17.9 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:

• Add health check for runner autoscaler instances
• Add histogram metrics for runner prepare stage duration
• Add support for custom service container names to the Kubernetes executor

Bug Fixes:

• GitLab Runner is unable to retrieve cache from S3 Express One Zone
• GitLab Runner on Kubernetes reports 'script_failure' instead of 'runner_system_failure' for AWS Spot instances

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

Software supply chain security

Rotate access tokens with self_rotate scope: System Access

You can now use the self_rotate scope to rotate access tokens. This scope is available for personal, project, or group access tokens. Previously, this required two requests: One to obtain a new token, then another to perform the token rotation.

Thank you Stéphane Talbot and Anthony Juckel for your contribution!

View inactive project and group access tokens (self-managed only): System Access

You can now view inactive group and project access tokens in the UI. Previously, GitLab instantly deleted project and group access tokens after they expired or were revoked. This lack of a record of inactive tokens made auditing and security reviews more difficult. GitLab now retains inactive group and project access token records for 30 days, which helps teams track token usage and expiration for compliance and monitoring purposes.

View access token IP addresses: System Access

Previously, when viewing your personal access tokens, the only usage information you could see was how many minutes ago the token was used. Now, you can also see up to the last seven IP addresses that the tokens were used from. This combined information can help you track where your token is being used.

Thank you Jayce Martin, Avinash Koganti, Austin Dixon, and Rohit Kala for your contribution!

Original source