gitlabJul 16, 2026

GitLab 19.2 release notes | GitLab Docs (opens in new tab)

GitLab 19.2, released July 16, 2026, focuses heavily on AI-assisted development, workflow automation, and centralized security controls. Major additions include the generally available GitLab Duo CLI and custom flows, scheduled pipeline execution policies, and Agentic Chat integrations. Several security features remain in beta, including automated dependency remediation and vulnerability tracking on non-default branches. ## AI-Assisted Development - **GitLab Duo CLI is generally available** for Premium and Ultimate users across GitLab.com, Self-Managed, and Dedicated. - Provides interactive chat and headless CI/CD modes. - Understands GitLab projects, pipelines, and agent configurations. - Supports model selection, shared sessions, tool approvals, MCP connections, slash commands, skills, and `AGENTS.md`. - Can be installed through `glab` or as a standalone tool. - **Custom flows are generally available** across all tiers. - Define reusable, YAML-based workflows for complex multi-step tasks. - Support multi-agent orchestration and human approval checkpoints. - Trigger from mentions, assignments, pipelines, and merge request events. - Offer project or AI Catalog management, visibility controls, secure service-account execution, and YAML validation. - **Foundational flows can now start from Agentic Chat.** - Developer Flow can implement changes or open merge requests. - Code Review Flow can review merge requests. - Fix CI/CD Pipeline Flow can diagnose and repair failed pipelines. - Users approve the handoff and monitor progress in chat or under AI sessions. ## Centralized Pipeline Automation - **Scheduled pipeline execution policies are generally available for Ultimate.** - Define schedules centrally in a security policy project. - Apply them across projects without modifying each project’s `.gitlab-ci.yml`. - Run compliance scripts, security scans, and other jobs independently of commit activity. - Support daily, weekly, or monthly schedules, time zones, time windows, and branch targeting. - Each policy creates a separate pipeline. ## Dependency and Vulnerability Management - **Dependency scanning auto-remediation is in beta.** - Automatically opens merge requests for vulnerable dependency upgrades. - Defaults to patch and minor version updates. - Agentic Breaking Change Resolution can address failed pipelines caused by complex or major upgrades. - GitLab Duo analyzes errors, changelogs, and code usage, commits fixes to the same merge request, and reruns the pipeline. - The feature creates an end-to-end remediation loop, from vulnerability detection through upgrade and repair. - **Non-default branch vulnerability tracking is in beta.** - Supports long-lived branches such as `project-qa`, `project-prod`, `project-iOS`, and `project-android`. - Allows branch-specific filtering in vulnerability reports and dashboards. - Tracks all vulnerability types, including CVEs. - Preserves vulnerability metadata when branches merge into the default branch. - Allows up to twice as many tracked branches as projects in the namespace. ## Governance and Administration - **Selective GitLab Duo availability is available for GitLab Dedicated and Dedicated for Government.** - Administrators can lock selected subgroups and descendants into an “Always off” state. - Other subgroups can retain the option to enable Duo according to their permissions. - The model provides a per-subgroup allowlist rather than disabling AI for the entire instance. - Owners receive clear messaging when a parent group has disabled the features. ## Contributor Recognition - GitLab recognized **vivekshukl007** as the month’s Notable Contributor. - Their contribution added Scala language support to GitLab Orbit, improving code graph capabilities for Scala projects. GitLab 19.2 is especially valuable for teams adopting AI-driven development and centralized security automation. Organizations should evaluate Duo CLI and custom flows for productivity gains, while testing the dependency remediation and non-default branch features carefully because they remain in beta.

vulnerability-managementgitlabmodel-context-protocolyaml+4

gitlabJun 18, 2026

One vulnerability view: From scanner coverage to AI governance (opens in new tab)

GitLab 19.1 presents a unified approach to application security and AI governance. It lets organizations enforce third-party SARIF-compatible scanners across every project, centralize findings, and automate remediation. At the same time, new AI governance features record agent activity and require approval for sensitive actions, enabling faster development without sacrificing accountability. ## Enforcing Complete Scanner Coverage - Security scanners are often configured separately for each project, creating coverage gaps and policy drift. - GitLab 19.1 allows administrators to enforce third-party scanners across all projects. - SARIF-compatible scanner results flow into GitLab’s unified vulnerability view. - Findings use the same governance and remediation workflows as GitLab-native results. - GitLab Duo Agent Platform can: - Triage findings with SAST False Positive Detection. - Generate merge requests through Agentic SAST Vulnerability Resolution. - Automatically remediate third-party scanner findings before production. ## Improving Secret Detection - Secret detection now scans every commit on a newly created branch, rather than only the latest commit. - This helps identify credentials introduced in earlier commits. - Secret False Positive Detection, now generally available, provides: - A confidence score for each finding. - An explanation displayed in the vulnerability report. - Developers can focus on genuine exposures instead of test credentials, placeholders, and example tokens. ## Governing AI Agent Actions - AI coding agents can create merge requests, invoke tools, commit code, and modify projects. - GitLab’s AI audit event streaming beta records every agent action and sends it to existing audit log destinations. - Agent tool approval guardrails let administrators configure each tool to: - Run automatically. - Require human approval. - Remain blocked. - Sensitive operations, such as writing files or deleting resources, can therefore require explicit review. - Approval decisions are also recorded, creating an auditable history for incident response and compliance. ## Governed Autonomy GitLab’s overall goal is to combine autonomous development with enforceable controls. Organizations can prove scanner coverage, automate vulnerability remediation, restrict risky agent behavior, and review a complete audit trail of what agents did. The practical recommendation is to centralize scanner governance and configure approval requirements for high-impact AI actions, allowing agents to work quickly while keeping security and accountability under human control.

vulnerability-managementgitlabdevsecopssast+4

gitlabMay 26, 2026

Reduce supply chain risk with SBOM-based dependency scanning (opens in new tab)

SBOM-based dependency scanning in GitLab 19.0 addresses the limits of traditional scanners that focus only on declared packages and known CVEs. It inventories direct and transitive dependencies, traces how vulnerable packages entered a project, and identifies whether application code actually reaches them. The result is more targeted remediation and easier organization-wide enforcement of supply chain security. ## Why Traditional Dependency Scanning Falls Short - Modern applications rely heavily on third-party and deeply nested dependencies. - Supply chain compromises can affect every project that depends on a vulnerable package. - AI-generated code further increases risk, with research indicating that nearly half contains vulnerabilities. - Teams need to know not only which packages are vulnerable, but also: - How they entered the project - What dependencies they brought with them - Whether the application actually uses them ## How SBOM-Based Scanning Works - The analyzer inventories dependencies in a CycloneDX-format software bill of materials. - Components are matched against the GitLab Advisory Database to identify known vulnerabilities. - Findings appear in: - Merge requests, so developers can address issues before release - Vulnerability dashboards and reports, for centralized security oversight - GitLab produces both an SBOM and a dependency scanning report for compliance and supply chain tooling. ## Tracing and Prioritizing Vulnerabilities - The analyzer follows transitive dependency chains regardless of nesting depth. - Teams can see the path a vulnerable package took into the project—for example, `library-a` → `library-b` → `library-c`. - For Java, JavaScript/TypeScript, and Python, GitLab checks whether vulnerable packages are directly imported or required. - Findings include reachability status, helping teams prioritize vulnerabilities their code can plausibly execute. - Scans can run on merge requests, pipeline executions, and when new advisories are published, including for production systems with little ongoing development. ## Supported Ecosystems and Input Files - The release supports more than 24 package ecosystems, with additional support planned. - Lockfiles and dependency graphs are preferred because they provide complete transitive dependency information. - If those are unavailable, the analyzer can parse manifests such as: - `pom.xml` - `requirements.txt` - Gradle build files - Manifest scanning identifies direct dependencies but offers less complete coverage because transitive dependencies may be missing. ## Centralized Configuration and Enforcement - GitLab 19.0 provides a security configuration profile for applying dependency scanning across many projects. - Security and platform teams can configure scanning once instead of maintaining individual pipeline files. - Scan execution policies and pipeline execution policies can enforce requirements at the group or instance level without modifying `.gitlab-ci.yml` files. - Centralized policies reduce configuration drift, skipped projects, and audit gaps. ## Availability and Migration - SBOM-based dependency scanning is available to GitLab Ultimate customers on GitLab.com and is rolling out to Dedicated and self-managed installations. - Teams migrating from Gemnasium can run both analyzers in parallel and compare their results. - GitLab provides setup instructions, migration guidance, and documentation for supported languages and advanced configuration. Teams should prefer lockfile-based SBOM scanning, enable it centrally through security policies, and prioritize remediation based on dependency reachability rather than vulnerability presence alone.

vulnerability-managementgitlabdevsecopsdependency-scanning+4

gitlabMay 13, 2026

5 ways to fix misleading vulnerability severities with policy (opens in new tab)

CVSS scores describe a vulnerability’s general characteristics, not its actual risk in a specific environment. GitLab severity override policies let teams automatically adjust findings based on CVE, CWE, file path, or directory, reducing manual triage. The result is a vulnerability report that better reflects deployment context, exploitability, and organizational priorities. ## How Severity Override Policies Work - Policies run automatically on every default-branch pipeline. - Rules match findings by: - CVE identifier - CWE identifier - File path - Directory - Available actions: - **Set Severity** to informational, low, medium, high, or critical - **Increase Severity** by one level - **Decrease Severity** by one level - Manual overrides by authorized users take precedence. - GitLab records automated changes in vulnerability history and audit events. ## Downgrading Low-Risk CVEs in Internal Services - Internal tools and services may have substantially lower exposure than public-facing applications. - A policy can reduce the severity of selected CVEs found under paths such as `internal/**/*`. - The `decrease` operation lowers severity by one level—for example, Critical to High or High to Medium. - Teams should replace the example CVEs with vulnerabilities they have assessed as less risky in internal deployments. ## Upgrading Injection Vulnerabilities in Production Code - XSS (`CWE-79`) and SQL injection (`CWE-89`) are frequently exploited vulnerability classes. - Findings involving these CWEs under `src/**/*` can be forced to **Critical**. - Combining this override with a merge request approval policy can require security-team review before affected code reaches production. ## Normalizing Severity Across Scanners - SAST, dependency, and container scanners may assign different severities to the same CVE. - A policy can set specific vulnerabilities—such as Log4Shell-related CVEs—to a consistent baseline, such as High. - This produces more predictable triage and approval thresholds across scanning tools. ## Incorporating Exploitation Intelligence - CVSS is largely static and does not reflect changes in real-world exploitation. - EPSS and CISA’s Known Exploited Vulnerabilities catalog provide signals about exploitation likelihood and active attacks. - Teams can explicitly upgrade CVEs identified as actively exploited or highly likely to be exploited, treating them as Critical regardless of their original scanner rating. GitLab severity overrides are most useful when they encode a documented risk model: deployment exposure, vulnerability type, scanner consistency, and current threat intelligence. They should complement—not replace—manual review, auditability, and merge request approval controls.

vulnerability-managementgitlabyamlsast+4

gitlabApr 22, 2026

GitLab Patch Release: 18.11.1, 18.10.4, 18.9.6 | GitLab Docs (opens in new tab)

GitLab released patch versions 18.11.1, 18.10.4, and 18.9.6 on April 22, 2026, addressing multiple security vulnerabilities and bugs in CE and EE. Self-managed installations should upgrade immediately, while GitLab.com is already patched and GitLab Dedicated customers need no action. The fixes include unauthenticated GraphQL and browser-based attacks, several denial-of-service flaws, and access-control weaknesses. ## Release Scope and Upgrade Guidance - Applies to GitLab Community Edition and Enterprise Edition. - Affects all deployment types unless otherwise specified, including Omnibus, source installations, and Helm charts. - Recommended fixed versions: - 18.11.1 - 18.10.4 - 18.9.6 - GitLab issues detailing security vulnerabilities are made public 30 days after the relevant patch release. - GitLab publishes both scheduled patch releases, issued on the second and fourth Wednesdays, and ad-hoc critical patches for high-severity vulnerabilities. ## High-Severity Vulnerabilities - **CVE-2026-4922 — GraphQL CSRF** - CVSS 8.1. - An unauthenticated attacker could execute GraphQL mutations on behalf of an authenticated user because of insufficient CSRF protection. - Affects versions before 18.9.6, 18.10.4, and 18.11.1. - **CVE-2026-5816 — Web IDE path validation** - CVSS 8.0. - Under certain conditions, improper path validation could allow unauthenticated attackers to execute arbitrary JavaScript in a user’s browser session. - Affects the 18.10 and 18.11 release lines before the listed patches. - **CVE-2026-5262 — Storybook cross-site scripting** - CVSS 8.0. - Improper input validation could allow unauthenticated access to tokens in the Storybook development environment. - Affects versions from 16.1 through the unpatched 18.9, 18.10, and 18.11 releases. ## Denial-of-Service Fixes - **CVE-2025-0186:** Crafted requests to the discussions endpoint could exhaust server resources. - **CVE-2026-1660:** Improper input validation during Jira issue imports could enable resource exhaustion. - **CVE-2025-6016:** Insufficient limits when retrieving notes could cause service disruption. - **CVE-2025-3922:** Resource-allocation weaknesses in the GraphQL API could allow authenticated users to overwhelm the system. - Each issue carries a CVSS score of 6.5 and generally requires authentication. ## Access-Control and Session Fixes - **CVE-2026-6515 — Virtual registry credentials** - CVSS 5.4. - Invalidated or incorrectly scoped credentials could continue accessing Virtual Registries. - **CVE-2026-5377 — Confidential issue titles** - CVSS 4.3. - Authenticated users could potentially view titles of confidential or private issues in public projects. - **CVE-2026-3254 — Mermaid sandbox** - CVSS 3.5. - Improper validation could allow authenticated users to load unauthorized content into another user’s browser. - The release also lists **CVE-2025-9957**, involving improper access control in the project fork relationship API; the provided text does not include its full impact or severity details. Self-managed GitLab administrators should apply the appropriate patch release as soon as possible, especially because several vulnerabilities permit unauthenticated browser or API attacks.

vulnerability-managementgitlabgraphqlcross-site-scripting+4

gitlabApr 20, 2026

Prepare your pipeline for AI-discovered zero-days (opens in new tab)

AI is accelerating both vulnerability discovery and insecure code production, shrinking the time defenders have to respond from months to hours. The post argues that security teams cannot remain the final defense layer; security controls, automated triage, and remediation must operate directly within development pipelines. AI-generated fixes can help close the gap, but they must follow the same policies, approvals, testing, and audit requirements as human-authored code. ## The Remediation Backlog Is Already Too Large - Most exploited vulnerabilities are already known and have patches available, but organizations cannot remediate them quickly enough. - Sixty percent of breaches in the 2025 Verizon DBIR involved known vulnerabilities. - Developers spend roughly 11 hours per month fixing vulnerabilities after release. - The median time to close half of internet-facing vulnerabilities is 361 days, while exploitation can begin within hours. - AI-assisted development is increasing the volume of insecure code: - Fortune 50 repositories reportedly gained more than 10,000 security findings per month by mid-2025. - AI coding tools may introduce outdated patterns, hallucinated packages, insecure examples, and excessive dependencies. - Security AI should therefore operate within existing development policies and audit trails rather than as a disconnected tool. ## Security Enforcement Must Move Into the Pipeline - Every change should pass security controls at the merge request, which becomes the central enforcement point. - Policies should be defined once and applied consistently across teams and projects. - Exceptions should be explicitly approved and logged. - IDE checks can catch straightforward problems—such as hardcoded secrets, vulnerable imports, and deprecated APIs—before code reaches review. - This allows human reviewers to focus on complex issues such as reachability, exploitability, and architectural risk. ## Automated Triage and Governed Remediation - AI should reduce the volume of findings developers must investigate by assessing: - False positives - Reachability - Exploitability - Severity - AI-generated fixes should not bypass normal governance. - Remediation proposals should be submitted as merge requests, with: - Required scans - Policy enforcement - Human approvals - Confidence scores - Complete audit records - Human and AI-authored changes should follow the same review and compliance process. ## Example: Responding to an Emerging Vulnerability - A proof-of-concept exploit may appear before a CVE, NVD entry, or scanner signature exists. - A security agent can inspect dependency graphs across projects, identify affected versions and call paths, and rank production exposure. - Teams can then launch a coordinated remediation campaign: - Upgrade dependencies where patches exist. - Apply targeted code changes where they do not. - Block merge requests that retain the vulnerable dependency. - Require security approval for fixes. - Pipeline tests can reject faulty AI-generated patches, allowing the agent to revise them before developers approve the corrected version. - Automatically collected scan results, policies, approvals, and merge timestamps provide audit evidence without manual reconstruction. ## Strengthen the Pipeline Before Attackers Catch Up - Organizations should verify that security scans run on every merge request, not only in selected projects. - Pipelines should detect compromised or vulnerable dependencies before build time. - Critical findings should move quickly from detection to the responsible developer without unnecessary tool boundaries. - The central recommendation is to make pipeline enforcement, AI-assisted triage, and governed remediation standard parts of the software supply chain before comparable offensive AI capabilities become widely available.

vulnerability-managementdatabase-designdevsecopsai-ml+4

gitlabMar 25, 2026

Manage vulnerability noise at scale with auto-dismiss policies (opens in new tab)

GitLab’s auto-dismiss vulnerability policies reduce scanner noise by automatically dismissing findings that teams have already determined are irrelevant, non-actionable, or mitigated. Policies match vulnerabilities by file path, directory, or identifier such as a CVE or CWE, while preserving dismissed findings and their audit history. This lets security teams focus on genuine risks without repeatedly performing the same manual triage. ## Why Auto-Dismiss Policies Matter - Security scanners often flag: - Test code and fixtures - Vendored or third-party dependencies - Generated files - Known false positives - Vulnerabilities addressed by existing controls - Manual dismissal creates: - Slower triage - Alert fatigue - Developer friction - Repeated work across projects and pipelines - Auto-dismiss policies allow teams to: - Apply triage decisions consistently at scale - Record a specific dismissal reason - Link findings back to the policy that dismissed them - Keep dismissed vulnerabilities visible for future review ## How Policies Work - Policies are defined in a vulnerability management policy YAML file. - Rules can match: - File paths - Directories - Vulnerability identifiers, including CVEs and CWEs - Teams create the policy through **Secure > Policies > New policy > Vulnerability management policy**. - After the merge request is merged, matching findings on default-branch pipelines are automatically marked **Dismissed**. - GitLab processes up to 1,000 vulnerabilities per pipeline run. - Teams can filter reports by **Dismissed** to evaluate policy impact and verify that the correct findings were handled. ## Dismissing Test Code Findings Test directories commonly contain intentionally insecure credentials, fixtures, or development-only dependencies that do not represent production risk. - Policies can target paths such as: - `test/**/*` - `tests/**/*` - `spec/**/*` - `__tests__/*` - The recommended dismissal reason is `used_in_tests`. ## Dismissing Vendored Dependencies Code in `vendor/`, `third_party/`, `vendored/`, or checked-in `node_modules` is often maintained upstream rather than by the application team. - Directory-based rules can identify these locations. - The example policy uses the `not_applicable` dismissal reason. - Teams should customize the directory patterns to match their repository structure. ## Dismissing Known False-Positive CVEs Repeatedly flagged CVEs that have been confirmed not to apply to an organization’s environment can be dismissed centrally. - Rules match specific identifiers, such as: - `CVE-2023-44487` - `CVE-2024-29041` - `CVE-2023-26136` - The sample policy uses `false_positive`. - The listed CVEs are examples and should be replaced with identifiers validated by the organization. ## Dismissing Generated Code Generated files from Protobuf, gRPC, OpenAPI, ORM, and similar tools may contain patterns scanners flag even though developers do not author or directly patch them. - Example matches include: - `generated/*` - `**/*.pb.go` - `**/*.generated.*` - The suggested dismissal reason is `not_applicable`. ## Dismissing Infrastructure-Mitigated Vulnerabilities Some vulnerabilities may be addressed by enforced runtime controls, such as WAF rules. - The example targets: - `CWE-79` for cross-site scripting - `CWE-89` for SQL injection - It uses the `mitigating_control` dismissal reason. - This approach should only be used when the mitigation is verified, consistently deployed, and reliably protects all affected paths. ## Practical Recommendation Use auto-dismiss policies for well-understood, documented cases—not as a substitute for vulnerability investigation. Start with narrowly scoped path or identifier rules, review the dismissed results regularly, and ensure every dismissal reason reflects a decision that remains valid.

