What's new

Enterprises want to use their own model subscriptions to power Duo Agent Platform features, for cost control, data residency, or existing contract leverage. BYOK Iteration 1 connects customer-owned providers through token-based authentication via GitLab AI Gateway. We’re working to add:

Security teams spend significant time triaging secret detection findings that turn out to be test credentials or dummy values. AI-powered false positive detection analyzes findings before developers see them, identifying test credentials, example values, and placeholder secrets with clear explanations and confidence scores. This detection is separate from SAST false positive detection. This capability is being built to:

GitLab Duo Chat (Agentic) will support file uploads and web content as first-class context, so agents can reason over documentation, logs, specs, and other artifacts alongside repository data. This expansion is intended to:

When the same vulnerability pattern appears across a codebase, creating individual merge requests for each instance creates review fatigue and slows remediation. Building on the per-vulnerability SAST resolution flow, this extension will intelligently group related findings by shared root causes and generate consolidated merge requests. We’re planning to include:

Today, GitLab only tracks vulnerabilities on the default branch, meaning organizations releasing from long-lived branches have zero visibility into security posture for code running in production. Non-default branch tracking is a top Security Insights request and a documented adoption blocker. Here’s what we are working on:

The business-context security attributes introduced earlier need to be filterable on the Security Dashboard itself. Security managers will be able to filter dashboards by business impact, application, business unit, and more. We are planning to:

CI/CD inputs exist today for pipeline-level configuration, but developers still cannot set parameters for individual manual jobs within pipelines, forcing expensive full pipeline re-runs for simple parameter changes. Job-level inputs will bring dynamic parameter setting to manual jobs when parameters change during execution. This capability is being built to:

Extending non-default branch tracking to the Security Dashboard and SBOM means vulnerability trends, dependency lists, and SBOM exports all become branch-aware. This extension is intended for:

CVSS severity alone does not tell you whether a vulnerability is actively exploited or likely to be. Adding Known Exploited Vulnerabilities (KEV) and Exploit Prediction Scoring System (EPSS) as filter criteria in MR approval policies shifts enforcement from theoretical severity to real-world exploitability. This filter is being created to:

One of GitLab's most requested features and a documented blocker for organizations migrating. Epics are currently group-level only, forcing teams to create unnecessary subgroups or misuse milestones. Project-level Epics are being enhanced to:

GitLab wants to bring automated CODEOWNERS assignments to address manual steps for each MR by reducing bottlenecks for developers and lowering risk with review selection. This feature is being made to:

Many teams hesitate to adopt work item features (custom statuses, custom fields, work item types) that are only available through GraphQL. The REST API removes this adoption blocker for integrations, automation scripts, and tools that rely on REST. This API is being created to:

Wiki discussions happen away from relevant content, reducing effectiveness and increasing context switching. Inline contextual commenting will tie threaded discussions directly to highlighted text, keeping conversations connected to the content they reference. We're working on:

Maven graduates to GA while npm enters beta, covering the two highest-volume enterprise artifact ecosystems. Docker Virtual Registry also targets GA in this timeframe. By mid-year, GitLab will have virtual registries at GA for Maven, Docker, and npm. These registries are being made to:

DORA metrics (deployment frequency, lead time for changes, change failure rate, time to restore service) are the industry standard for measuring software delivery performance. Complete maturity for the API means full feature parity for programmatic consumption. This milestone is meant to include:

The security attributes story that started on the Security Dashboard reaches the vulnerability report. Teams will be able to filter vulnerabilities by application, business unit, or team directly on the report, bookmark filtered URLs, and share filtered views. This filter is being developed for:

Expanding from lower severity vulnerabilities, auto-remediation will support configurable severity levels and version targets. We are working on:

SAST remains foundational to application security, but CI/CD configuration requirements create adoption barriers. The SAST scan profile will let security managers deploy static analysis across projects through Security Inventory, with automatic language detection and Advanced SAST for supported languages on Ultimate. This profile is designed to:

Security managers need to deploy secret push protection at scale without manual project-by-project configuration. Scan configuration profiles will introduce bulk enablement through Security Inventory, protecting projects without requiring YAML changes or developer intervention. This profile is being created to:

While secret push protection blocks commits in real-time, pipeline scanning provides complementary coverage by detecting secrets in repository history and pipeline artifacts. This profile will let security managers apply broad secret detection using the same profile-based approach, creating defense-in-depth without configuration overhead. We are building this profile to:

Completing the scan configuration profiles family, the dependency scanning profile will let security teams apply dependency scanning across projects without requiring developers to edit CI configs. We are working to create this profile for:

Organizations with proprietary credential formats need the ability to define their own secret patterns beyond GitLab's built-in rules. Custom rules will let security teams add organization-specific patterns that are automatically enforced during secret detection. This capability is being designed to:

Default vulnerability severities don't always reflect organizational risk priorities. Security teams will be able to automate severity overrides based on rules including KEV/EPSS, CVSS, reachability, CVE, CWE, and scan type, mapping risk to business needs while automating triage processes that previously required manual intervention. This policy is meant to:

Security teams currently need Developer or Maintainer access to use vulnerability management features, granting far more permissions than necessary. The Security Manager role inherits from Reporter and adds security-specific permissions. This role is being made to help:

Dart and Flutter license information currently displays as UNKNOWN, forcing teams to use external tools for license compliance. License scanning support for the pub package manager fills this gap for the growing Flutter ecosystem. We’re working on:

Pattern-based secret detection misses generic passwords like admin_password=Password123! that lack recognizable formats. Context-aware detection identifies generic passwords by analyzing surrounding code patterns and variable naming conventions, extending current secret detection coverage. Currently in the pipeline is:

Supply chain attacks through malicious packages pose immediate risk: unlike CVEs that may exist dormant for months, a malicious package causes harm the moment it is ingested. GitLab is exploring surfacing malicious packages directly in dependency scanning results to help teams identify and respond to active threats. We're exploring:

Advanced SAST analysis in large repositories can exceed pipeline job time limits. Incremental scanning will cache results from previous scans and only analyze changed code, significantly reducing scan time while producing accurate results. This is a separate performance initiative from Advanced SAST's backwards slicing work. This optimization is meant to:

Security dashboards need exportable formats for stakeholder communication and compliance documentation. PDF export will replicate dashboard panels with applied filters and group-by configurations for offline sharing and archival. This export is being created to:

Organizations need to prove the provenance and integrity of their artifacts across the supply chain. Attestation APIs, UI integration, and GitLab CLI (glab) commands for verification will validate artifacts, while container image signing and verification extends this to the container ecosystem. We are working to:

Broad PAT scopes like read_api and api create excessive blast radius if tokens are compromised. Fine-grained permissions will scope tokens to specific resources and operations, restricted to specific projects and groups. We are working on:

Teams using CI variables for secrets lack proper lifecycle management, rotation reminders, and granular access control. GitLab Secrets Manager will provide purpose-built secrets storage with expiration management, environment/branch scoping, and role-based permissions. This manager is being expanded to:

The security attributes introduced for tagging and filtering will extend into the policy engine. Security teams will be able to write policies that reference custom security attributes for fine-grained governance rules. Here’s what we are working on:

Security teams will be able to enforce scheduled scans (nightly DAST, weekly dependency scanning) via policy, ensuring continuous compliance without developer action. This policy is intended to: