Multiple matches per file in code search

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.

View downstream pipeline job logs in VS Code

View downstream pipeline job logs in VS Code

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!

DAST detection parity with secret detection default rules

DAST detection parity with secret detection default rules

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.

Variable precedence controls in pipeline execution policies

Variable precedence controls in pipeline execution policies

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.

Filter for bot and human users

Filter for bot and human users

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

Pagination for requirements in compliance frameworks UI

Pagination for requirements in compliance frameworks UI

When creating a compliance framework, you can specify up to 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.

Epic support for GitLab Query Language views Beta

Epic support for GitLab Query Language views Beta

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.

GitLab Runner 18.1

GitLab Runner 18.1

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.

PHP support for Advanced SAST

PHP support for Advanced 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.

Define a ‘Name’ for external custom controls

Define a ‘Name’ for external custom controls

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.

Increased SAST coverage for Duo Vulnerability Resolution

Increased SAST coverage for Duo Vulnerability Resolution

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.

New accessLevels argument for projectMembers in GraphQL API

New accessLevels argument for projectMembers in GraphQL API

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 permissions structures.