vulnerability-managementgitlabdevsecopsyaml+3

gitlabMar 19, 2026

GitLab 18.10 brings AI-native triage and remediation (opens in new tab)

GitLab 18.10 adds AI-powered security features designed to reduce vulnerability triage noise and speed remediation. GitLab Duo Agent Platform can assess whether SAST and secret-detection findings are likely false positives, explain its reasoning, and— for verified SAST issues—generate tested fixes in merge requests. These capabilities are available to GitLab Ultimate customers using the Duo Agent Platform, with some features still in beta. ## SAST False Positive Detection - Generally available for new critical and high-severity SAST findings. - Uses LLM-based agentic reasoning to assess whether a vulnerability is likely real or a false positive. - Adds: - A confidence score - An AI-generated explanation - A “Likely false positive” or “Likely real” badge - Findings can be filtered in the Vulnerability Report so teams can prioritize likely real vulnerabilities. - The assessment remains a recommendation that teams can review and audit. ## Agentic SAST Vulnerability Resolution - Currently in beta. - For findings judged unlikely to be false positives, the agent: - Reads the vulnerable code and its surrounding context - Generates a proposed fix - Validates the fix with automated tests - Opens a merge request for developer review - The merge request includes code changes, a confidence score, and an explanation of the remediation. - Developers should still carefully review AI-generated changes before merging. ## Secret False Positive Detection - Currently in beta. - Identifies likely test credentials, placeholder values, example tokens, and other dummy secrets. - Provides confidence scores, explanations, and visual badges in the Vulnerability Report. - Runs automatically on the default branch and can also be triggered manually with “Check for false positive.” - The goal is to help teams focus on exposed credentials that represent genuine risk. GitLab 18.10 extends AI assistance across the vulnerability lifecycle: filtering out misleading findings, explaining security assessments, and proposing validated code fixes. Teams using GitLab Ultimate and Duo Agent Platform can use these features to reduce review effort while retaining human control over security decisions and merges.

vulnerability-managementgitlabsastmerge-requests+4

gitlabFeb 19, 2026

Track vulnerability remediation with the updated GitLab Security Dashboard (opens in new tab)

The updated GitLab Security Dashboard addresses the challenge of vulnerability overload by shifting the focus from simple detection to contextual remediation and risk management. By providing integrated trend tracking and sophisticated risk scoring, the platform enables security and development teams to prioritize high-risk projects and measure the actual progress of their security programs. This update transforms raw security data into actionable insights that are tracked directly within the existing DevSecOps workflow. ## Transitioning from Detection to Remediation Context * Consolidates vulnerability data into a single view that spans across projects, groups, and entire business units to eliminate data silos. * Introduced initial time-based tracking in version 18.6, with version 18.9 adding expanded filters for severity, status, scanner type, and project. * Provides visualizations for remediation velocity and vulnerability age distribution, moving beyond static raw counts to show how quickly threats are being addressed. ## Data-Driven Prioritization with Risk Scoring * Utilizes a dynamic risk score calculated from multiple factors, including vulnerability age and repository security postures. * Integrates external threat intelligence such as the Exploit Prediction Scoring System (EPSS) and Known Exploited Vulnerability (KEV) scores to identify the most critical threats. * Allows teams to monitor risk scores over time to pinpoint specific areas of the infrastructure that require additional resources or immediate intervention. ## Strategic Impact for Security and Development Teams * Enables security leaders to prove program effectiveness to executives by showing downward trends in Common Weakness Enumeration (CWE) types and shrinking backlogs. * Streamlines the developer experience by highlighting critical vulnerabilities within active projects, removing the need for external spreadsheets or manual reporting tools. * Identifies specific teams or departments that may require additional remediation training based on their ability to meet company security policies. Organizations should leverage these updated dashboard features to transition from manual, reactive security tracking to an automated, risk-based posture. By integrating EPSS and KEV data into daily workflows, teams can ensure they are solving the most dangerous vulnerabilities first while maintaining a clear, measurable record of their security improvements.

vulnerability-managementgitlabdevsecopsdata-visualization+3

gitlabJan 14, 2026

Getting started with GitLab Duo Agentic Chat (opens in new tab)

GitLab Duo Agentic Chat marks a shift from traditional Q&A chatbots to autonomous AI collaboration partners integrated directly into the software development lifecycle. By leveraging specialized agents and context-aware large language models, the platform enables developers to automate complex tasks like code refactoring, security remediation, and issue triaging. This system serves as a centralized interface across both the GitLab Web UI and IDEs to streamline workflows from initial planning to production deployment. ## Capabilities of Agentic AI * **Autonomous Actions:** The system can move beyond simple chat by creating files, modifying existing code, and opening merge requests on behalf of the user. * **Deep Context Integration:** Agents have access to the full GitLab ecosystem, including issues, epics, Git commits, CI/CD pipelines, and security scans. * **Extensibility:** Through the Model Context Protocol (MCP), the chat can integrate with external services to expand its functional scope. * **Information Retrieval:** Users can query project architecture or use GitLab Query Language (GLQL) to pull specific project analytics and insights. ## Model and Agent Customization * **Flexible Model Selection:** Users and administrators can choose from different LLMs based on task requirements, with configuration available at both the group and individual user levels. * **Specialized Agents:** The platform features dedicated agents for specific roles, such as the **Planner Agent** for product management and the **Security Analyst Agent** for vulnerability management. * **Contextual Switching:** In IDEs, users can switch between agents via a dropdown menu, while the Web UI allows for agent selection when starting new chat sessions. ## Specialized Workflow Use Cases * **Project Planning:** The Planner Agent can break down epics into smaller tasks, list high-priority bugs, and generate technical requirements for new features. * **Security Remediation:** Security-focused agents can explain vulnerabilities in simple terms, identify false positives in scans, and suggest specific code fixes for SQL injection or XSS risks. * **Troubleshooting and Debugging:** The system can analyze CI/CD pipeline logs to identify why a build failed and suggest optimizations for job performance. * **Legacy Modernization:** Specific prompts can guide the AI to refactor code to follow SOLID principles or create migration plans for modernizing legacy languages like COBOL to Java or Python. ## Access and Integration * **Interface Options:** The chat is accessible via a collapsible sidebar in the Web UI and through dedicated plugins in popular IDEs. * **Future Development:** While currently limited to UI and IDE interfaces, a GitLab Duo CLI is in development to bring agentic capabilities to the terminal. To get the most out of GitLab Duo Agentic Chat, it is recommended to transition between specialized agents as you move through different project phases. Using the Security Analyst for code reviews and the Planner for backlog grooming ensures that the underlying models are optimized for the specific metadata and constraints of those tasks.

vulnerability-managementdatabase-designai-agentgitlab+4