What’s new in Eficode ROOT: May 2026

Slack slash commands integration removed

The Slack slash commands integration is deprecated in favor of the GitLab for Slack app, which provides a more secure integration with the same capabilities.

From GitLab 19.0, users will no longer be able to configure or use Slack slash commands. This integration only exists on GitLab Self-Managed and GitLab Dedicated — GitLab.com users are not affected. Learn more here.

Trending tab removed from Explore projects page

The Trending tab in Explore > Projects and its associated GraphQL arguments are removed in GitLab 19.0. The trending algorithm only considers public projects, making it ineffective for Self-Managed instances that primarily use internal or private project visibility.

In the month before the GitLab 19.0 release, the Trending tab on GitLab.com will redirect to the Active tab sorted by stars in descending order.

Also removed: the trending argument in the Query.adminProjects, Query.projects, and Organization.projects GraphQL types. Learn more here.

ciJobTokenScopeAddProject GraphQL mutation removed

The ciJobTokenScopeAddProject GraphQL mutation is deprecated in favor of ciJobTokenScopeAddGroupOrProject, introduced alongside the CI/CD job token scope changes in GitLab 18.0. Update any automation or tooling using the deprecated mutation before upgrading. Learn more here.

ci_job_token_scope_enabled projects API attribute removed

The ci_job_token_scope_enabled attribute in the Projects REST API is removed in GitLab 19.0. This attribute was deprecated in GitLab 18.0 when the underlying setting was removed, and has since always returned false.

To control CI/CD job token access, use the CI/CD job token project settings. Learn more here.

Resource Owner Password Credentials (ROPC) OAuth grant removed

Support for the Resource Owner Password Credentials (ROPC) grant as an OAuth flow will be fully removed in GitLab 19.0. This aligns with the OAuth RFC Version 2.1 standard, which removes ROPC due to its inherent security limitations.

GitLab has already required client authentication for ROPC on GitLab.com since April 8, 2025. An administrator setting was added in 18.0 to allow controlled opt-out ahead of the removal.

After the 19.0 upgrade, ROPC cannot be used under any circumstances, even with client credentials. Any applications or integrations using this grant type must migrate to a supported OAuth flow — such as the Authorization Code flow — before upgrading. Learn more here.

Mattermost removed from the Linux package

In GitLab 19.0, bundled Mattermost is removed from the Linux package. Mattermost was first bundled with GitLab in 2015, but has since matured its own standalone deployment options. Additionally, with Mattermost v11, GitLab SSO was deprecated from their free offering, reducing the value of the bundled integration.

Customers not using the bundled Mattermost will not be impacted. If you currently use it, refer to Migrating from GitLab Omnibus to Mattermost Standalone in the Mattermost documentation for migration instructions. Learn more here.

Set subscription-level usage cap for GitLab Credits (Premium, Ultimate)

To help organizations manage costs, administrators can now set a monthly usage limit for On-Demand Credits at the subscription level. This cap acts as a hard guardrail against unexpected overage charges, making it easier for organizations to roll out the GitLab Duo Agent Platform more broadly.

When the configured cap is reached, access to the GitLab Duo Agent Platform is automatically suspended for all users on that subscription until the next billing cycle begins or the administrator modifies the limit. Administrators will receive an email notification when the cap is hit, and the cap automatically resets with each new billing period. Learn more here.

Set per-user GitLab Credits cap (Premium, Ultimate)

Administrators now have the ability to enforce an optional, per-user usage cap on GitLab Credits for each billing period. This new control mechanism ensures a more equitable distribution of the organization's credit pool by preventing any single user from using a disproportionate amount.

If an individual user reaches their configured credit limit, their access to the GitLab Duo Agent Platform is temporarily suspended. Importantly, this suspension affects only that user, allowing all other users to continue their work uninterrupted. The per-user cap functions in tandem with the existing subscription-level usage cap, with the stricter limit (the one reached first) taking precedence. Learn more here.

Security Manager role (Beta) (all users)

The new Security Manager role is now available in beta. This role offers a dedicated set of default permissions tailored for security professionals, which removes the need for them to be assigned Developer or Maintainer roles. This approach prevents over-privileging and maintains a clear separation of duties.

Key Permissions for the Security Manager Role:

• Vulnerability Management: Full access to view, triage, and manage vulnerabilities across projects and groups, including security dashboards and reports.
• Security Inventory: Ability to view a group's security inventory to assess scanner coverage across all associated projects.
• Configuration: View security configuration profiles and enable secret push protection for a group.
• Compliance: Access to compliance tools such as audit events, compliance center, compliance frameworks, and dependency lists at the group or project level.
• DAST Scanning: Create and execute on-demand DAST scans for a group.

To assign this role, navigate to a group, select Manage > Members, and invite or assign members to the Security Manager role. Learn more here.

Asynchronous transfer of projects (all users)

GitLab now offers more robust handling for large group and project transfers, which previously could result in timeouts. By adopting a unified state model for operations like transfer, archive, and deletion, we ensure more consistent behavior and enhance visibility into the state history and audit details. This shift includes asynchronous processing, specifically aimed at reducing timeouts during long-running transfer operations. Learn more here.

Fine-grained permissions for personal access tokens now available (Beta) (all users)

GitLab announced the beta release of fine-grained Personal Access Tokens (PATs). This new feature significantly enhances security by allowing you to restrict each token to specific resources and actions, unlike legacy PATs which grant access to every project and group you belong to. By limiting the scope of access, the potential impact of a leaked or compromised token is greatly reduced.

What to know:

• Your existing PATs will continue to function as they do now.
• You can still create legacy PATs without fine-grained permissions.
• This beta version currently covers approximately 75% of the GitLab REST API.

Future Plans (GA Release):

Full REST API coverage, GraphQL enforcement, and administrator policy controls are planned for the General Availability (GA) release. Learn more here.

Service Accounts available on GitLab Free (all users)

Service accounts are now available across all tiers. These accounts are designed for automated actions, data access, or running scheduled processes without depending on individual team member credentials, which is ideal for maintaining stable credentials in pipelines and third-party integrations, regardless of team member changes. Previously, service accounts were only available in Premium and Ultimate tiers. Free tier users are now permitted to create up to 100 service accounts per top-level group (this includes accounts created in subgroups or projects). Learn more here.

Create Service Account in subgroups and projects (all users)

Service accounts can now be created at the subgroup and project levels, offering more granular access control than broad, top-level group bots.

This new functionality allows teams to:

• Dedicated Access: Attach a specific service account to a single subgroup or project.
• Manage Access: Control the service account's permissions just like any other member within that namespace.
• Scope of Use:
• Group and subgroup service accounts can be invited to the group where they were created, as well as any descendant subgroups and projects.
• Project service accounts are restricted to their own project.

Learn more here.

Sign in securely with passkeys (all users)

GitLab now introduces support for passkeys, offering users a modern, phishing-resistant method for both passwordless sign-in and two-factor authentication (2FA). Passkeys leverage public-key cryptography, using your device's biometric data (fingerprint, face recognition) or PIN for secure account access.

Key Benefits of Using Passkeys:

• Passwordless Convenience: Access your account quickly and easily using your device's biometrics or PIN, eliminating the need to remember a complex password.
• Enhanced Security: Passkeys provide phishing-resistant protection. Your private key remains securely stored on your device, and only the public key is held by GitLab. This protects your account even in the event of a compromise on GitLab's servers.
• Automatic 2FA Integration: If you have 2FA enabled, passkeys will automatically become your default 2FA method for streamlined, secure access.
• Broad Device Compatibility: Passkeys are supported across various platforms, including desktop browsers, mobile devices (Android 9+, iOS 16+), and dedicated FIDO2/WebAuthn-compatible hardware security keys.

Learn more here.

GitLab Duo Agent Platform Self-Hosted models now available for cloud licenses (Premium, Ultimate)

GitLab Duo Agent Platform is now generally available for customers who utilize a cloud license. This feature is billed based on usage.

Administrators have the capability to set up compatible models for the GitLab Duo Agent Platform. If using AWS Bedrock or Azure OpenAI, administrators can also configure Anthropic Claude or OpenAI GPT models. Learn more here. Learn more here.

Addition of self hosted model.

New navigation experience for groups in Explore (all users)

Group discovery experience within your GitLab instance's Explore section is enhanced. The groups list has been redesigned with a new, streamlined tabbed interface, offering clearer visibility into group status and making it easier to find relevant communities.

The new layout features two distinct views:

• Active Groups: Browse all groups you can access and join.
• Inactive/Archived Groups: View groups that are either archived or scheduled for deletion, providing insight into their lifecycle status.

These improvements streamline group discovery and offer greater transparency into which groups are available. Learn more here.

Sticky action bar on wiki pages (all users)

The action bar on wiki pages is now permanently visible as you scroll. This "sticky" functionality means key actions, such as Edit, New page, Templates, and Page history, along with the page title, are always within easy reach. Previously, accessing these actions required scrolling back up to the top of the page. Learn more here.

Wiki sidebar toggle repositioned for easier access (all users)

The wiki sidebar toggle has been repositioned to the left, directly adjacent to the sidebar it controls.

To enhance accessibility, the toggle is now visible as a floating control even when the sidebar is collapsed, allowing for easy reopening without needing to scroll to the top of the page. Learn more here.

Introducing the work items list and saved views (all users)

The GitLab planning experience is significantly enhanced with two new, much-requested features: the work items list and saved views.

Work Items List. This feature unifies planning objects—like epics, issues, and other work items—into a single, consolidated list. Users no longer have to navigate separate pages for different item types, making it easier to understand how planning objects relate to one another.

Saved Views. Users can now create and store customized list settings, including preferred filters, sort orders, and display options. This standardization streamlines routine checks and promotes consistent ways for teams to view their work.

These updates represent the next major step in the GitLab work items journey, which is a unified architectural approach designed to ensure consistency and introduce new capabilities across all GitLab planning tools. Learn more here.

Sort users in the GitLab Credits dashboard (Premium, Ultimate)

GitLab Credits administrators can now efficiently manage high-volume usage. The Usage by User table in the dashboard now offers sorting capabilities by both total credits consumed and username.

By default, the list is sorted by total credits (highest first), instantly highlighting the top consumers. This feature is invaluable for administrators overseeing large deployments, enabling them to quickly perform cost allocation, chargeback reporting, and license utilization audits. Learn more here.

New navigation experience for projects in Explore (all users)

The projects page within Explore has been simplified to provide a cleaner, more focused experience. We have removed redundant options and consolidated content into two main views:

Active: This tab is for projects currently undergoing development and those with recent activity.

Inactive: This tab includes archived projects and those slated for deletion.

This streamlined organization involved removing several previous tabs:

• Most starred projects can now be found by applying the star count sort option to either the Active or Inactive tabs.
• All projects are still accessible by viewing both the Active and Inactive tabs.
• The Trending tab will be completely retired in GitLab 19.0 due to its limited functionality and low adoption.

The updated design enhances visual consistency with other project lists. All the original content remains available through a more logical structure and versatile sorting capabilities. Learn more here.

Task item support in Markdown tables (all users)

You can now use the standard task item checkbox syntax directly inside Markdown table cells. This eliminates the previous need for a cumbersome combination of raw HTML and Markdown, making it easier to maintain your tables within issues, epics, and other content. Learn more here.

Manage container virtual registries with a dedicated UI (Beta) (Premium, Ultimate)

Last milestone, we launched the beta for the container virtual registry, giving platform engineers the power to consolidate multiple upstream container registries (such as Docker Hub, Harbor, and Quay) under a single pull endpoint.

However, all initial configuration required direct API calls. This meant teams had to manage manual curl commands or maintenance scripts to create, manage, and modify their registries and upstream configurations. This friction added operational overhead and made the feature inaccessible to users less familiar with direct API interaction.

Now you can manage and create container virtual registries directly within the GitLab UI.

From the group-level container registry page, you can now perform all necessary tasks without leaving GitLab or writing a single API call:

• Create new virtual registries.
• Configure upstream sources, including authentication credentials.
• Edit existing configurations.
• Delete unwanted registries.

This seamless integration makes virtual registries a first-class feature of your group's artifact management workflow. Learn more here.

GLQL now has access to projects, pipelines, and jobs data sources (all users)

The GitLab Query Language (GLQL) has been enhanced with three new data sources: projects, pipelines, and jobs. This expansion enables teams to embed views of pipeline results, job statuses, and project overviews directly into wikis, issue/merge request descriptions, and repository Markdown files.

Furthermore, these new data types empower the Data Analyst Agent (which is powered by GLQL) to perform more detailed inspections. The agent can now inspect CI/CD job results, debug failures, provide detailed overviews of pipeline execution, and offer accurate summaries of projects within a namespace. Learn more here.

View historical months in GitLab Credits dashboard (Premium, Ultimate)

The GitLab Credits dashboard in the Customers Portal has been enhanced to include historical month navigation. Billing managers now have the ability to view past billing months, enabling them to analyze daily usage trends, compare consumption patterns over different periods, and more easily reconcile usage against invoices. This is a significant improvement, as the dashboard was previously limited to showing only the current billing month. With access to this historical data, administrators can now make better-informed decisions regarding credit allocation and accurately forecast future needs. Learn more here.

ClickHouse is generally available for Self-Managed deployments (all users)

GitLab enhanced the recommendations and configuration guidance for integrating GitLab Self-Managed instances with GitLab ClickHouse. Customers now have two options for setup: they can either utilize their own cluster or opt for the recommended ClickHouse Cloud service. This high-performance, scalable database integration is essential, as it powers various dashboards and enables access to multiple API endpoints within the analytics domain. These improvements are part of a broader architectural initiative to advance the GitLab analytics infrastructure. Learn more here.

Enhanced GitLab Duo Agent Platform analytics on Duo and SDLC trends dashboard (Premium, Ultimate)

The GitLab Duo and SDLC trends dashboard now offers enhanced analytics for measuring the impact of GitLab Duo on software delivery.

Key updates include:

• New single stat panels: These now track monthly unique users of the Agent Platform and the number of Agentic Chat sessions.
• Updated usage metrics: Metrics previously reported as a percentage of seat assignments have been changed to strictly report usage counts. This resolves an issue where usage counts for the Agent Platform, which is controlled under the new usage billing model, were previously missing.

Learn more here.

Download credit usage data as CSV (Premium, Ultimate)

Finance and operations teams can now easily perform cost allocation, chargeback reporting, and usage analysis without manual data gathering or support requests.

The GitLab Credits dashboard in the Customers Portal now allows billing managers to download credit usage data as a CSV file.

This export provides a daily, per-action breakdown of credit consumption for the current billing month, detailing usage of commitment, waiver, trial, on-demand, and included credits. The data can be readily used in tools like Excel, Google Sheets, or various BI applications. Learn more here.

Link credit usage to GitLab Duo Agent Platform sessions (Premium, Ultimate)

The GitLab Credits dashboard has been enhanced to provide a direct link between credit consumption and the specific GitLab Duo Agent Platform session that generated it.

In the per-user drill-down view, the Action column for Agent Platform usage types (like Foundational Agents or Agentic Chat) is now a clickable hyperlink. Clicking this link navigates directly to the corresponding session details.

This new feature establishes a clear, direct audit trail from billing records to the detailed AI session behavior. This eliminates the need for administrators to manually correlate timestamps across different systems when investigating credit usage, supporting escalations, or conducting compliance reviews. Learn more here.

Release evidence now includes packages (all users)

GitLab now resolves this by automatically associating packages with release evidence when the package version matches the release tag. This new feature establishes a verifiable and auditable link between the release and its packages without requiring any manual effort. As a result, the source code, artifacts, and packages are unified in a comprehensive and complete release snapshot. Learn more here.

Package protection rules now support Terraform modules (all users)

Package protection rules have been enhanced to allow scoping for terraform_module. This new capability restricts push access based on a minimum role requirement. You can configure this through various interfaces: the UI package type dropdown, the REST API, the GraphQL API, and the GitLab Terraform provider resource. Learn more here.

Kubernetes 1.35 support (all users)

To ensure full feature access when deploying applications via GitLab, please upgrade your connected Kubernetes clusters to version 1.35. GitLab now offers complete support for this version. Learn more here.

Epic weights (Premium, Ultimate)

You can initially assign a "preliminary weight" to an epic before breaking it down into smaller child issues. As you decompose the epic, its total weight automatically updates, reflecting the "rolled-up weight" from all associated child issues. This functionality mirrors the existing weight rollup for issues and tasks.

The epic detail page provides clear visibility into both the preliminary estimate and the rolled-up total, enabling you to continuously refine your estimations over the project lifecycle. Learn more here.

Reconfigure inputs when manually running MR pipelines (all users)

Runtime customization for Merge Request (MR) pipelines is now available. Previously, the powerful CI/CD input feature—which allows manual pipeline runs with new values—was not supported in MR pipelines.

With this release, after configuring inputs for your MR pipelines, you can now optionally modify those inputs and change the pipeline's behavior anytime you run a new pipeline for a merge request. Learn more here.

Use runtime inputs with CI/CD jobs (all users)

Historically, managing dynamic job configurations with CI/CD variables has been cumbersome due to a complex override hierarchy, limiting their use cases.

GitLab now introduces Job Inputs to define explicit, typed inputs directly at the job level. This feature gives you precise control over the values a job accepts at runtime, offering several key benefits:

• Type Safety: Supports string, number, boolean, and array types.
• Default Values: Set static defaults or reference existing variables.
• Value Constraints: Define a strict list of accepted values.
• Validation: Use regular expressions (Regex) to validate input values.

Job Inputs can utilize their default values without any user intervention. However, you have the flexibility to modify these values when running a manual job or retrying a failed job. Learn more here.

Enforce merge request title naming conventions with regex (Premium, Ultimate)

GitLab now provides a native solution: you can configure a required title regex in your project settings.

When this feature is enabled, GitLab uses the regex pattern to evaluate the merge request title as a fundamental mergeability check. The merge will be blocked until the title is updated to fully comply with the pattern, irrespective of when the title was last modified.

How to Configure

This check is opt-in and only applies to projects where you explicitly configure it. Your existing merge request workflows remain unaffected otherwise.

To set up the required title regex, navigate to your project's Settings > Merge requests and enter your regex pattern in the Merge request title must match regex field. Learn more here.

GitLab Helm Chart registry generally available (all users)

Teams using Helm for managing Kubernetes deployments can now confidently use the GitLab Helm Chart registry for production workloads. Following a successful exit from beta, the registry is now generally available (GA) after significant architectural and reliability concerns were addressed.

The path to GA involved several key improvements:

• Increased Capacity: A hard limit preventing the index.yaml endpoint from returning more than 1,000 charts was resolved.
• Enhanced Reliability: A background indexing bug that caused newly published chart versions to be missing from the index was fixed.
• Security Assurance: A full AppSec security review was completed.
• High Availability: Geo replication support for the Helm metadata cache was added, ensuring high availability for self-managed customers utilizing GitLab Geo.

Platform and DevOps teams can leverage standard Helm client workflows to publish and install Helm charts directly within GitLab. The registry supports project-level endpoints and authentication via personal access tokens, deploy tokens, and CI/CD job tokens. This integration allows users to store their charts alongside the associated source code, pipelines, and security scanning, streamlining the DevOps workflow. Learn more here.

Conan 2.0 package registry support (Beta) (all users)

C and C++ development teams utilizing Conan for package management can now fully leverage GitLab's built-in registry support. Addressing a long-standing request from the community, the Conan package registry has been significantly upgraded.

Key Updates:

• Promoted to Beta: The Conan registry has moved from Experimental to Beta status, signaling increased stability and readiness for broader adoption.
• Conan 2.0 Compatibility: The registry now includes full compatibility with the modern Conan 2.0 toolchain, which was previously a limitation for many teams.
• Full v2 API Support: This update introduces complete v2 API compatibility, alongside recipe revision support and enhanced search capabilities.
• Seamless Workflow Integration: Teams can now use standard Conan client workflows—including proper handling of upload policies like the --force flag—to publish and install Conan 2.0 packages directly from GitLab.

This enhancement allows platform engineering teams managing C and C++ dependencies to consolidate their package management directly within GitLab. By eliminating the reliance on external artifact management solutions (like JFrog Artifactory), teams can centralize their source code, CI/CD pipelines, security scanning, and package dependencies in a single platform.

The Conan registry is flexible, supporting both project-level and instance-level endpoints, and integrates with various authentication methods, including personal access tokens, deploy tokens, and CI/CD job tokens. Learn more here.

Unverified vulnerabilities (Beta)

You can now view unverified vulnerabilities (findings where the complete trace from source to sink is not established) in the vulnerability report for Advanced SAST. This option is recommended if your priority is reducing false negatives, accepting a potentially higher rate of false positives. Learn more here.

Block merge requests with high exploitability risk

Security teams now have greater control over Merge Request (MR) approval policies with the introduction of configuration options based on Known Exploited Vulnerability (KEV) and Exploit Prediction Scoring System (EPSS) data.

This new feature allows you to:

• Block or require approval for findings listed in the KEV catalog (indicating active exploitation).
• Set thresholds for the EPSS score, blocking or requiring approval when a finding's score exceeds it.

When the security gate is triggered, the MR now includes KEV and EPSS context to help developers understand the violation.

Benefits: This allows security teams to precisely control which findings result in a block or a warning, reducing alert fatigue and keeping enforcement policies aligned with the most current threat landscape.

Learn more here.

Security attribute filters in group security dashboards

The group security dashboard now allows filtering of results using security attributes previously applied to the projects within that group.

The filterable security attributes are:

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

Learn more here.

Improved row interaction in the vulnerability report

The vulnerability report is now more intuitive and accessible thanks to several improvements. You can now navigate directly to a row's details by clicking anywhere on it. Furthermore, keyboard navigation has been enhanced, and the link styling for the vulnerability description and file location only appears when you hover over the respective links. Learn more here.

Assign CVSS 4.0 scores to vulnerabilities

The severity of vulnerabilities, a key industry standard, is now rated using the latest version, CVSS 4.0. You can now conveniently access and view this CVSS 4.0 score within the UI, specifically on the vulnerability details page and in the vulnerability report. Additionally, the score can also be queried via the API. Learn more here.

SAST scanning in security configuration profiles

Static Application Security Testing (SAST) - Default profile. This new SAST profile simplifies security coverage by allowing you to apply standardized static analysis across all projects without manual CI/CD configuration.

The profile automatically triggers SAST scans in two ways:

1. Merge Request Pipelines: A scan runs every time new commits are pushed to an open merge request branch. These results focus only on vulnerabilities introduced in that merge request.
2. Branch Pipelines (Default Branch Only): Scans are automatically run when changes are merged or pushed to the default branch, providing a complete security posture for the main codebase.

Learn more here.

Incremental scanning for Advanced SAST

GitLab Advanced SAST now supports incremental scans, which drastically cut down analysis time by focusing only on the changed sections of your codebase instead of requiring a full repository scan.

This enhancement builds upon diff-based scanning by delivering complete results for the codebase while integrating security testing more effectively into the development workflow. By analyzing only the modified code, your teams can enjoy faster security feedback without introducing friction or sacrificing speed. Learn more here.

Identifier list popover in the vulnerability report

The vulnerability report has been enhanced:

• The primary CVE identifier in each row is now a clickable link.
• If multiple identifiers exist, a "+N more" popover displays the full list.
• Every identifier links to its external reference (e.g., in the CVE, CWE, or WASC databases), allowing you to quickly access detailed information without leaving the report.

Learn more here.

Dependency resolution for Maven and Python SBOM scanning

GitLab's dependency scanning feature, which uses Software Bill of Materials (SBOM), has been significantly improved for Maven and Python projects. It can now automatically generate a dependency graph, which was previously a mandatory requirement.

While dependency scanning used to require users to provide a lock file or a graph file for accurate analysis, the analyzer will now automatically attempt to generate one if these files are unavailable. This enhancement simplifies the adoption of dependency scanning for Maven and Python projects by removing the need for a pre-existing lock file. Learn more here.

Export a security dashboard as a PDF

The security dashboard can now be exported as a PDF. This feature is useful for reports and presentations, as the exported document includes the current view of all dashboard elements—charts, panels, and any active filters—at the time of export. Learn more here.

Automated vulnerability severity overrides

New version now includes the ability to create vulnerability management policies that automatically adjust the severity of findings. These policies can be configured based on conditions such as CVE ID, CWE ID, file path, or directory.

When a policy is applied, it automatically updates the severity of any matching vulnerability on the default branch. This streamlined process reduces manual triage effort and helps developers prioritize the security issues most relevant to your business.

Please note that any manual severity overrides will still take precedence over the policy. All changes made by these policies are fully logged in the vulnerability's history and audit events for transparency. Learn more here.

Top CWE chart in security dashboards

The new security dashboards now feature a chart displaying the most frequent Common Weakness Enumerations (CWEs). This allows users to easily identify the most prevalent CWEs across a specific project or the entire instance, which is helpful for pinpointing areas for training, process improvements, or program enhancements. You can customize the view by grouping the dashboard data by severity, and you can apply filters based on severity, project, and report type. Learn more here.

Secret false positive detection with AI (beta)

GitLab introduces a new, AI-powered Secret False Positive Detection (beta) capability within GitLab Duo to significantly enhance security team efficiency by focusing on genuine threats.

False positives—such as test credentials or placeholder tokens incorrectly flagged as secrets—are a major time drain for security teams, leading to alert fatigue and eroding trust in scan results.

This new feature addresses this by automatically analyzing Critical and High severity secret detection vulnerabilities immediately after a security scan runs. The AI assessment, which determines the likelihood of a finding being a false positive, is seamlessly integrated into the vulnerability report. This gives security engineers the immediate context needed for faster, more confident triage decisions.

Key Features of AI-powered Secret False Positive Detection:

• Automatic Analysis: Runs without manual intervention after every security scan.
• Targeted Focus: Scoped specifically for Critical and High severity vulnerabilities to maximize signal-to-noise improvement.
• Contextual AI Reasoning: Each assessment includes an explanation, based on code context and vulnerability characteristics, of why the finding may or may not be a true positive.
• Confidence Scoring: A confidence score is provided to aid teams in prioritizing review based on the model's certainty.
• Seamless Integration: Results (severity, status, confidence) surface directly in the existing vulnerability report workflow.
• Manual Trigger: An option is available to manually trigger the analysis for individual vulnerabilities on the details page for on-demand assessment.

Learn more here.

Vulnerability resolution generally available on GitLab Duo Agent Platform

GitLab Duo's Agentic SAST Vulnerability Resolution is now generally available on the GitLab Duo Agent Platform.

This feature can be activated as part of your standard SAST scan, after the SAST false positive detection process, or manually for specific SAST vulnerabilities.

Key capabilities of Agentic SAST Vulnerability Resolution:

• Autonomous Analysis: Automatically examines the vulnerability finding and its surrounding code context.
• Automated Fix Generation: Creates a ready-to-review merge request with proposed code fixes specifically for critical and high severity SAST vulnerabilities.
• Quality Assessment: Provides quality assessments to help reviewers quickly judge the confidence level of the suggested remediation.
• Direct Application: Allows users to apply the resolutions directly from the vulnerability details pages.

Learn more here.

Dependency scanning SBOM-based scanning extended to self-managed

The new SBOM-based dependency scanning feature, initially released in GitLab 18.5 with limited availability for GitLab.com only, is now extending its limited availability status to self-managed instances in GitLab 18.10.

Key Changes and Improvements:

• Default-Enabled: The feature flag (dependency_scanning_sbom_scan_api) is now enabled by default, reflecting additional improvements and fixes that increase confidence in the new internal SBOM scanning API.
• Immediate Results: This new process significantly improves the workflow. The dependency scanning analyzer now uses the internal API to generate a dependency scanning report, containing all component vulnerabilities, immediately during the CI/CD job. This gives users instant access to vulnerability data for custom workflows, unlike the previous Beta behavior which processed SBOM reports only after the CI/CD pipeline finished.
• Fallback Option: Self-managed customers can disable the dependency_scanning_sbom_scan_api feature flag if they encounter issues. The analyzer will then revert to the previous behavior.

How to Use It:

To utilize this enhanced feature, customers must import the v2 dependency scanning template: Jobs/Dependency-Scanning.v2.gitlab-ci.yml.

Learn more here.

License scanning support for Dart/Flutter projects using Pub package manager

GitLab now offers license scanning for Dart and Flutter projects utilizing the pub package manager. This addresses a previous gap where teams using Dart/Flutter lacked the ability to identify the licenses of their open-source dependencies directly within GitLab. This capability is crucial for organizations with license policy requirements, as it eliminates compliance blind spots.

The license information is sourced straight from pub.dev, the official Dart package repository, and is displayed alongside results from other supported ecosystems. Note that dependency scanning and vulnerability detection for Dart/Flutter were already available. Learn more here.

Dependency Scanning with SBOM support for Java Gradle build files

GitLab's dependency scanning feature, which uses Software Bill of Materials (SBOM), now includes support for scanning Java build.gradle and build.gradle.kts build files.

Previously, running dependency scanning on Java projects using Gradle required a lock file. This is no longer a requirement. The analyzer now offers a manifest fallback mechanism: if a lock file is missing, it will automatically scan the build.gradle and build.gradle.kts files, extracting and reporting only direct dependencies for vulnerability analysis.

This enhancement simplifies the process for Java Gradle projects to enable dependency scanning, removing the prerequisite of a lock file.

To activate this manifest fallback, set the DS_ENABLE_MANIFEST_FALLBACK CI/CD variable to "true". Learn more here.

Pipeline secret detection in security configuration profiles

The Secret Detection - Default profile now offers comprehensive coverage for secret detection, extending to pipeline-based scanning for a unified security control surface across your entire development workflow.

This profile activates three key scan triggers:

• Push Protection: Scans all Git push events and automatically blocks pushes containing detected secrets, ensuring secrets never make it into your codebase.
• Merge Request Pipelines: Automatically runs a scan when new commits are pushed to a branch with an open merge request. The results are focused only on new vulnerabilities introduced by that merge request.
• Branch Pipelines (default only): Runs automatically upon changes merged or pushed to the default branch, giving you a complete and up-to-date view of the default branch's secret detection posture.

Implementation is simple, requiring no YAML configuration. The profile can be applied at the group level to propagate coverage to all projects within the group, or to individual projects for more specific, granular control. Learn more here.

SAST false positive detection with GitLab Duo Agent Platform

GitLab Duo Agent Platform now enhances security scanning by automatically analyzing each critical and high severity SAST vulnerability to determine the likelihood of it being a false positive. This assessment appears directly in the vulnerability report, providing teams with the necessary context for confident triaging.

Key Features of False Positive Detection:

• Automatic Operation: The detection runs automatically following every security scan, requiring no manual intervention.
• On-Demand Manual Analysis: Users retain the option to manually trigger false positive detection for individual vulnerabilities via the vulnerability details page.
• Targeted Focus: Analysis is concentrated only on critical and high severity SAST vulnerabilities, effectively cutting through lower-priority noise.
• Contextual AI Reasoning: Each assessment includes an explanation for the false positive determination, leveraging code context, data flow, and characteristics specific to static analysis.
• Seamless Integration: Results are presented directly within the existing vulnerability report, alongside severity, status, and remediation information, ensuring no disruption to current workflows.

Learn more here.

The Enterprise edition and higher now include enhanced regulatory coverage for crucial AI and Mobile security standards. This expansion incorporates security reports based on standards such as the OWASP Top 10 for Large Language Models (LLMs) and the OWASP Mobile Application Security Verification Standard (MASVS). Learn more here.

For users of SonarQube and JFrog with strict compliance needs, this new integration offers a single, verifiable audit trail. SonarQube analysis results are now automatically signed and attached directly to your JFrog packages, establishing a unified source of truth. This eliminates the need to switch between tools to demonstrate that your code meets security standards. All necessary information for a rigorous audit is conveniently accessible within the JFrog Evidence Collection interface. This functionality is included in the Enterprise edition and higher. Learn more here.

To avoid overly strict enforcement of small changes, the quality gate ignores coverage and duplication conditions for very small sets of new code. Learn more here.

This update transitions the platform to the latest version to provide immediate, deep support for the industry’s newest language standards and cloud architectures. By incorporating dedicated analysis for .NET 10 and C# 14, this version ensures your high-performance enterprise applications are analyzed with absolute accuracy from day one. You will benefit from significant improvements across several core languages, including COBOL and PHP, where refined parsing reduces false positives and focuses on critical logic errors. These enhancements mean your developers spend less time triaging results and more time writing clean code in their preferred environments. Furthermore, the strengthened Infrastructure as Code (IaC) analysis—covering Terraform, Kubernetes, and GitHub Actions—proactively secures your deployment pipelines against hard-coded credentials and insecure command configurations.

Key Language Updates:

• .NET 10 & C# 14: Immediate support for the latest LTS release with zero-day accuracy.

• Infrastructure as Code: Improved evaluation of Helm templates and new security rules for GitHub Actions.

• COBOL & VB6: Enhanced parsing and reliability for legacy systems, including specific fixes for line counts and unused data items.

• PHP & Scala: Streamlined dependency infrastructure and reduced false positives for unit testing and logic rules.

• Secret Detection: New rules protecting sensitive credentials, including xAI API keys and SMTP information.

• Refreshed Workspace: A vertical navigation sidebar replaces the top menu, providing faster access to Analysis, Reporting, and Policies.
• Next-Gen Language Support: Stay current with full analysis support for Java 25, PHP 8.5, and Python 3.14.
• Direct Repository Access: Navigate directly from your SonarQube project to your bound GitHub or GitLab repository via a new clickable header icon.
• Lightning-Fast Go Analysis: A brand-new engine for Go delivers up to a 30x speedup in processing times.

New in-code annotations offer a structured, auditable alternative to blindly suppressing issues with NOSONAR. This feature allows teams to manage deviations directly in the source code while maintaining visibility in SonarQube.

How it works:

• In-Code Resolution: Resolve specific rule violations by adding an annotation with a mandatory comment and status (accepted or fp for false-positive) directly in the code.
• Visibility and Auditability: Deviations remain visible in SonarQube's UI and are fully auditable, reducing the risk of accidentally hiding critical issues.
• Compliance: This structured approach helps teams comply with strict standards like MISRA C++:2023.

Key Capabilities:

• Set the resolution status (accept or fp) directly within the code.
• Administrative control is available via global and project-level settings.
• Supported Languages: C, C++, Objective-C.

Learn more here.

SonarQube enhanced the configuration for AI CodeFix to be model-agnostic. This improvement provides greater flexibility and allows for better suggestions when using AI-powered code fixing. This feature is available starting with the Enterprise edition. Learn more here.

Available as part of SonarQube Advanced Security license for Enterprise edition and higher. Learn more here.

SonarQube improved security reporting in SonarQube:

• Dependency Risk in Sonar Reports: Sonar security reports now integrate Software Composition Analysis (SCA) data directly. A new "Dependency risk" column is included in application and portfolio-level reports, visible in the SonarQube Server UI and exported PDFs.

For project regulatory compliance:

• Downloadable Regulatory Reports: