This becomes even more important as testing scales across automated pipelines, where execution data is spread across tools and harder to track in one place.

For organizations using GitLab for CI/CD and SmartBear QMetry for test management, manually uploading test results creates friction, delays feedback loops, and makes it harder to maintain a reliable, centralized view of testing.

What if you could automatically publish your JUnit, TestNG, or other test results directly from your GitLab pipeline to QMetry with just a few lines of configuration?

That's exactly what the new QMetry GitLab Component enables. This reusable CI/CD component, now available in the GitLab CI/CD Catalog, eliminates the manual overhead of test result management by automatically uploading test execution data to QMetry. This is an AI-enabled, enterprise-grade test management platform that brings together test planning, execution, tracking, and reporting in one place.

As a centralized system of record for testing, QMetry helps teams understand coverage, track execution, and make more reliable release decisions.

In this guide, you'll learn:

• How to set up the QMetry GitLab Component in your pipeline
• How to configure automated test result uploads
• Advanced configuration options for enterprise requirements
• A real-world aerospace industry use case
• Best practices for test management automation

By the end of this article, your GitLab pipelines will automatically feed test results into QMetry, giving your QA teams instant visibility into test execution and helping them make faster, more confident release decisions.

Why integrate GitLab with QMetry?

Before diving into the technical implementation, let's understand the value this integration delivers:

Eliminate manual test result uploads

DevSecOps engineers and QA teams no longer need to manually export test results from CI/CD runs and import them into test management systems. The component handles this automatically after every pipeline execution.

This reduces manual effort while ensuring test data stays consistent, up to date, and easy to access across teams.

Enable end-to-end traceability

By connecting GitLab's CI/CD execution data with QMetry's test management capabilities, teams gain complete traceability from requirements through test cases to actual test execution results. This is critical for regulated industries like financial services, aerospace, medical devices, and automotive, where audit trails are mandatory and regulatory compliance depends on demonstrating complete test coverage.

It also gives teams a clearer view of coverage and risk across releases, making it easier to understand what’s been tested and what still needs attention.

Accelerate feedback loops

Automated test result uploads mean QA teams, product managers, and stakeholders see test execution results immediately after pipeline completion – no waiting for manual data entry or report generation.

With faster access to results, teams can act immediately, reduce delays, and make quicker, more informed release decisions.

Support compliance and audit requirements

For organizations in regulated industries, maintaining comprehensive test records with proper versioning and traceability is non-negotiable. This integration ensures you can document every test execution properly in QMetry with links back to the specific GitLab pipeline, commit, and build.

This creates an audit-ready record of testing activity without adding manual overhead.

Leverage AI-powered test insights

QMetry uses AI to analyze test execution patterns, identify flaky tests, predict test failures, and recommend optimization opportunities. Feeding it real-time data from GitLab pipelines maximizes the value of these AI capabilities.

With continuous data flowing in, teams get more accurate insights and can focus their efforts where it matters most.

About the GitLab and SmartBear partnership

This component represents a growing partnership between GitLab and SmartBear to better connect CI/CD execution with test management in a single workflow. SmartBear brings deep expertise in testing, API management, and quality automation, while GitLab provides the most comprehensive AI-powered DevSecOps platform. Together, they help teams streamline how testing fits into the development lifecycle while maintaining the quality, security, and compliance standards their industries require.

Whether you're managing test execution for aerospace flight control systems, financial services platforms, automotive safety applications, or medical device software, the combination of GitLab's CI/CD capabilities and QMetry's test management gives teams a centralized, reliable view of testing across the lifecycle, helping them track execution, maintain traceability, and make more confident release decisions.

What you'll need

Before getting started, ensure you have:

• A GitLab account with a project containing automated tests that generate test result files (JUnit XML, TestNG XML, etc.)
• QMetry Test Management Enterprise account with API access enabled
• QMetry API Key generated from your QMetry instance (we'll cover this shortly)
• QMetry Project already created where you will upload test results
• Familiarity with GitLab CI/CD, including understanding of basic .gitlab-ci.yml syntax and pipeline concepts
• Test suite configuration in QMetry (optional but recommended for better organization)

Understanding the test result flow

Here's what happens when you integrate this component:

1. Test execution: Your GitLab CI/CD pipeline runs automated tests (unit tests, integration tests, E2E tests, etc.).
2. Result generation: Tests produce output files in formats like JUnit XML, TestNG XML, or other supported formats.
3. Component invocation: The QMetry component executes as a job in your pipeline.
4. Automatic upload: The component reads your test result files and uploads them to QMetry via API.
5. QMetry processing: QMetry receives the results, processes them, and makes them available for reporting and analysis.

The beauty of this integration is that it happens automatically, with no manual intervention required once configured.

Part 1: Getting your QMetry API credentials

Before configuring the GitLab component, you need to obtain API access credentials from your QMetry instance. Here are the steps to follow:

1. Access QMetry settings

1. Log in to your QMetry Test Management Enterprise instance.
2. Navigate to your user profile (typically in the top-right corner).
3. Select Settings or API Access from the dropdown menu.

2. Generate an API key

1. In the API Access section, click Generate New API Key.
2. Provide a descriptive name for the key (e.g., "GitLab CI/CD Integration").
3. Set appropriate permissions. The key needs write access to upload test results.
4. Click Generate.
5. Copy the API key immediately as it will only be displayed once.

Important security note: Treat your API key like a password. Never commit it directly to your .gitlab-ci.yml file or store it in plain text. We'll use GitLab CI/CD variables to store it securely.

3. Note your QMetry instance URL

You'll also need your QMetry instance URL, which typically follows this format:

https://your-company.qmetry.com

or, for self-hosted instances:

https://qmetry.your-company.com

Make note of this URL because you'll need it in the next section.

Part 2: Configuring GitLab CI/CD variables

Now that you have your QMetry credentials, let's store them securely in GitLab. Here are the next steps to follow:

4. Navigate to CI/CD settings

1. Open your GitLab project.
2. In the left sidebar, navigate to Settings > CI/CD.
3. Expand the Variables section.
4. Click Add variable.

5. Add the QMetry API key

Configure the API key variable:

Click Add variable to save.

6. Add the QMetry instance URL

Add a second variable for your instance URL:

Click Add variable to save.

Why use CI/CD variables?

• Security: Masked variables are hidden in job logs.
• Reusability: You can use the same credentials across multiple pipelines.
• Flexibility: It is easy to rotate credentials without modifying pipeline code.
• Access control: Protected variables are only available on protected branches.

Part 3: Understanding your test result files

Before integrating the component, ensure your tests generate output files that QMetry can process. Here are the next steps to follow:

7. Verify test output format

The QMetry component supports multiple test result formats. The most common is JUnit XML, which most testing frameworks can generate:

Example JUnit XML output (results.xml):

<?xml version="1.0" encoding="UTF-8"?>
<testsuites>
  <testsuite name="Flight Control System Tests" tests="15" failures="1" errors="0" time="45.231">
    <testcase classname="FlightControlTests" name="testAltitudeHold" time="2.341">
      <system-out>Altitude hold engaged at 10,000 feet</system-out>
    </testcase>
    <testcase classname="FlightControlTests" name="testAutopilotEngagement" time="3.125">
      <system-out>Autopilot engaged successfully</system-out>
    </testcase>
    <testcase classname="FlightControlTests" name="testEmergencyLanding" time="5.892">
      <failure message="Landing gear failed to deploy">
        Expected: Landing gear deployed
        Actual: Landing gear malfunction detected
      </failure>
    </testcase>
    <!-- Additional test cases... -->
  </testsuite>
</testsuites>

Most testing frameworks generate this format automatically:

• JUnit (Java): Native format
• pytest (Python): Use --junitxml=results.xml flag
• Jest (JavaScript): Use jest-junit reporter
• RSpec (Ruby): Use rspec_junit_formatter
• NUnit (.NET): Use nunit-console with XML output
• Go test: Use go-junit-report

8. Confirm test artifact configuration

Ensure your existing pipeline saves test results as artifacts. This allows the QMetry component to access them:

test:
  stage: test
  script:
    - npm install
    - npm test -- --reporter=junit --reporter-options=output=results.xml
  artifacts:
    reports:
      junit: results.xml
    paths:
      - results.xml
    when: always  # Upload even if tests fail

Key points:

• artifacts.reports.junit makes results visible in GitLab's test report UI.
• artifacts.paths ensures the file is available to downstream jobs.
• when: always ensures results upload even if tests fail.

Part 4: Integrating the QMetry component

Now for the main event – adding the QMetry component to your pipeline. Here are the next steps to follow:

9. Basic component integration

Add the component to your .gitlab-ci.yml file. The component should run after your tests complete:

include:
  - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5
    inputs:
      stage: test
      project: "Aerospace Flight Control System"
      file_name: "results.xml"
      testing_type: "JUNIT"
      instance_url: ${INSTANCE_URL}
      api_key: ${QMETRY_API_KEY}

Let's break down each input parameter:

10. Complete pipeline example

Here's a complete .gitlab-ci.yml example showing test execution followed by QMetry upload:

stages:
  - test
  - report

variables:
  # Your app-specific variables
  NODE_VERSION: "18"

# Run your automated tests
unit-tests:
  stage: test
  image: node:${NODE_VERSION}
  script:
    - npm ci
    - npm run test:unit -- --reporter=junit --reporter-options=output=results.xml
  artifacts:
    reports:
      junit: results.xml
    paths:
      - results.xml
    when: always
  tags:
    - docker

# Upload results to QMetry
include:
  - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5
    inputs:
      stage: test  # Runs in same stage as tests
      project: "Aerospace Flight Control System"
      file_name: "results.xml"
      testing_type: "JUNIT"
      instance_url: ${INSTANCE_URL}
      api_key: ${QMETRY_API_KEY}

11. Run your pipeline

Commit and push your changes:

git add .gitlab-ci.yml
git commit -m "Add QMetry test result integration"
git push origin main

Navigate to your GitLab project's CI/CD > Pipelines to watch the execution.

12. Verify successful upload

After the pipeline completes, you should see:

In GitLab:

1. A new job in your pipeline named qmetry-import (or similar)
2. Job logs showing successful API communication
3. Green checkmark indicating successful upload

Example successful job log:

$ curl -X POST https://your-company.qmetry.com/api/v3/test-results/import \
  -H "Authorization: Bearer ${QMETRY_API_KEY}" \
  -H "Content-Type: application/json" \
  -d @payload.json

{
  "status": "success",
  "message": "Test results uploaded successfully",
  "results_processed": 15,
  "test_cases_created": 3,
  "test_cases_updated": 12,
  "execution_id": "EXE-12345"
}

Job succeeded ```

**In QMetry**:

1. Navigate to your project dashboard.  
2. Check the **Test Executions** section.  
3. You should see a new test execution with results from your GitLab pipeline.  
4. Click into the execution to see detailed test case results.


## Part 5: Advanced configuration options

Now that you have the basic integration working, let's explore advanced configuration for enterprise requirements. Here are the next steps to follow:

### 13. Organizing results with test suites

For better organization, you can specify which QMetry test suite should receive results:

```yaml
include:
  - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5
    inputs:
      stage: test
      project: "Aerospace Flight Control System"
      file_name: "results.xml"
      testing_type: "JUNIT"
      testsuite_name: "Sprint 23 Regression Tests"
      testsuite_id: "TS-456"  # Optional: Use existing test suite ID
      instance_url: ${INSTANCE_URL}
      api_key: ${QMETRY_API_KEY}

When to use test suites:

• Organizing tests by sprint or release
• Separating regression tests from new feature tests
• Grouping tests by component or subsystem
• Creating test execution hierarchies for reporting

14. Configuring automation hierarchy levels

QMetry supports hierarchical test organization. Use the automation_hierarchy parameter to specify the organization level:

include:
  - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5
    inputs:
      stage: test
      project: "Aerospace Flight Control System"
      file_name: "results.xml"
      testing_type: "JUNIT"
      automation_hierarchy: "2"  # Level 2 hierarchy
      instance_url: ${INSTANCE_URL}
      api_key: ${QMETRY_API_KEY}

Hierarchy levels explained:

• Level 1: Top-level test suites (e.g., "All Regression Tests")
• Level 2: Sub-suites (e.g., "Flight Control Tests" under "Regression Tests")
• Level 3: Granular test groups (e.g., "Altitude Hold Tests" under "Flight Control")

15. Multiple test result files

For complex projects with multiple test jobs, you can invoke the component multiple times:

stages:
  - test

# Unit tests
unit-tests:
  stage: test
  script:
    - npm run test:unit
  artifacts:
    paths:
      - unit-results.xml
    when: always

# Integration tests
integration-tests:
  stage: test
  script:
    - npm run test:integration
  artifacts:
    paths:
      - integration-results.xml
    when: always

# Upload unit test results
include:
  - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5
    inputs:
      stage: test
      project: "Aerospace Flight Control System"
      file_name: "unit-results.xml"
      testing_type: "JUNIT"
      testsuite_name: "Unit Tests - Sprint 23"
      instance_url: ${INSTANCE_URL}
      api_key: ${QMETRY_API_KEY}

  # Upload integration test results
  - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5
    inputs:
      stage: test
      project: "Aerospace Flight Control System"
      file_name: "integration-results.xml"
      testing_type: "JUNIT"
      testsuite_name: "Integration Tests - Sprint 23"
      instance_url: ${INSTANCE_URL}
      api_key: ${QMETRY_API_KEY}

16. Custom runner tags

For enterprise environments with dedicated runners, specify runner tags:

include:
  - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5
    inputs:
      stage: test
      runner_tag: "production-runners"  # Use specific runner pool
      project: "Aerospace Flight Control System"
      file_name: "results.xml"
      testing_type: "JUNIT"
      instance_url: ${INSTANCE_URL}
      api_key: ${QMETRY_API_KEY}

17. Custom test suite folders

Organize test suites into folders for better project structure:

include:
  - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5
    inputs:
      stage: test
      project: "Aerospace Flight Control System"
      file_name: "results.xml"
      testing_type: "JUNIT"
      testsuite_folder_path: "/Regression/Sprint-23/Flight-Controls"
      instance_url: ${INSTANCE_URL}
      api_key: ${QMETRY_API_KEY}

This creates a folder hierarchy in QMetry:

Aerospace Flight Control System/
└── Regression/
    └── Sprint-23/
        └── Flight-Controls/
            └── [Your test execution]

18. Advanced field mapping

For enterprise QMetry instances with custom fields, use the testcase_fields and testsuite_fields parameters:

include:
  - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5
    inputs:
      stage: test
      project: "Aerospace Flight Control System"
      file_name: "results.xml"
      testing_type: "JUNIT"
      testcase_fields: "priority=P1,component=FlightControl,certification=DO-178C"
      testsuite_fields: "release=v2.4.0,sprint=23"
      instance_url: ${INSTANCE_URL}
      api_key: ${QMETRY_API_KEY}

This adds custom metadata to test cases and suites for enhanced filtering and reporting.

Part 6: Real-world use cases

Let's explore how organizations across different industries are using this integration to solve critical quality and compliance challenges.

Financial services: Enterprise banking platforms

Leading financial institutions are evolving their engineering practices with integrated DevOps platforms. These organizations face unique challenges when managing test automation at scale.

The challenge for financial services:

• Regulatory compliance: Financial services must maintain detailed audit trails for all testing activities.
• Multiple compliance frameworks: Firms must adhere to FCA, PSD2, GDPR, and internal risk management policies.
• High-frequency deployments: Multiple production deployments are required daily across microservices.
• Zero-tolerance for failures: Banking systems require extremely high reliability.
• Distributed teams: QA teams need real-time visibility across global engineering teams.

The solution: Financial services organizations implementing the QMetry GitLab Component can automate test result uploads across their CI/CD pipelines for:

• Unit tests for hundreds of microservices
• API contract tests for inter-service communication
• End-to-end transaction flow tests
• Security and compliance scanning results
• Performance and load testing results

Example implementation approach:

# Financial services approach: Separate test uploads by test type
stages:
  - test
  - security
  - report

# Unit tests for payment processing service
unit-tests:
  stage: test
  script:
    - mvn clean test
  artifacts:
    paths:
      - target/surefire-reports/TEST-*.xml
    when: always

# Upload to QMetry with compliance metadata
include:
  - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5
    inputs:
      stage: report
      project: "Payment Processing Platform"
      file_name: "target/surefire-reports/TEST-*.xml"
      testing_type: "JUNIT"
      testsuite_name: "Payment Services - Unit Tests"
      testsuite_folder_path: "/Regulatory/FCA-Compliance/Unit-Tests"
      testcase_fields: "compliance=FCA,risk_level=high,service=payments"
      automation_hierarchy: "2"
      instance_url: ${INSTANCE_URL}
      api_key: ${QMETRY_API_KEY}

Potential business outcomes for financial services:

• Significant reduction in manual test reporting time
• Complete audit trail coverage for regulatory reviews
• Real-time visibility for distributed QA teams
• Faster time-to-production with automated quality gates
• Enhanced compliance posture with complete traceability from requirements to test execution

Aerospace flight control testing

Let's explore how an aerospace company might use this integration for critical flight control system testing.

Aerospace software development faces unique requirements and challenges:

• DO-178C compliance: Aviation software must follow strict certification standards
• Complete traceability: Every requirement must link to test cases and execution results
• Audit trails: Regulators require detailed records of all testing activities
• Safety-critical quality: Failures can have catastrophic consequences
• Multiple test levels: Unit, integration, system, and certification tests

The solution: By integrating GitLab CI/CD with QMetry, the aerospace engineering team achieves automated test execution and reporting.

stages:
  - build
  - unit-test
  - integration-test
  - system-test
  - report

# Build flight control firmware
build-firmware:
  stage: build
  script:
    - make clean
    - make build TARGET=flight-control
  artifacts:
    paths:
      - build/flight-control.bin

# Unit tests (DO-178C Level A)
unit-tests:
  stage: unit-test
  script:
    - make test-unit OUTPUT=junit
  artifacts:
    paths:
      - test-results/unit-tests.xml
    when: always

# Hardware-in-the-loop integration tests
hil-integration-tests:
  stage: integration-test
  tags:
    - hil-test-bench  # Dedicated hardware test environment
  script:
    - ./scripts/deploy-to-test-bench.sh
    - ./scripts/run-hil-tests.sh
  artifacts:
    paths:
      - test-results/hil-tests.xml
    when: always

# System-level certification tests
certification-tests:
  stage: system-test
  tags:
    - certification-environment
  script:
    - ./scripts/run-certification-suite.sh
  artifacts:
    paths:
      - test-results/certification-tests.xml
    when: always
  only:
    - main  # Only run on main branch

# Upload unit test results to QMetry
include:
  - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5
    inputs:
      stage: report
      project: "Flight Control System v2.4"
      file_name: "test-results/unit-tests.xml"
      testing_type: "JUNIT"
      testsuite_name: "Unit Tests - DO-178C Level A"
      testsuite_folder_path: "/Certification/DO-178C/Unit"
      testcase_fields: "compliance=DO-178C,level=A,safety_critical=true"
      automation_hierarchy: "2"
      instance_url: ${INSTANCE_URL}
      api_key: ${QMETRY_API_KEY}

  # Upload HIL test results
  - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5
    inputs:
      stage: report
      project: "Flight Control System v2.4"
      file_name: "test-results/hil-tests.xml"
      testing_type: "JUNIT"
      testsuite_name: "Hardware-in-Loop Integration Tests"
      testsuite_folder_path: "/Certification/DO-178C/Integration"
      testcase_fields: "compliance=DO-178C,level=A,test_type=HIL"
      automation_hierarchy: "2"
      instance_url: ${INSTANCE_URL}
      api_key: ${QMETRY_API_KEY}

  # Upload certification test results
  - component: gitlab.com/sb9945614/qtm-gitlab-component/qmetry-import@1.0.5
    inputs:
      stage: report
      project: "Flight Control System v2.4"
      file_name: "test-results/certification-tests.xml"
      testing_type: "JUNIT"
      testsuite_name: "System Certification Tests"
      testsuite_folder_path: "/Certification/DO-178C/System"
      testcase_fields: "compliance=DO-178C,level=A,certification_ready=true"
      automation_hierarchy: "1"
      instance_url: ${INSTANCE_URL}
      api_key: ${QMETRY_API_KEY}

The results

Before integration:

• QA engineers manually exported test results from GitLab
• Imported results into QMetry through UI uploads
• Process took 2-3 hours per test cycle
• Human error risk in data entry
• Delayed feedback to stakeholders

After integration:

• Test results automatically flow from GitLab to QMetry
• Complete audit trail from commit → test → result
• Zero manual intervention required
• Real-time visibility for certification auditors
• Compliance reports generated automatically

Example QMetry dashboard after integration:

╔════════════════════════════════════════════════════════════╗
║  Flight Control System v2.4 - Test Execution Dashboard     ║
╠════════════════════════════════════════════════════════════╣
║                                                            ║
║  📊 Test Execution Summary (Last 7 Days)                   ║
║  ───────────────────────────────────────────────────────── ║
║  ✓ Total Tests Executed: 1,247                             ║
║  ✓ Passed: 1,241 (99.5%)                                   ║
║  ✗ Failed: 6 (0.5%)                                        ║
║  ⏸ Skipped: 0                                              ║
║                                                            ║
║  📁 Test Suite Organization                                ║
║  ───────────────────────────────────────────────────────── ║
║  └─ Certification/                                         ║
║     └─ DO-178C/                                            ║
║        ├─ Unit/ (487 tests, 100% pass)                     ║
║        ├─ Integration/ (623 tests, 99.2% pass)             ║
║        └─ System/ (137 tests, 100% pass)                   ║
║                                                            ║
║  🔗 Traceability                                           ║
║  ───────────────────────────────────────────────────────── ║
║  Requirements Covered: 342/342 (100%)                      ║
║  Test Cases Linked: 1,247/1,247 (100%)                     ║
║  GitLab Pipeline Executions: 47 (automated)                ║
║                                                            ║
║  ⚠️  Action Items                                          ║
║  ───────────────────────────────────────────────────────── ║
║  • 6 failed tests require investigation                    ║
║  • Last execution: 2 minutes ago (Pipeline #1543)          ║
║  • GitLab Commit: a7f8c23 "Fix altitude hold logic"        ║
║                                                            ║
╚════════════════════════════════════════════════════════════╝

Compliance and audit benefits

Both financial services and aerospace organizations can leverage this integration for compliance:

For financial services (FCA, PSD2, SOX):

1. Automated traceability: Link regulatory requirements → test cases → execution results → GitLab commits
2. Audit-ready documentation: Complete test execution history with timestamps and pipeline references
3. Risk management: Real-time quality dashboards for risk assessment
4. Regulatory reporting: Generate compliance reports directly from QMetry test data

For aerospace certification (DO-178C, DO-254):

1. Automated traceability matrix: QMetry links requirements → test cases → execution results → GitLab commits
2. Immutable audit trail: Every test execution is timestamped with pipeline ID, commit SHA, and executor
3. Certification package generation: QMetry generates compliant documentation pulling data from GitLab pipelines
4. Real-time compliance dashboards: Auditors can view test coverage and execution history in real-time

Complete configuration reference

Here's a comprehensive reference of all available component inputs:

Best practices for production use

As you scale your integration, follow these best practices:

Security

• ✅ Always use CI/CD variables for sensitive data (API keys, URLs)
• ✅ Mask and protect API key variables
• ✅ Rotate API keys periodically (quarterly recommended)
• ✅ Restrict API key permissions to minimum required (write to test results only)
• ✅ Use protected branches for production test uploads

Performance

• ✅ Keep test result files reasonable size (< 10 MB recommended)
• ✅ Split large test suites into multiple jobs/files
• ✅ Use parallel test execution to reduce pipeline duration
• ✅ Cache dependencies to speed up test execution

Organization

• ✅ Use consistent naming conventions for test suites and folder paths
• ✅ Leverage custom fields for filtering and reporting
• ✅ Create folder hierarchies that mirror your test strategy
• ✅ Document your integration in project README files

Troubleshooting

• ✅ Review job logs for API communication details
• ✅ Verify test result file format matches testing_type parameter
• ✅ Check QMetry project exists and API key has access
• ✅ Ensure test result files are available as pipeline artifacts

Summary and next steps

Congratulations! You've successfully integrated GitLab CI/CD with QMetry Test Management Enterprise. Your setup now provides:

• Automated test result uploads – No more manual exports and imports
• Real-time visibility – QA teams see results immediately after pipeline execution
• Complete traceability – Link GitLab commits, pipelines, and test executions
• Enhanced compliance – Maintain audit trails for regulated industries
• Scalable quality processes – Support growing test suites without added overhead

What happens now

Every time your GitLab pipeline runs:

1. Tests execute and generate result files.
2. The QMetry component automatically uploads results to your instance.
3. QA teams, stakeholders, and auditors see results in QMetry dashboards.
4. AI-powered insights analyze execution patterns and identify improvements.
5. Compliance reports generate automatically with full traceability.

Expand your integration

Now that you have the basic integration working, consider these advanced scenarios:

• Bi-directional integration: Use QMetry's API to trigger GitLab pipelines from test management workflows.
• Multi-project deployments: Scale the component across your organization's GitLab projects.
• Custom reporting: Build dashboards combining GitLab pipeline metrics with QMetry test analytics.
• Scheduled test execution: Use GitLab scheduled pipelines to run regression suites nightly.

Learn more and get help

Documentation and resources

• Component documentation: GitLab CI/CD Catalog
• QMetry documentation: QMetry Support Portal
• SmartBear resources: SmartBear Academy
• GitLab CI/CD documentation: GitLab CI/CD Documentation

Support

For component technical questions:

• Visit the component repository.
• Open an issue on the project.
• Check existing issues for common questions.

For QMetry product questions:

• Contact SmartBear support at support@smartbear.com.
• Visit the QMetry Community Forum.

In the span of 12 days, four separate supply chain attacks revealed that continuous integration and continuous delivery (CI/CD) pipelines have become a high-value target for sophisticated threat actors.

Between March 19 and March 31, 2026, threat actors compromised:

• an open-source security scanner (Trivy)
• an infrastructure-as-code (IaC) security scanner (Checkmarx KICS)
• an AI model gateway (LiteLLM)
• a JavaScript HTTP client (axios)

Each attack shared the same surface: the build pipeline. This article shows what happened, why pipelines can be uniquely vulnerable, and how centralized policy enforcement with GitLab — using policies defined below — can block, detect, and contain these classes of attack before they reach production.

Trusted by millions, compromised in minutes

Here is the timeline of the supply chain attacks:

March 19: Trivy security scanner becomes an attack vector

Trivy is one of the most widely used open-source vulnerability scanners in the world. It is the tool teams run inside their pipelines to find vulnerabilities.

On March 19, a threat actor group known as TeamPCP used compromised credentials to force-push malicious code into 76 of 77 version tags of the aquasecurity/trivy-action GitHub Action and all 7 tags of aquasecurity/setup-trivy. Simultaneously, they published a trojanized Trivy binary (v0.69.4) to official distribution channels. The payload was credential-stealing malware that harvested environment variables, cloud tokens, SSH keys, and CI/CD secrets from every pipeline that ran a Trivy scan.

The incident was assigned CVE-2026-33634 with a CVSS score of 9.4. The Cybersecurity and Infrastructure Security Agency (CISA) added it to the Known Exploited Vulnerabilities catalog within days.

March 23: Checkmarx KICS falls next

Using stolen credentials, TeamPCP pivoted to Checkmarx’s open-source KICS (Keeping Infrastructure as Code Secure) project. They compromised the ast-github-action and kics-github-action GitHub Actions, injecting the same credential-stealing malware. Between 12:58 and 16:50 UTC on March 23, any CI/CD pipeline referencing these actions was silently exfiltrating sensitive data, such as API keys, database passwords, cloud access tokens, SSH keys, and service account credentials.

March 24: LiteLLM compromised via stolen Trivy credentials

LiteLLM, an LLM API proxy with 95 million monthly downloads, was the next target. TeamPCP published backdoored versions (1.82.7 and 1.82.8) to PyPI using credentials harvested from LiteLLM’s own CI/CD pipeline, which used Trivy for scanning.

The malware targeting Version 1.82.7 used a base64-encoded payload injected directly into litellm/proxy/proxy_server.py that executed at import time. The version targeting 1.82.8 used a .pth file, a Python mechanism that executes automatically during interpreter startup. Simply installing LiteLLM was enough to trigger the payload. Attackers encrypted the stolen data (SSH keys, cloud tokens, .env files, cryptocurrency wallets) and exfiltrated it to models.litellm.cloud, a lookalike domain.

March 31: Source code for AI coding assistant leaked via simple packaging mistake

While the TeamPCP campaign was still unfolding, a software company shipped an npm package containing a 59.8 MB source map file — one that referenced its AI coding assistant's complete, unminified TypeScript source code, hosted in the company's own Cloudflare R2 bucket.

The leak exposed 1,900 TypeScript files, 512,000+ lines of code, 44 hidden feature flags, unreleased model codenames, and the full system prompt for anyone who knew where to look. As engineer Gabriel Anhaia explained, “A single misconfigured .npmignore or files field in package.json can expose everything.”

March 31: axios and another trojan in the supply chain

That same day, a sophisticated campaign targeted the axios npm package, a JavaScript HTTP client with over 100 million weekly downloads.

A compromised maintainer account published backdoored versions (1.14.1 and 0.30.4). It injected a malicious dependency (plain-crypto-js@4.2.1) that deployed a Remote Access Trojan capable of running on macOS, Windows, and Linux. Both release branches were hit within 39 minutes, with the malware designed to self-destruct after execution.

The patterns behind these attacks

Across these five incidents, three distinct attack patterns emerge, and all of them exploit the implicit trust that CI/CD pipelines place in their inputs.

Pattern 1: Poisoned tools and actions

The TeamPCP campaign exploited a fundamental assumption: that the security tools running inside your pipeline are themselves trustworthy. When a GitHub Action tag or a PyPI package version resolves to malicious code, the pipeline executes it with full access to environment secrets, cloud credentials, and deployment tokens. There is no verification step because the pipeline trusts the tag.

A recommended pipeline-level control: Pin tools and actions to immutable references (commit SHAs or image digests) rather than mutable version tags. Where pinning is not practical, verify the integrity of tools and dependencies against known-good checksums or signatures. Block execution if verification fails.

Pattern 2: Packaging misconfigurations that leak IP

A misconfigured build pipeline shipped debugging artifacts straight into the production package. A misconfigured .npmignore or files field in package.json is all it takes. A pre-publish validation step should catch this every time.

A recommended pipeline-level control: Before any package is published, run automated checks that validate the package contents against an allowlist, flag unexpected files (source maps, internal configs, .env files), and block the publish step if the checks fail.

Pattern 3: Vulnerabilities in transitive dependencies

The axios attack targeted not just direct users of axios, but anyone whose dependency tree resolved to the compromised version. A single poisoned dependency in a lockfile can thus propagate through an entire organization’s build infrastructure.

A recommended pipeline-level control: Compare dependency checksums against known-good lockfile state. Detect unexpected new dependencies or version changes. Block builds that introduce unverified packages.

How GitLab Pipeline Execution Policies address each attack pattern

GitLab Pipeline Execution Policies (PEPs) enable security and platform teams to inject mandatory CI/CD jobs into every pipeline across an organization, regardless of what a developer defines in their .gitlab-ci.yml. Jobs defined in PEPs cannot be skipped, even with [skip ci] or [no_pipeline] directives. Jobs can be executed in reserved stages (.pipeline-policy-pre and .pipeline-policy-post) that bookend the developer’s pipeline.

We have published ready-to-use pipeline execution policies for all three patterns as an open-source project: Supply Chain Policies. These policies are independently deployable, and each one ships with violation samples that you can use to test them. Here is how each one works.

Use case 1: Prevent accidental exposure in package publishing

Problem: A source map file ended up in the npm package of an AI coding tool after the build pipeline skipped publish-time validation.

PEP approach: We built an open-source Pipeline Execution Policy for exactly this class of error: Artifact Hygiene.

The policy injects .pipeline-policy-pre jobs that auto-detect the artifact type (npm package, Docker image, or Helm chart) and inspect the contents before any publish step runs. For npm packages, it performs three checks:

1. File pattern blocklist. Scans npm pack output for source maps (.map), test directories, build configs, IDE settings, and src/ directories.
2. Package size gate. Blocks packages exceeding 50 MB, like the 59.8 MB package that leaked the AI tool.
3. sourceMappingURL scan. Detects external URLs (the R2 bucket pattern that exposed a major AI company’s source), inline data: URIs, and local file references embedded in JavaScript bundles.

When violations are found, the pipeline fails with a clear report in the failed CI job logs:

=============================================
FAILED: 3 violation(s) found
=============================================
BLOCKED: dist/index.js.map (matched: \.map$)
BLOCKED: dist/index.js contains external sourceMappingURL
BLOCKED: dist/utils.js contains inline sourceMappingURL

This check is enforced by a Pipeline Execution Policy. If this is a false positive, contact the security team to update the policy project or exclude this project.

The policy has no user-configurable CI variables. Developers cannot disable or bypass it. Exceptions are managed by the security team at the policy level, ensuring a deliberate process and a clean audit trail.

The repository includes a test project with intentional violations (examples/leaky-npm-package/) so you can see the policy in action before deploying it to your organization. The README includes a complete quick-start guide for setup and deployment.

What this catches: Any one of these controls would likely have prevented the AI company's source code leak:

• The source map file triggers the file pattern blocklist.
• Its 59.8 MB size triggers the size gate.
• The sourceMappingURL pointing to an external R2 bucket triggers the URL scan.

Use case 2: Detect dependency tampering and lockfile manipulation

Problem: The axios attack introduced a malicious transitive dependency (plain-crypto-js) that executed a RAT on install. Anyone who ran npm install during the compromise window pulled in the trojan.

PEP approach: The Dependency Integrity policy injects .pipeline-policy-pre jobs that auto-detect the package ecosystem (npm or Python) and perform three checks:

For npm projects (triggered by package-lock.json, yarn.lock, or pnpm-lock.yaml):

1. Lockfile integrity. Runs npm ci --ignore-scripts, which fails if node_modules would differ from what the lockfile specifies. This catches cases where package.json was updated but the lockfile was not regenerated, and also verifies SRI integrity hashes.
2. Blocked package scan. Cross-references the lockfile’s full dependency tree against blocked-packages.yml, a GitLab-maintained list of known-compromised package versions. The shipped blocklist includes axios@1.14.1, axios@0.30.4, and plain-crypto-js@4.2.1.
3. Undeclared dependency detection. After install, compares the contents of node_modules against the lockfile. Any package present on disk but absent from the lockfile indicates tampering (e.g., a compromised postinstall script that fetches additional packages).

For Python projects (triggered by requirements.txt, Pipfile.lock, poetry.lock, or uv.lock):

1. Lockfile integrity. Installs in an isolated virtual environment and verifies that the install succeeds from the lockfile.
2. Blocked package scan. Same blocklist approach. The shipped list includes litellm==1.82.7 and litellm==1.82.8.
3. .pth file detection. Scans site-packages for .pth files containing executable code patterns (import os, exec(, eval(, __import__, subprocess, socket). This is the exact mechanism the LiteLLM backdoor used.

When a violation is found:

=============================================
FAILED: 1 violation(s) found
=============================================
BLOCKED: axios@1.14.1 is a known-compromised package

This check is enforced by a Pipeline Execution Policy.

The policy runs in strict mode: any dependency not present in the committed lockfile blocks the pipeline. If a developer needs to add a dependency, they commit the updated lockfile. The policy verifies that the installed version matches the committed version. If something appears that was not committed (e.g., a transitive dependency injected via a compromised upstream package), the pipeline blocks.

What this catches: The introduction of plain-crypto-js as a new, previously unseen dependency would be flagged by the undeclared dependency check. The axios@1.14.1 version would be caught by the blocked package scan. The LiteLLM .pth file would be caught by the .pth detection check. Each attack has at least one, and often two, independent detection signals.

Use case 3: Detect and block compromised tools before execution

Problem: TeamPCP replaced trusted Trivy and Checkmarx GitHub Action tags with malicious versions. Any pipeline referencing those tags executed credential-stealing malware.

PEP approach: The Tool Integrity policy injects a .pipeline-policy-pre job that queries the GitLab CI Lint API (or falls back to evaluate the .gitlab-ci.yml), extracts the container image references, and compares it against an approved images allowlist maintained by the security team.

The allowlist (approved-images.yml) supports three controls per image:

Approved repositories: Only images from repositories on the list are permitted. An unknown repository blocks the pipeline.

Allowed tags: Only specific tags are permitted within an approved repository. This prevents drift to untested versions.

Blocked tags: Known-compromised versions can be explicitly blocked even if the repository is approved. The shipped allowlist blocks aquasec/trivy:0.69.4 through 0.69.6, the exact versions TeamPCP trojanized.

When a violation is found, the pipeline fails before any other job runs:

=============================================
FAILED: 1 violation(s) found
=============================================
BLOCKED: aquasec/trivy:0.69.4 (job: trivy-scan)

 - tag '0.69.4' is known-compromised

This check is enforced by a Pipeline Execution Policy.

The allowlist is maintained via MRs against the policy project. To add a new approved image, the security team opens an MR. To respond to a new compromise, they add a blocked tag. No code changes required, just YAML.

What this catches: When images with unapproved tags are detected, the policy compares the image repository names and tags to an allowlist. A failed match blocks the pipeline before any scanner executes, preventing credential exfiltration.

Note: By extending the sample above, PEPs can be used to force pinning to digests over tags, which is immune to force pushes. This sample demonstrates a more basic tag-based enforcement pattern.

Beyond PEPs: GitLab’s supply chain defenses

Pipeline Execution Policies are the enforcement layer, but they work best as part of a broader defense-in-depth strategy. GitLab provides several capabilities that complement PEPs for supply chain protection:

Secret detection

GitLab secret detection prevents credentials from landing in the repository in the first place, significantly reducing what a compromised pipeline tool can harvest. In the context of the March 2026 attacks:

• Credentials stored in repositories are both easier for attackers to discover and slower to rotate. The Trivy incident showed that even the rotation process can be exploited: Aqua Security's rotation was not atomic, and the attacker captured newly issued tokens before the old ones were fully revoked. GitLab Secret Detection includes automatic revocation for leaked GitLab tokens and a partner API that notifies third-party providers to revoke their credentials, accelerating response when a breach does occur.
• Secret detection combined with proper secret management (short-lived tokens, vault-backed credentials, minimal pipeline secret exposure) limits what an attacker can reach even when a trusted tool turns hostile.

Dependency scanning via software composition analysis (SCA)

GitLab dependency scanning identifies known vulnerabilities in project dependencies by analyzing lockfiles and manifests. In the context of the March 2026 attacks:

• For LiteLLM, the compromised versions (1.82.7, 1.82.8) are tracked in GitLab's advisory database, flagging affected Python projects automatically.
• For axios, dependency scanning identifies the compromised versions (1.14.1, 0.30.4) across every project in the organization, giving security teams a single view for assessing blast radius and prioritizing credential rotation.
• Similarly, all npm packages compromised by TeamPCP's CanisterWorm propagation are also flagged if used.

GitLab Container Scanning detects vulnerable container images used in your deployments. For the Trivy compromise, Container Scanning flags the trojanized Trivy Docker images (0.69.4 through 0.69.6) when they appear in your container registry or deployment manifests.

Merge request approval policies

Merge request approval policies can require security team approval before changes to dependency lockfiles or CI/CD configurations are merged. This ensures a human checkpoint for the types of changes that supply chain attacks typically introduce.

Coming soon: Dependency Firewall, Artifact Registry, and SLSA Level 3 Attestation & Verification

Upcoming GitLab supply chain security capabilities harden policy enforcement at two critical control points: the registry and the pipeline. The Dependency Firewall and Artifact Registry will block non-conforming packages, while SLSA Level 3 attestation will provide cryptographic proof that artifacts were produced by approved pipelines and remain unmodified. Together, they will give security teams verifiable control over what enters and exits the software supply chain.

What this means for your organization

Amidst rising AI-assisted threats, attacks on CI/CD pipelines are becoming commonplace. The TeamPCP campaign shows how a single compromised credential can cascade across an ecosystem of trusted tools.

If your organization used any of the affected components, operate with the assumption that all of your pipeline secrets were exposed: rotate them immediately and audit systems for persisted backdoors. Either way, regularly rotating credentials and using short-lived tokens limits the blast radius of any future compromise.

Here is what we recommend:

1. Pin dependencies to checksums, when possible. Mutable version tags (like the ones TeamPCP hijacked) are not a security boundary. Use SHA-pinned references for all CI/CD components or actions and container images.
2. Run pre-execution integrity checks. Use Pipeline Execution Policies to verify tool and dependency integrity before any pipeline job runs. This is the .pipeline-policy-pre stage.
3. Audit what you publish. Every package publish step should include automated validation of the artifact contents. Source maps, environment files, and internal configuration should never leave your build environment. The Supply Chain Policy project provides a ready-to-deploy starting point for npm, Docker, and Helm artifacts.
4. Detect dependency drift. Compare dependency resolutions against committed lockfiles on every pipeline run. Monitor for unexpected new dependencies.
5. Centralize policy management. Do not rely on developers remembering to include security checks. Enforce them at the group or instance level through policies that developers cannot remove or skip.
6. Assume your security tools are targets. If your vulnerability scanner, static application security testing (SAST) tool, or AI gateway can be compromised, it will be. Limit each tool to its least necessary privileges and verify that it can't reach anything else.

Protect your pipelines with GitLab

Over two weeks, attackers compromised production pipelines at organizations running some of the most widely adopted tools in the software development ecosystem.

The lesson is clear: Build pipelines need the same degree of centralized, policy-driven protection that we apply to networks and cloud infrastructure.

GitLab Pipeline Execution Policies provide that enforcement layer. They ensure that security checks run on every pipeline, in every project regardless of individual project configurations. Combined with dependency scanning, secret detection, and merge request approval policies, they can block, detect, and contain the class of attacks we saw in March 2026.

The Supply Chain Policies project provides a working Pipeline Execution Policy that catches the exact class of error behind the major AI company’s leak, with coverage for npm packages, Docker images, and Helm charts. Clone it, deploy it to your group, and ensure that all of your pipelines are ready for the supply chain attacks to come.

To get started with centralized pipeline policies, sign up for a free trial of GitLab Ultimate.

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

GitLab Duo CLI brings agentic AI powered by Duo Agent Platform to the terminal with full support for automated workflows, alongside an interactive chat mode when you need a human in the loop. This article highlights what Duo CLI does, how its two operating modes work, and the security model behind it.

How to install GitLab Duo CLI

If you already have GLab (the GitLab CLI) installed, enter:

glab duo cli

Then follow the prompts.

If you don't have GLab yet, you can install it here or use GitLab Duo CLI as a standalone tool.

Why the terminal, and why now

The first wave of AI assistants for software development lived in the IDE, and focused solely on coding. That made sense when the job was autocomplete. But as AI agents start doing things across every stage of the software lifecycle, e.g. running tests, triggering pipelines, monitoring vulnerability scans, and more, the IDE may no longer be the only abstraction needed to get the job done.

The best developer tools are ones that work for both humans and machines. CLIs have had decades of design iteration toward that goal. They're composable. You can pipe output, chain commands, and drop them into scripts. They're debuggable: when something goes wrong, you run the same command yourself and see exactly what the agent saw. And they're transparent. No background processes, no initialization dance, no protocol to decode when things break.

Terminal interfaces are better for automation, scripting, and environment portability. IDE interfaces are better for interactive, context-rich development. GitLab Duo CLI is designed for the former, while Duo Agentic Chat in the IDE and UI covers the latter.

What GitLab Duo CLI can do

With GitLab Duo CLI, developers can build, modify, refactor, and modernize code — similar to other AI-powered coding assistants built for the terminal. But that’s not where they stop. Any agent and flow defined within GitLab Duo Agent Platform is accessible via Duo CLI, whether it is to automate CI/CD configuration and optimize pipelines, or to perform multi-step development tasks autonomously across the entire software development lifecycle.

GitLab Duo CLI runs in two modes:

• Interactive mode, an editor-agnostic terminal chat experience with human-in-the-loop approval before any action is taken. Use it to understand codebase structure, create code, fix errors, or troubleshoot broken pipelines.
• Headless mode, non-interactive, designed for runners, scripts, and automated workflows. Drop it into CI/CD and let it work without handholding.

AI with guardrails

Agentic AI that can take actions creates real security exposure. GitLab Duo CLI addresses this at the platform level, not as an afterthought:

• Human-in-the-loop by default in interactive mode, so no action is taken without approval.
• Prompt injection detection is built into the GitLab Duo Agent Platform, not bolted on.
• Composite identity limits what the agent can access and makes every AI-driven action auditable.

GitLab Duo CLI also supports custom instruction files, e.g. chat-rules.md, AGENTS.md, and SKILL.md, that define which tasks, resources, context, knowledge, and actions your agents are permitted to take. This is the principle of least privilege applied to AI: Your agent does exactly what you've authorized, and nothing more.

Watch GitLab Duo CLI in action:

Use GitLab Duo CLI today

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

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

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

The base domain packages.gitlab.com remains the same, but URL formats, GPG key locations, network requirements, and the package browsing UI are changing. Your existing configuration will continue to work during the transition period until September 30, 2026 — we are maintaining backwards compatibility with old URL formats through URL rewrite rules while customers transition.

The updated installation documentation already reflects the new URL formats. If you are setting up a new installation, follow the documentation and no further action is needed.

If you have an existing installation, read on for what's changing and what you need to do.

Timeline

The old PackageCloud system and its UI will be shut down on March 31, 2026. Since all traffic has been served from the new system for months, we do not expect any disruptions.

The URL rewrite rules maintaining backwards compatibility will be removed by the end of September 2026. After that date, only the new URL formats will work.

We recommend updating your configurations as soon as possible.

Required actions

Before the end of September 2026, you need to:

1. Re-run the installation script (DEB or RPM) or manually update repository configurations for gitlab/* repos to use the new URL formats.
2. Update GPG key references from https://packages.gitlab.com/gpg.key to https://packages.gitlab.com/gpgkey/gpg.key.
3. Update firewall/proxy allowlists to permit traffic to https://storage.googleapis.com/packages-ops.
4. Update mirroring configurations to use the new URL formats, if you mirror GitLab package repositories.
5. Update Runner noarch RPM references from the noarch path to x86_64, if you use Runner noarch RPM packages.
6. Update any direct download automation, if you relied on PackageCloud-style download.rpm or download.deb URLs.

Read on for the details behind each change.

What's changing

DEB repository URLs for gitlab/* repos

For gitlab/* repositories (e.g., gitlab-ee, gitlab-ce), the DEB repository URL structure now includes the distribution codename as a path segment. This aligns with the standard Debian repository format, where the distribution codename is part of the base URL that your package manager uses to locate package metadata and pools. The old PackageCloud format omitted this path segment.

The easiest way to update is to re-run the installation script, which will automatically configure the correct repository URLs:

curl --location "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh" | sudo bash

Replace gitlab-ee with the appropriate repository name (e.g., gitlab-ce). For RPM-based systems, use script.rpm.sh instead.

If you prefer to update your configuration manually, here is what changed. For example, for GitLab EE on Ubuntu Jammy:

Old format (to be deprecated):

deb https://packages.gitlab.com/gitlab/gitlab-ee/ubuntu/ jammy main

This resolved to paths like:

/gitlab/gitlab-ee/ubuntu/dists/jammy/...
/gitlab/gitlab-ee/ubuntu/pool/...

New format:

deb https://packages.gitlab.com/gitlab/gitlab-ee/ubuntu/jammy jammy main

Which resolves to:

/gitlab/gitlab-ee/ubuntu/jammy/dists/jammy/...
/gitlab/gitlab-ee/ubuntu/jammy/pool/...

Note the addition of the distribution codename (jammy) as a path segment before dists/ and pool/.

DEB repository URLs for runner/* repos

The URL format for runner/* DEB repositories (e.g., runner/gitlab-runner) are unchanged. No action is needed.

GPG key URL

The GPG key URL has changed. Update any references in your configuration:

Installation scripts

Do not reuse old installation scripts. If you have previously saved copies of the installation scripts, download the latest versions:

DEB-based (Debian/Ubuntu):

curl --location "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh" | sudo bash

RPM-based (RHEL/CentOS/etc.):

curl --location "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.rpm.sh" | sudo bash

Replace gitlab-ee with the appropriate repository name (e.g., gitlab-ce).

Direct package download URLs

The old PackageCloud UI exposed download links in a format like /<org>/<repo>/packages/<distro>/<os>/<filename>.<ext>/download.<ext> (e.g., download.deb, download.rpm). The new UI links directly to the actual package paths instead.

If you navigate packages through the new UI, no action is needed. However, if you have automation that scrapped the old UI or relied on the download.deb / download.rpm URL format, you will need to update it to use the new path structure or switch to standard package manager repository access.

GitLab Runner noarch RPM package changes

GitLab Runner noarch RPM packages (such as gitlab-runner-helper-images) have been moved from the noarch architecture path to x86_64. For example:

Old path:

/<org>/<repo>/<distro>/<os>/noarch/Packages/...

New path:

/<org>/<repo>/<distro>/<os>/x86_64/Packages/...

This change only affects RPM-based distributions (e.g., EL/8, EL/9). DEB-based Runner packages are not affected.

If you have automation or configuration that references the noarch path for Runner RPM packages, update it to use x86_64 instead.

Firewall and network allowlist updates

Package downloads from packages.gitlab.com now redirect to Google Cloud Storage. Previously, packages were served through AWS CloudFront. If your environment has strict firewall or proxy rules, you must add the following to your allowlist:

https://storage.googleapis.com/packages-ops

Without this change, package downloads may fail with 503 errors or connection timeouts.

Repository mirroring

If you mirror GitLab package repositories using tools like apt-mirror, reposync, or Red Hat Satellite, you must update to the new URL format for gitlab/* repos. The old URL format does not work correctly for mirroring with the new infrastructure. More detailed instructions can be found on the installation guide.

UI changes

The package browsing interface at packages.gitlab.com is being updated with a new UI. The old interface (previously accessible at packages.gitlab.com/gitlab/... and packages.gitlab.com/runner/... ) will no longer be available. The new interface provides similar package browsing functionality.

Feedback

If you encounter any issues related to these changes, please report them in our public feedback issue. We are actively monitoring it and will respond to reports.

Feature flags prevent exactly this. They let you decouple deployment from release: push code to production whenever it's ready, then control who actually sees the new feature by flipping a toggle in GitLab. Start with your QA team using a "User IDs" strategy, then switch to a "10% percent rollout," then flip to "All users" when you're confident. If something goes wrong at any point, you turn it off in seconds. No redeployment, no hotfix, no bad press.

This tutorial walks through a working Flask application that reads GitLab feature flags through the Unleash Python SDK. A complete, runnable version of the code is available at gitlab.com/omid-blogs/gitlab-feature-flags-demo. Clone it into your own group or workspace, and you'll have live feature flag control in minutes.

By the end, you'll understand how the integration works and have a template you can drop straight into your own projects.

What you'll need

• A GitLab project (Free, Premium, or Ultimate) with feature flags enabled. This is where you'll create and manage your flags. To enable it, go to your project and navigate to Settings > General > Visibility, project features, permissions and make sure the Feature Flags toggle is on.
• The demo repo forked into your own GitLab namespace, then cloned locally

How GitLab feature flags work under the hood

GitLab exposes an Unleash-compatible API for every project. That means any Unleash client SDK (Go, Ruby, Python, JavaScript, and more) can connect directly to GitLab without a separate Unleash server.

On startup, the SDK fetches all flag definitions, then re-fetches on a configurable interval (the demo uses 15 seconds). Every call to is_enabled() evaluates locally against the cached configuration with no network call per flag check. That makes flag evaluation near-instant and resilient to transient network issues.

Here are the steps to take to integrate GitLab feature flags into a Python Flask app using the Unleash SDK.

1. Set up your GitLab project and clone the demo

You'll need:

• Your own GitLab project to host the feature flags
• The demo repo cloned locally to run the app

Fork or clone the demo repo

Go to gitlab.com/omid-blogs/gitlab-feature-flags-demo and fork it into your own GitLab namespace. This gives you a personal copy of the project where you can manage your own feature flags. Then clone it locally and open it in your favorite IDE:

git clone https://gitlab.com/<your-namespace>/gitlab-feature-flags-demo.git
cd gitlab-feature-flags-demo

What's inside the repo

.
├── app.py                # Flask app + Unleash SDK integration
├── requirements.txt      # Python dependencies
├── .env.example          # Template for required environment variables
├── .gitignore
├── templates/
│   └── index.html        # Web UI template
└── static/
    └── styles.css        # Styling

2. Create your feature flags in GitLab

Open your own GitLab project and navigate to Deploy > Feature Flags, then click New feature flag. Create the following four flags, setting each status to Active with a strategy of All users.

• dark_mode — Switches the page to a dark color scheme.
• holiday_banner — Shows a festive banner at the top of the page.
• new_layout — Switches the card grid to a single-column layout.
• fun_fonts — Swaps the body font to a playful handwritten style.

Tip: A flag must be Active and have at least one strategy to evaluate as enabled. Without a strategy, the SDK treats the flag as disabled even if it's marked "Active."

Understanding strategies

"All users" is a simple on/off toggle, but GitLab supports several more out of the box:

• Percent rollout (recommended): Gradually roll out to a percentage of users based on user ID, session ID, or randomly. This is the most flexible option and the one to reach for first.
• Percent of users: Enable for a percentage of authenticated users. Less flexible than Percent rollout since it only works with logged-in users.
• User IDs: Enable for specific user IDs only, great for internal testing with a named group.
• User list: Enable for a predefined list of users.
• All users: Enable for everyone.

Strategies are where feature flags get really powerful. Start with your QA team using a User IDs strategy, switch to a 10% percent rollout, then flip to All users when you're confident. All from the GitLab UI, no code changes required.

3. Get your Unleash credentials

On the Feature Flags page, click Configure in the top-right corner. You'll see two values:

• API URL: https://gitlab.com/api/v4/feature_flags/unleash/<your-project-id>
• Instance ID: A unique token scoped to your project

Copy both values. You'll pass them to the app as environment variables. Note that the Instance ID is read-only. It can only fetch flag state, not modify anything, but still treats the Instance ID as a secret to prevent information disclosure.

4. Set up the project locally

The README has the full setup walkthrough, but the short version is:

pip install -r requirements.txt

Then set your credentials. You can do this one of two ways:

Option A: Using the .env file (recommended)

The repo includes a .env.example file. Copy it and fill in your values:

cp .env.example .env

Open .env in your editor and replace the placeholder values with your credentials from Step 3:

UNLEASH_URL=https://gitlab.com/api/v4/feature_flags/unleash/<your-project-id>
UNLEASH_INSTANCE_ID=<your-instance-id>
UNLEASH_APP_NAME=production

Then export them:

export $(grep -v '^#' .env | xargs)

Option B: Export directly in your terminal

export UNLEASH_URL="https://gitlab.com/api/v4/feature_flags/unleash/<your-project-id>"
export UNLEASH_INSTANCE_ID="<your-instance-id>"
export UNLEASH_APP_NAME="production"

Never commit your .env file to version control. The .gitignore in the repo already excludes it, but it's worth knowing why: your Instance ID is a secret and should stay out of git history.

Three environment variables drive the entire integration:

UnleashClient is the key dependency. It's the official Unleash Python SDK that handles polling, caching, and local flag evaluation so you don't have to build any of that yourself.

5. Understand the application

Before running it, read through app.py. Here are the key patterns worth understanding so you can replicate them in your own projects.

Initializing the SDK

unleash_client = UnleashClient(
    url=UNLEASH_URL,
    app_name=UNLEASH_APP_NAME,
    instance_id=UNLEASH_INSTANCE_ID,
    refresh_interval=15,
    metrics_interval=60,
)

unleash_client.initialize_client()

No personal access tokens, no credentials hardcoded in source. The app exits immediately with a clear error message if either required variable is missing.

Checking a flag

def is_flag_enabled(flag_name):
    return unleash_client.is_enabled(flag_name)

Because the SDK caches flag definitions in memory, is_enabled() returns instantly with no network roundtrip.

Gating real behavior behind flags

The index route builds a feature dictionary, evaluating each flag and passing the results to the template:

features = {}
for flag_name, config in feature_configs.items():
    features[flag_name] = {
        **config,
        'enabled': is_flag_enabled(flag_name)
    }

return render_template('index.html', features=features)

The template uses those values to conditionally apply CSS classes and render UI elements. dark_mode toggles a body class, holiday_banner shows or hides a banner element entirely. Open templates/index.html to see how it's wired together.

Note that index.html also auto-refreshes every 30 seconds via a small JavaScript snippet, so you can watch flag changes take effect without manually reloading.

Passing user context for targeted strategies

When you're ready to move beyond All users and use Percentage rollouts or User targeting, pass a context object to is_enabled():

unleash_client.is_enabled(
    'new_layout',
    context={'userId': current_user.id}
)

The SDK handles consistent hashing for percentage rollouts automatically. No math required on your end.

6. Run the app

python3 app.py

Visit http://localhost:8080. You should see all four feature cards showing their current enabled/disabled state.

7. Toggle flags in real time

Go back to Deploy > Feature Flags in GitLab and toggle one of the flags. Try dark_mode or holiday_banner for the most visible effect. Wait about 15 seconds, then reload the page. The card updates to reflect the new state, and if you toggled dark_mode on, the entire page switches to a dark theme. Toggle it back off, wait, reload, and it snaps back instantly.

This is the core value of feature flags: You control application behavior from GitLab without touching code or redeploying.

Why the Unleash SDK instead of the GitLab REST API?

For an app that evaluates flags on every request, the SDK is the clear winner. It's faster, simpler, and the Instance ID it uses carries no permissions beyond reading flag state. That's a much smaller security footprint than a PAT.

Troubleshooting

A note on rate limits in production

The 15-second polling interval works well for development and small deployments. With all clients polling from the same IP, GitLab.com can support around 125 clients at a 15-second interval before hitting rate limits. If you're building a larger production app, consider running an Unleash Proxy in front of your clients. It batches requests to GitLab on behalf of all your instances and dramatically reduces upstream traffic.

Security considerations

1. debug=False is already set in the demo: Keep it that way. Flask's debug mode exposes an interactive debugger that allows remote code execution.
2. Keep dependencies updated: The requirements.txt pins specific versions. Enable GitLab Dependency Scanning in your CI/CD pipeline to stay on top of vulnerabilities.
3. Use environment variables for credentials: Never hardcode the Instance ID or any tokens in source code. The demo's .env.example shows the right pattern.
4. The Instance ID is read-only: It can only fetch flag state, not modify it. Still treat it as a secret.

Summary

This tutorial covered the full lifecycle of integrating GitLab feature flags into a Python application: creating flags with the right strategies, retrieving Unleash credentials, initializing the SDK, evaluating flags locally in Flask, and toggling behavior in real time without a redeployment.

The entire integration requires one dependency (UnleashClient), three environment variables, and a single method call (is_enabled()). No separate Unleash server, no personal access tokens, no complex infrastructure.

Feature flags are one of the most practical tools available for reducing deployment risk. The ability to instantly disable a broken feature, or progressively roll one out from a targeted user group to a percentage to everyone, without touching a deployment pipeline, delivers outsized value for minimal setup. The demo repo provides a working foundation to fork and adapt for any project.

Resources

• Demo project on GitLab
• GitLab Feature Flags documentation
• Unleash Python SDK on GitHub
• Unleash SDKs (all languages)

GitLab's auto-dismiss vulnerability policies let you codify your triage decisions once and apply them automatically on every default-branch pipeline. Define criteria based on file path, directory, or vulnerability identifier (CVE, CWE), choose a dismissal reason, and let GitLab handle the rest.

Why auto-dismiss?

Auto-dismiss vulnerability policies enable security teams to:

• Eliminate triage noise: Automatically dismiss findings in test code, vendored dependencies, and generated files.
• Enforce decisions at scale: Apply policies centrally to dismiss known false positives across your entire organization.
• Maintain audit transparency: Every auto-dismissed finding includes a documented reason and links back to the policy that triggered it.
• Preserve the record: Unlike scanner exclusions, dismissed vulnerabilities remain in your report, so you can revisit decisions if conditions change.

How auto-dismiss policies work

1. Define your policy in a vulnerability management policy YAML file. Specify match criteria (file path, directory, or identifier) and a dismissal reason.
2. Merge and activate. Create the policy via Secure > Policies > New policy > Vulnerability management policy. Merge the MR to enable it.
3. Run your pipeline. On every default-branch pipeline, matching vulnerabilities are automatically set to "Dismissed" with the specified reason. Up to 1,000 vulnerabilities are processed per run.
4. Measure the impact. Filter your vulnerability report by status "Dismissed" to see exactly what was cleaned up and validate that the right findings are being handled.

Use cases with ready-to-use configurations

Each example below includes a policy configuration you can copy, customize, and apply immediately.

1. Dismiss test code vulnerabilities

SAST and dependency scanners flag hardcoded credentials, insecure fixtures, and dev-only dependencies in test directories. These are not production risks.

vulnerability_management_policy:
  - name: "Dismiss test code vulnerabilities"
    description: "Auto-dismiss findings in test directories"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: file_path
            value: "test/**/*"
      - type: detected
        criteria:
          - type: file_path
            value: "tests/**/*"
      - type: detected
        criteria:
          - type: file_path
            value: "spec/**/*"
      - type: detected
        criteria:
          - type: directory
            value: "__tests__/*"
    actions:
      - type: auto_dismiss
        dismissal_reason: used_in_tests

2. Dismiss vendored and third-party code

Vulnerabilities in vendor/, third_party/, or checked-in node_modules are managed upstream and not actionable for your team.

vulnerability_management_policy:
  - name: "Dismiss vendored dependency findings"
    description: "Findings in vendored code are managed upstream"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: directory
            value: "vendor/*"
      - type: detected
        criteria:
          - type: directory
            value: "third_party/*"
      - type: detected
        criteria:
          - type: directory
            value: "vendored/*"
    actions:
      - type: auto_dismiss
        dismissal_reason: not_applicable

3. Dismiss known false positive CVEs

Certain CVEs are repeatedly flagged but don't apply to your usage context. Teams dismiss these manually every time they appear. Replace the example CVEs below with your own.

vulnerability_management_policy:
  - name: "Dismiss known false positive CVEs"
    description: "CVEs confirmed as false positives for our environment"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: identifier
            value: "CVE-2023-44487"
      - type: detected
        criteria:
          - type: identifier
            value: "CVE-2024-29041"
      - type: detected
        criteria:
          - type: identifier
            value: "CVE-2023-26136"
    actions:
      - type: auto_dismiss
        dismissal_reason: false_positive

4. Dismiss generated and auto-created code

Protobuf, gRPC, OpenAPI generators, and ORM scaffolding tools produce files with flagged patterns that cannot be patched by your team.

vulnerability_management_policy:
  - name: "Dismiss generated code findings"
    description: "Generated files are not authored by us"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: directory
            value: "generated/*"
      - type: detected
        criteria:
          - type: file_path
            value: "**/*.pb.go"
      - type: detected
        criteria:
          - type: file_path
            value: "**/*.generated.*"
    actions:
      - type: auto_dismiss
        dismissal_reason: not_applicable

5. Dismiss infrastructure-mitigated vulnerabilities

Vulnerability classes like XSS (CWE-79) or SQL injection (CWE-89) that are already addressed by WAF rules or runtime protection. Only use this when mitigating controls are verified and consistently enforced.

vulnerability_management_policy:
  - name: "Dismiss CWEs mitigated by WAF"
    description: "XSS and SQLi mitigated by WAF rules"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: identifier
            value: "CWE-79"
      - type: detected
        criteria:
          - type: identifier
            value: "CWE-89"
    actions:
      - type: auto_dismiss
        dismissal_reason: mitigating_control

6. Dismiss CVE families across your organization

A wave of related CVEs for a widely-used library your team has assessed? Apply at the group level to dismiss them across dozens of projects. The wildcard pattern (e.g., CVE-2021-44*) matches all CVEs with that prefix.

vulnerability_management_policy:
  - name: "Accept risk for log4j CVE family"
    description: "Log4j CVEs mitigated by version pinning and WAF"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: identifier
            value: "CVE-2021-44*"
    actions:
      - type: auto_dismiss
        dismissal_reason: acceptable_risk

Quick reference

Getting started

Here's how to get started with auto-dismiss policies:

1. Identify the noise. Open your vulnerability report and sort by "Needs triage." Look for patterns: test files, vendored code, the same CVE across projects.
2. Pick a scenario. Start with whichever use case above accounts for the most findings.
3. Record your baseline. Note the number of "Needs triage" vulnerabilities before creating a policy.
4. Create and enable. Navigate to Secure > Policies > New policy > Vulnerability management policy. Paste the configuration from the use case above, then merge the MR.
5. Validate results. After the next default-branch pipeline, filter by status "Dismissed" to confirm the right findings were handled.

For full configuration details, see the vulnerability management policy documentation.

Ready to take control of vulnerability noise? Start a free GitLab Ultimate trial and configure your first auto-dismiss policy today.

These capabilities help save time and effort by:

• Eliminating repetitive filter setup for common workflows
• Ensuring consistency in how teams view and assess work
• Facilitating standardized reporting and status checks

What are work items?

Previously, epics and issues lived on separate list pages, requiring users to navigate between them. The work items list combines epics, issues, and other work items into a single, unified list experience, eliminating the need to switch between separate pages for different work item types.

This is also the foundation for deeper planning capabilities coming in the future. Bringing all work item types into one place paves the way for hierarchy views (like a Table view) that will make it easier to visualize relationships and structure across epics, issues, and other items at a glance.

Beyond list and hierarchy views, we also plan to consolidate other common workflows, like Boards, into this unified experience. The result: all of your essential planning views in one place, shareable with your team through saved views, without needing to navigate across different parts of the product.

You may be wondering why we call these "work items" rather than issues. The short answer is that "issue" doesn't scale to where we're going. Soon, you'll be able to fully configure your work item types, including their names, to match your organization's planning hierarchy. Locking the experience to legacy naming would work against that flexibility. "Work items" is the foundation for a model you can make your own.

What led to the change to work items?

In 2024, we shared our vision for a new Agile planning experience in GitLab, powered by the work items framework. That post outlined the core problem: Epics and issues existed as separate experiences, creating friction for teams who expected consistent functionality across planning objects. The work items framework was our answer — a unified architecture designed to deliver consistency and unlock new capabilities across GitLab's planning tools. Work items list and saved views are a step in that journey.

What are saved views?

Saved views allow users to save and return to customized list configurations, including filters, sort order, and display options. The goal is to make routine checks more efficient and to support consistent, standardized ways of viewing work across a team.

What's next

To understand why we are making the changes we are, it helps to picture where we're headed.

The goal isn't just a work items list; it's a planning experience that lets you move fluidly between different types of views (list, board, table, and more) while retaining your current filter scope.

Pair that with saved views, and you can create a dedicated view for each of your workflows: iteration planning, backlog refinement, portfolio-level planning with nested table views, and more.

Each view is ready to go, consistent in how it filters and displays work, and shareable with your team. This framework also sets the stage for more powerful capabilities down the road, including full swimlane support for any work item attribute in boards.

We know that changes to the tools you use every day can be disruptive. If you've built workflows around the existing epic and issue list pages, this will look and feel different. That's not something we take lightly.

This direction wasn't a decision we made quickly. It reflects years of feedback, a significant architectural investment in the work items framework, and a genuine belief that a unified experience will serve teams better in the long run. We expect the transition to take some adjustment, and we'll continue to iterate based on what we hear from you!

Share your feedback

We encourage you try these new capabilities. Then, please reach out about your work items list and saved views experience in our feedback issue. Your comments will help us further improve these capabilities.

Here is what’s new:

• Static Application Security Testing (SAST) false positive detection is now generally available. This flow uses an LLM for agentic reasoning to determine the likelihood that a vulnerability is a false positive or not, so security and development teams can focus on remediating critical vulnerabilities first.
• Agentic SAST vulnerability resolution is now in beta. Agentic SAST vulnerability resolution automatically creates a merge request with a proposed fix for verified SAST vulnerabilities, which can shorten time to remediation and reduce the need for deep security expertise.
• Secret false positive detection is now in beta. This flow brings the same AI-powered noise reduction to secret detection, flagging dummy and test secrets to save review effort.

These flows are available to GitLab Ultimate customers using GitLab Duo Agent Platform.

Cut triage time with SAST false positive detection

Traditional SAST scanners flag every suspicious code pattern they find, regardless of whether code paths are reachable or frameworks already handle the risk. Without runtime context, they cannot distinguish a real vulnerability from safe code that just looks dangerous.

This means developers could spend hours investigating findings that turn out to be false positives. Over time, that can erode confidence in the report and slow down the teams responsible for fixing real risks.

After each SAST scan, GitLab Duo Agent Platform automatically analyzes new critical and high severity findings and attaches:

• A confidence score indicating how likely the finding is to be a false positive
• An AI-generated explanation describing the reasoning
• A visual badge that makes “Likely false positive” versus “Likely real” easy to scan in the UI

These findings appear in the Vulnerability Report, as shown below. You can filter the report to focus on findings marked as “Not false positive” so teams can spend their time addressing real vulnerabilities instead of sifting through noise.

GitLab Duo Agent Platform's assessment is a recommendation. You stay in control of every false positive to determine if it is valid, and you can audit the agent's reasoning at any time to build confidence in the model.

Turn vulnerabilities into automated fixes

Knowing that a vulnerability is real is only half the work. Remediation still requires understanding the code path, writing a safe patch, and making sure nothing else breaks.

If the vulnerability is identified as likely not be a false positive by the SAST false positive detection flow, the Agentic SAST vulnerability resolution flow automatically:

1. Reads the vulnerable code and surrounding context from your repository
2. Generates high-quality proposed fixes
3. Validates fixes through automated testing
4. Opens a merge request with a proposed fix that includes:
   • Concrete code changes
   • A confidence score
   • An explanation of what changed and why

In this demo, you’ll see how GitLab can automatically take a SAST vulnerability all the way from detection to a ready-to-review merge request. Watch how the agent reads the code, generates and validates a fix, and opens an MR with clear, explainable changes so developers can remediate faster without being security experts.

As with any AI-generated suggestion, you should review the proposed merge request carefully before merging.

Surface real secrets

Secret detection is only useful if teams trust the results. When reports are full of test credentials, placeholder values, and example tokens, developers may waste time reviewing noise instead of fixing real exposures. That can slow remediation and decrease confidence in the scan.

Secret false positive detection helps teams focus on the secrets that matter so they can reduce risk faster. When it runs on the default branch, it will automatically:

1. Analyze each finding to spot likely test credentials, example values, and dummy secrets
2. Assign a confidence score for whether the finding is a real risk or a likely false positive
3. Generate an explanation for why the secret is being treated as real or noise
4. Add a badge in the Vulnerability Report so developers can see the status at a glance

Developers can also trigger this analysis manually from the Vulnerability Report by selecting “Check for false positive” on any secret detection finding, helping them clear out findings that do not pose risk and focus on real secrets sooner.

Try AI-powered security today

GitLab 18.10 introduces capabilities that cover the full vulnerability workflow, from cutting false positive noise in SAST and secret detection to automatically generating merge requests with proposed fixes.

To see how AI-powered security can help cut review time and turn findings into ready-to-merge fixes, start a free trial of GitLab Duo Agent Platform today.

That changes with GitLab 18.10. Starting today, Free GitLab.com teams can purchase a monthly commitment of GitLab Credits and start using GitLab Duo Agent Platform immediately. No subscription upgrade required. This is a full entry point to agentic AI for teams that aren’t ready to add a GitLab plan, but are ready to start building with AI.

The model is simple: pay for what AI does, not how many people use it. Your group owner purchases a monthly credit commitment of GitLab Credits through your group’s billing settings. Your entire team gets access to the same AI agents and flows that GitLab Premium and Ultimate customers use for planning, code generation, automated code review, and pipeline diagnosis, all drawing from a shared credit pool.

The GitLab Credits dashboard gives group owners visibility into which agents and flows are consuming credits, so you can connect AI spend directly to the work it's producing.

Day Zero with GitLab Duo Agent Platform

Once your group owner purchases credits, every member of the team can start using GitLab Duo Agent Platform right away.

Here's how a typical workflow plays out:

You start with a feature request for your software. Open Planner Agent in Agentic Chat and describe what you need in plain language. The agent breaks it down into structured work items: issues with descriptions, labels, and relationships. They are all created directly in your project. What used to be an afternoon of manual issue grooming takes minutes.

Pick up one of those issues and assign Developer Flow to begin work. The agent reads the issue context, generates code aligned to the requirements, runs tests, and opens a merge request for review. You can also use Agentic Chat for more iterative work, whether you’re refactoring, extending, or explaining code within your project's context.

When the merge request is ready, Code Review Flow runs a multi-step automated review: scanning the changes, pulling in repository context, and posting structured inline feedback tied to the diff. Your human reviewers can skip the first-pass mechanics and focus on architecture and business logic.

And if the pipeline breaks, Fix CI/CD Pipeline Flow reads the failure logs, traces the error to its root cause, and proposes a fix. Instead of manually stepping through job logs, your team gets a starting point for resolution.

GitLab’s Duo Agent Platform takes software development from iteration to deployment, powered by one credit pool.

It's simple to get started with agents and flows, from plan to deploy in under 3 minutes. Watch this demo to learn how:

Flat-rate code review: Predictable costs as you scale

Of all the workflows available through GitLab Duo Agent Platform, automated code review is where teams see value the fastest, and where predictable pricing matters most.

Code Review Flow now costs a flat 0.25 GitLab Credits per review, regardless of merge request size, repository complexity, or how many steps the flow runs internally. Four reviews equal one credit. Whether your team merges 500 requests a month or 50,000, you can forecast costs directly in terms of reviews.

The math is worth a closer look. Manual code reviews don’t just cost money, they take time and add disruption in development with constant context-switching. The time saved with the Code Review Flow could mean substantial savings as review volume grows. Now you have the potential to run hundreds of reviews simultaneously rather than having them sit in a queue. That means the time savings quickly compound with the cost savings.

For teams on GitLab’s Free tier, this means you know exactly what portion of your monthly credit pool goes to code review and can plan accordingly.

Learn more about how Code Review Flow works and what it means for scaling your engineering organization.

Why Premium multiplies the value

GitLab Credits on the Free tier give your team a direct path to agentic AI. If your team relies on GitLab for more, Premium is where the economics and the capabilities come together.

At $29 per user per month, GitLab Premium includes 12 GitLab Credits per user as a promotional offer. For a team of 20, that's 240 credits per month before you spend anything extra, enough to cover roughly 960 automated code reviews, or a mix of code review, planning, development flows, and pipeline fixes.

GitLab Duo Agent Platform is only a part of what Premium gives you. You also get advanced CI/CD for high-volume pipelines, merge approvals and code owners for governance, and AI that runs within a single data layer with unified context across your projects.

If your team is spending credits on Free and finding that AI is becoming central to your workflow, Premium is the natural next step with the included promotional credits. It offers more platform capability, and a foundation that scales with you.

Get started today

GitLab 18.10 is available now. Whether your team needs agentic AI to move faster or the full platform to support how you already work, there's a clear path for accelerating your software development process.

• Free GitLab.com teams: Purchase a monthly commitment of GitLab Credits through your group billing settings and start using GitLab Duo Agent Platform today.
• Teams ready for the full platform: Find the right GitLab subscription for your team, or start a free trial of GitLab Ultimate.

Getting credits set up for your team is fast and easy. Watch this demo to learn how:

FAQ

What is a monthly commitment of GitLab Credits?

A monthly commitment is a usage-based purchase option where your group owner selects a set number of credits that apply as a shared pool across the group. Credits are consumed when your team uses GitLab Duo Agent Platform capabilities. Learn more in the GitLab Credits documentation.

Who can purchase GitLab Credits today?

GitLab Premium and Ultimate customers already receive promotional credits included with their subscription. Starting in 18.10, Free GitLab.com top-level group namespaces can also purchase a monthly commitment of credits through self-serve group billing. For the latest on eligibility, see the GitLab Credits documentation.

What AI capabilities do credits unlock on Free?

Teams with credits get access to the same agentic AI capabilities and models available to Premium and Ultimate customers, including Planner Agent, Developer Flow, Code Review Flow, Fix CI/CD Pipeline Flow, Agentic Chat, Code Suggestions, custom agents and flows, and more. For the full list, see the Duo Agent Platform documentation.

How much does automated code review cost?

Code Review Flow charges a flat rate of 0.25 GitLab Credits per review, regardless of merge request size or complexity. For current pricing details, see the Code Review Flow documentation.

Can I upgrade from Free with credits to GitLab Premium?

In GitLab 18.10, upgrading from a Free namespace with a monthly credit commitment to Premium is available through a sales-assisted path. Contact the GitLab sales team to explore your options.

The industry is responding with AI-powered review tools, but most come with a catch: unpredictable, token-based pricing that makes it hard to turn them on everywhere. Some of the new ones cost as much as $15 to $25 per review depending on the size and complexity of the change. At that price, teams ration reviews to high-priority changes and the queue stays long.

Code Review Flow, an agentic AI capability within GitLab Duo Agent Platform, costs $0.25 per review. Flat rate. Every merge request, every project, every time.

How it works

When a merge request is opened, Code Review Flow automatically runs a multi-step review: scanning changes, exploring relevant repository context, checking against your pipeline, security findings, and compliance requirements, then generating structured inline feedback.

The result is a review grounded in what's actually happening in your project, not just what changed in the diff. And because it runs inside GitLab, you get something standalone tools can't offer: hundreds of reviews running in parallel across your entire organization, not one at a time in one engineer's IDE.

See Code Review in action with this demo:

Simple math, real savings

Each review costs 0.25 GitLab Credits ($0.25 at list pricing). Four reviews, one credit. Whether your team merges 500 MRs a month or 50,000, the math is the same.

No token estimation. No bill surprises based on merge request complexity. Just a flat cost per review that you can forecast in a spreadsheet.

For context: If a manual code review takes roughly 15 minutes of a senior engineer's time, that's about $25 in engineering cost. At $0.25 per automated review, that's a 99% reduction in per-review cost. And because reviews run in parallel rather than sitting in a queue, you're not just saving money. You're getting merge requests unblocked in minutes instead of hours.

Why flat-rate changes the game

At variable pricing, teams pick and choose which MRs get AI review. At $0.25, you stop choosing. You turn it on for everything.

Every MR, every project. Set Code Review Flow to trigger automatically on every merge request. Let the agent handle the queue while your engineers focus on architecture and mentorship.

Consistent standards at scale. Define custom merge review instructions per project. One project uses the built-in flow. Another uses Claude Code or Codex. A third runs a custom agent. All of it runs in parallel, each aligned to its own guardrails, all visible in one place.

Unblock the review queue. The bottleneck in modern software delivery isn't writing code — it's waiting for someone to review it. Flat-rate, parallel AI review turns a days-long queue into a minutes-long process.

New to GitLab Credits? GitLab Credits are the unit of consumption for Duo Agent Platform usage. 1 Credit = $1. Learn more about how GitLab Credits work.

Get started today

The $0.25 flat-rate pricing for Agentic Code Review is available now if you’re using GitLab Duo Agent Platform on GitLab.com, Dedicated, or on self-managed instances running 18.8.4 or later. Enable Code Review Flow by default now for every merge request your teams create.

Start a free trial of GitLab Duo Agent Platform to see it in action, or, if you are a GitLab customer, reach out to your account representative with questions.

"Security says we need to use hardened base images."

"Great, where do I configure credentials for yet another registry?"

"Also, how do we make sure everyone actually uses them?"

Or this one:

"Why are our builds so slow?"

"We're pulling the same 500MB image from Docker Hub in every single job."

"Can't we just cache these somewhere?"

I've been working on Container Virtual Registry at GitLab specifically to solve these problems. It's a pull-through cache that sits in front of your upstream registries — Docker Hub, dhi.io (Docker Hardened Images), MCR, and Quay — and gives your teams a single endpoint to pull from. Images get cached on the first pull. Subsequent pulls come from the cache. Your developers don't need to know or care which upstream a particular image came from.

This article shows you how to set up Container Virtual Registry, specifically with Docker Hardened Images in mind, since that's a combination that makes a lot of sense for teams concerned about security and not making their developers' lives harder.

What problem are we actually solving?

The Platform teams I usually talk to manage container images across three to five registries:

• Docker Hub for most base images
• dhi.io for Docker Hardened Images (security-conscious workloads)
• MCR for .NET and Azure tooling
• Quay.io for Red Hat ecosystem stuff
• Internal registries for proprietary images

Each one has its own:

• Authentication mechanism
• Network latency characteristics
• Way of organizing image paths

Your CI/CD configs end up littered with registry-specific logic. Credential management becomes a project unto itself. And every pipeline job pulls the same base images over the network, even though they haven't changed in weeks.

Container Virtual Registry consolidates this. One registry URL. One authentication flow (GitLab's). Cached images are served from GitLab's infrastructure rather than traversing the internet each time.

How it works

The model is straightforward:

Your pipeline pulls:
  gitlab.com/virtual_registries/container/1000016/python:3.13

Virtual registry checks:
  1. Do I have this cached? → Return it
  2. No? → Fetch from upstream, cache it, return it

You configure upstreams in priority order. When a pull request comes in, the virtual registry checks each upstream until it finds the image. The result gets cached for a configurable period (default 24 hours).

┌─────────────────────────────────────────────────────────┐
│                    CI/CD Pipeline                       │
│                          │                              │
│                          ▼                              │
│   gitlab.com/virtual_registries/container/<id>/image   │
└─────────────────────────────────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────┐
│            Container Virtual Registry                   │
│                                                         │
│  Upstream 1: Docker Hub ────────────────┐               │
│  Upstream 2: dhi.io (Hardened) ────────┐│               │
│  Upstream 3: MCR ─────────────────────┐││               │
│  Upstream 4: Quay.io ────────────────┐│││               │
│                                      ││││               │
│                    ┌─────────────────┴┴┴┴──┐            │
│                    │        Cache          │            │
│                    │  (manifests + layers) │            │
│                    └───────────────────────┘            │
└─────────────────────────────────────────────────────────┘

Why this matters for Docker Hardened Images

Docker Hardened Images are great because of the minimal attack surface, near-zero CVEs, proper software bills of materials (SBOMs), and SLSA provenance. If you're evaluating base images for security-sensitive workloads, they should be on your list.

But adopting them creates the same operational friction as any new registry:

• Credential distribution: You need to get Docker credentials to every system that pulls images from dhi.io.
• CI/CD changes: Every pipeline needs to be updated to authenticate with dhi.io.
• Developer friction: People need to remember to use the hardened variants.
• Visibility gap: It's difficult to tell if teams are actually using hardened images vs. regular ones.

Virtual registry addresses each of these:

Single credential: Teams authenticate to GitLab. The virtual registry handles upstream authentication. You configure Docker credentials once, at the registry level, and they apply to all pulls.

No CI/CD changes per-team: Point pipelines at your virtual registry. Done. The upstream configuration is centralized.

Gradual adoption: Since images get cached with their full path, you can see in the cache what's being pulled. If someone's pulling library/python:3.11 instead of the hardened variant, you'll know.

Audit trail: The cache shows you exactly which images are in active use. Useful for compliance, useful for understanding what your fleet actually depends on.

Setting it up

Here's a real setup using the Python client from this demo project.

Create the virtual registry

from virtual_registry_client import VirtualRegistryClient

client = VirtualRegistryClient()

registry = client.create_virtual_registry(
    group_id="785414",  # Your top-level group ID
    name="platform-images",
    description="Cached container images for platform teams"
)

print(f"Registry ID: {registry['id']}")
# You'll need this ID for the pull URL

Add Docker Hub as an upstream

For official images like Alpine, Python, etc.:

docker_upstream = client.create_upstream(
    registry_id=registry['id'],
    url="https://registry-1.docker.io",
    name="Docker Hub",
    cache_validity_hours=24
)

Add Docker Hardened Images (dhi.io)

Docker Hardened Images are hosted on dhi.io, a separate registry that requires authentication:

dhi_upstream = client.create_upstream(
    registry_id=registry['id'],
    url="https://dhi.io",
    name="Docker Hardened Images",
    username="your-docker-username",
    password="your-docker-access-token",
    cache_validity_hours=24
)

Add other upstreams

# MCR for .NET teams
client.create_upstream(
    registry_id=registry['id'],
    url="https://mcr.microsoft.com",
    name="Microsoft Container Registry",
    cache_validity_hours=48
)

# Quay for Red Hat stuff
client.create_upstream(
    registry_id=registry['id'],
    url="https://quay.io",
    name="Quay.io",
    cache_validity_hours=24
)

Update your CI/CD

Here's a .gitlab-ci.yml that pulls through the virtual registry:

variables:
  VIRTUAL_REGISTRY_ID: <your_virtual_registry_ID>

  
build:
  image: docker:24
  services:
    - docker:24-dind
  before_script:
    # Authenticate to GitLab (which handles upstream auth for you)
    - echo "${CI_JOB_TOKEN}" | docker login -u gitlab-ci-token --password-stdin gitlab.com
  script:
    # All of these go through your single virtual registry
    
    # Official Docker Hub images (use library/ prefix)
    - docker pull gitlab.com/virtual_registries/container/${VIRTUAL_REGISTRY_ID}/library/alpine:latest
    
    # Docker Hardened Images from dhi.io (no prefix needed)
    - docker pull gitlab.com/virtual_registries/container/${VIRTUAL_REGISTRY_ID}/python:3.13
    
    # .NET from MCR
    - docker pull gitlab.com/virtual_registries/container/${VIRTUAL_REGISTRY_ID}/dotnet/sdk:8.0

Image path formats

Different registries use different path conventions:

Verify it's working

After some pulls, check your cache:

upstreams = client.list_registry_upstreams(registry['id'])
for upstream in upstreams:
    entries = client.list_cache_entries(upstream['id'])
    print(f"{upstream['name']}: {len(entries)} cached entries")

What the numbers look like

I ran tests pulling images through the virtual registry:

The first pull is the same speed (it has to fetch from upstream). Every pull after that, for the cache validity period, comes straight from GitLab's storage. No network hop to Docker Hub, dhi.io, MCR, or wherever the image lives.

For a team running hundreds of pipeline jobs per day, that's hours of cumulative build time saved.

Practical considerations

Here are some considerations to keep in mind:

Cache validity

24 hours is the default. For security-sensitive images where you want patches quickly, consider 12 hours or less:

client.create_upstream(
    registry_id=registry['id'],
    url="https://dhi.io",
    name="Docker Hardened Images",
    username="your-username",
    password="your-token",
    cache_validity_hours=12
)

For stable, infrequently-updated images (like specific version tags), longer validity is fine.

Upstream priority

Upstreams are checked in order. If you have images with the same name on different registries, the first matching upstream wins.

Limits

• Maximum of 20 virtual registries per group
• Maximum of 20 upstreams per virtual registry

Configuration via UI

You can also configure virtual registries and upstreams directly from the GitLab UI—no API calls required. Navigate to your group's Settings > Packages and registries > Virtual Registry to:

• Create and manage virtual registries
• Add, edit, and reorder upstream registries
• View and manage the cache
• Monitor which images are being pulled

What's next

We're actively developing:

• Allow/deny lists: Use regex to control which images can be pulled from specific upstreams.

This is beta software. It works, people are using it in production, but we're still iterating based on feedback.

Share your feedback

If you're a platform engineer dealing with container registry sprawl, I'd like to understand your setup:

• How many upstream registries are you managing?
• What's your biggest pain point with the current state?
• Would something like this help, and if not, what's missing?

Please share your experiences in the Container Virtual Registry feedback issue.

Related resources

• New GitLab metrics and registry features help reduce CI/CD bottlenecks
• Container Virtual Registry documentation
• Container Virtual Registry API

At GitLab, our Signals Engineering team is responsible for building and maintaining the detections that protect the platform and the company. We deal with the same detection gap problem that every security team does so we’ve automated detection gap analysis with GitLab Duo Agent Platform to improve our assessment of those gaps and how we can close them.

In this article, you'll learn our strategy, which includes two AI agents you can use in your environment: the built-in Security Analyst Agent and a custom agent we built and named the Detection Engineering Assistant.

The detection gap problem

A detection gap is exactly what it sounds like: an attacker took an action, and your detections didn't catch it. Gap analysis is the process of systematically reviewing security incidents to identify those missed opportunities and determine what new or improved detections would close them.

The challenge isn't that gap analysis is conceptually hard. It's that it requires careful, methodical reading of incident data and mapping those events to your detection coverage. For a single incident, a skilled analyst can do it well. But across a steady stream of incidents, with multiple engineers contributing, it's difficult to maintain consistency and easy to let the review become shallow.

We wanted a process that was repeatable, thorough, and embedded directly in the workflow where our security incidents already live: GitLab issues.

What is GitLab Duo Agent Platform?

GitLab Duo Agent Platform is GitLab's framework for building and deploying agentic AI agents that can reason, take actions, and integrate natively with GitLab resources like issues, merge requests, and code. Unlike a simple chat interface, agents in Duo Agent Platform can be given specific roles, domain knowledge, and access to tools, making them effective for domain-specific workflows like security operations.

GitLab Duo Agent Platform gives you two practical paths:

1. Use a pre-built agent — GitLab ships several out-of-the-box agents, including a Security Analyst Agent designed for security-related tasks.
2. Build your own agent — You can create a custom agent in just a few minutes by giving it a name, a description, and a system prompt. The system prompt is where the real power lies.

Both paths are viable for detection gap analysis. Let's look at each.

1. Security Analyst Agent

The easiest way to get started is with Security Analyst Agent, which comes pre-configured with security domain knowledge and can be invoked directly from a GitLab issue.

To use the agent for gap analysis, we navigate to a closed incident issue and ask the agent to review the incident description, timeline, tasks, and comments to identify where detections were absent or insufficient. The agent reads the issue content — including comments, linked artifacts, and timeline details — and reasons over it to surface potential gaps. It can identify undetected tactics, techniques, and procedures (TTPs) mapped to MITRE ATT&CK and suggest areas where new detection rules could improve coverage.

This works well for a quick first pass, especially if your incident issues are well-documented. Security Analyst Agent is knowledgeable about general security concepts, common attacker behaviors, and detection principles. For teams just getting started with AI-assisted operations, it provides immediate value with no configuration required.

That said, the pre-built agent doesn't know your specific environment, including your SIEM, your log sources, your detection stack, or your team's detection engineering standards. For us, that meant the recommendations, while valid in general, sometimes missed the specific context we needed to translate them into actionable detections. That's what led us to build our own agent.

2. Building the Detection Engineering Assistant

Creating a custom agent in GitLab Duo Agent Platform is surprisingly straightforward. From the Duo Agent Platform interface, you give the agent a name (we called ours the Detection Engineering Assistant), a brief description, and a system prompt. That's it. The agent is ready to use.

The system prompt is the most important part. It's the agent's knowledge base: everything it knows about your team, your environment, your standards, and how it should reason about its work. A thin, vague system prompt produces thin, vague output. A verbose, carefully crafted system prompt produces an agent that behaves like a knowledgeable member of your team.

Here's the approach we took when writing our system prompt for the Detection Engineering Assistant:

Define the agent's role and scope clearly

We opened the system prompt by telling the agent exactly what it is and what it's responsible for. Not just "you are a security analyst." We specifically prompted: "You are a detection engineering assistant for GitLab's Signals Engineering team, responsible for analyzing security incidents and identifying gaps in our detection coverage." This framing anchors every response it produces.

Encode your detection philosophy

We wrote out what "a good detection" means to us: low false positive rates, high signal fidelity, and actionable alerts that provide responders with the context they need. We explained our preference for behavioral detections over IOC-based detections where possible, and described how we think about the tradeoff between coverage breadth and alert fatigue.

Give it context on your tech stack and log sources

An agent can only recommend what you can actually build. We told the agent which log sources we ingest, what our SIEM looks like, and what data is and isn't available to us. This means when it recommends a new detection, it does so in terms of what we can actually implement, not hypothetical telemetry we don't have.

Ground it in MITRE ATT&CK

We told the agent to organize its gap findings using ATT&CK tactics and techniques. This gives us consistent, structured output that maps directly to how we track coverage internally, and makes it easy to prioritize which gaps to address first.

Set expectations for output format

We specified exactly what we want the agent to produce: a structured list of detection gaps, each with the relevant ATT&CK technique, a description of what was missed, the log source or data that could support a detection, and a recommended approach. A consistent output format makes the findings easier to triage and turn into engineering work.

Example system prompt excerpt

Note: Our full Detection Engineering Assistant system prompt is 1,870 words and 337 lines. The example below is just a small example of what a full custom system prompt can be.

You are the Detection Engineering Assistant for GitLab's Security Operations team. Your role is to analyze closed security incidents and identify gaps in our detection capabilities.

When reviewing an incident, you should:
1. Identify each distinct attacker action or technique described in the incident timeline
2. For each action, assess whether our existing detections would have caught it
3. For any action that would not have been detected, document it as a detection gap

For each gap, provide:
- MITRE ATT&CK Technique ID and name (e.g., T1078 - Valid Accounts)
- A plain-language description of what happened and why it wasn't detected
- The log source or telemetry that could support a detection (e.g., authentication logs, process execution events, network flow data)
- A recommended detection approach, written in terms our SIEM can implement

Our SIEM ingests [log sources]. Our detection standards prioritize behavioral patterns over static IOCs. Avoid recommending detections that would generate significant false positives without a high-confidence tuning path...

A system prompt this specific produces dramatically more useful output than a generic one. The agent stops giving you general security advice and starts giving you detection engineering recommendations.

Running gap analysis on incidents

With the Detection Engineering Assistant configured, the workflow is simple. At the close of an incident, we open the incident issue in GitLab and invoke the assistant. It reads the full issue — the incident summary, timeline, investigative notes, and any linked resources — and returns a structured gap analysis.

A typical output looks like this:

Gap: Lateral movement via valid credentials not detected

• ATT&CK: T1078.004 — Valid Accounts: Cloud Accounts
• What happened: An attacker used a valid access token to authenticate to an auxiliary GitLab instance. No alert fired because we lacked authentication baseline detections for that instance.
• Log source: Authentication logs from example.gitlab.com
• Recommended approach: Create a detection that alerts on first-time authentication from a user account to example.gitlab.com within a 90-day rolling window, with suppression for accounts with established access patterns.

This kind of structured output goes directly into our engineering backlog. We treat the agent's analysis as a high-quality first draft. It gets reviewed by a human engineer who validates the findings, checks whether gaps are already covered by detections we haven't documented, and adds context before it becomes an engineering issue. But the hard work of reading the incident and generating the initial findings is automated.

What we've learned

A few things stand out from building and iterating on this workflow:

The system prompt is a living document — Every time the agent produces an output that misses something obvious or gets the framing wrong, we update the prompt. The agent's quality is a direct reflection of how well we've encoded our domain knowledge into it.

Incident documentation quality matters — An agent can only reason over what's written down. Incidents with detailed, structured timelines produce much better gap analysis than sparse or informal ones. Building the gap analysis workflow created an unexpected second benefit: it gave us a concrete reason to improve our incident documentation standards.

This is a force multiplier, not a replacement — The Detection Engineering Assistant doesn't replace a skilled detection engineer, but it does amplify one. The engineer still reviews the findings, validates the recommendations, and makes the final call on what goes into the backlog. But the time spent on the initial analysis drops significantly, and the consistency across incidents improves.

Get started

If you want to build your own detection gap analysis agent, here's where to start:

1. Review your last three to five closed incidents and note what a good gap analysis would have surfaced for each.
2. Use those observations to draft a system prompt that encodes your environment, standards, and preferred output format.
3. Create a custom agent in GitLab Duo Agent Platform with your prompt.
4. Run it against one of your incidents and iterate on the prompt based on the output.

The detection gap problem isn't going away. But with GitLab Duo Agent Platform, you can make the analysis repeatable, consistent, and embedded directly in the place where your security work already happens.

Start a free trial of GitLab Duo Agent Platform today!

It works. It just gets old fast.

If you have ever wished the repository browser felt more like your IDE and less like a series of breadcrumb trails, the file tree browser in GitLab 18.9 is for you.

What the file tree browser does

The file tree browser adds a collapsible, resizable panel alongside your file and directory views so your project structure stays visible while you read and navigate code. No more losing your place. No more clicking back to figure out where you are.

It shows your project’s files and directories in a tree alongside the file list and file content so you can see structure and code at the same time.

If you have used a file tree in an IDE or a Git platform, it should feel familiar:

Navigate with structure

Expand and collapse directories and switch between files while keeping a clear view of where you are in the repository hierarchy. When you navigate directly to a nested file, the tree expands parent directories and highlights the current file so you do not lose context. The tree also synchronizes with your current location, so selecting a file in the main content area updates the tree to match.

Filter by filename

After opening the tree, press F to open the global search dialog. Type part of a filename to jump to it from the results list, with each result showing its parent directories so you know where you are landing.

Keyboard-first navigation

The tree implements the W3C ARIA treeview pattern, so you can move through files and directories entirely from the keyboard using arrow keys plus Enter, Space, Home, End, and character keys. That makes it more accessible for screen reader users and anyone who prefers to keep their hands on the keyboard.

Responsive across viewports

On a desktop, the tree sits side by side with your file list and code. On smaller viewports, it becomes a left-side drawer you can toggle open when you need it. On mobile, the tree is hidden so the code view can use the full screen.

Built for large repositories

For repositories with many entries, the tree uses pagination so you can load more items as needed without overwhelming the page. The experience stays responsive as your project grows.

See the file tree browser in action

Watch GitLab Principal Developer Advocate Michael Friedrich walk through the new file tree browser in GitLab and see how it makes navigating large repositories feel like working in your IDE. The demo uses the GitLab project: Tanuki IoT Platform project, which you can explore yourself to try the file tree in a real repository.

Try the file tree browser today

The file tree browser is available now on GitLab.com and was released in 18.9 for GitLab Self-Managed and GitLab Dedicated.

Here is how to get started:

1. Open any repository file or directory view in your project (/<project>/-/tree/<branch>).
2. In the upper left corner, select the file tree icon or press Shift+F to toggle the file tree browser.
3. Press F to filter files by name or extension, start typing, and use the arrow keys plus Enter to jump directly to the file you want.

What’s next

The Source Code team at GitLab built the file tree browser with accessibility, performance at scale, and cross-viewport consistency as core requirements. Those principles will continue to guide what comes next, and your feedback will help us shape future iterations.

Help us continue to improve the file tree browser

Share your thoughts about the file tree browser in our feedback issue.

Want to learn more about the file tree browser? Read the file tree browser documentation.

With GitLab Duo Agent Platform's MCP support, you can now connect Jira or any tool that supports MCP directly to your AI-powered development environment. Query issues, update tickets, and sync your workflow — all through natural language, without ever leaving your IDE.

What you'll learn

In this tutorial, we'll walk you through:

• Setting up the Jira/Atlassian OAuth application for secure authentication
• Configuring GitLab Duo Agent Platform as an MCP client
• Three practical use cases demonstrating real-world workflows

Prerequisites

Before getting started, ensure you have the following:

Understanding the architecture

GitLab Duo Agent Platform acts as an MCP client, connecting to the Atlassian MCP server to access your Jira project management data. Atlassian MCP server handles authentication, translates natural language requests into API calls, and returns structured data back to GitLab Duo Agent Platform — all while maintaining security and audit controls.

Part 1: Configure Jira OAuth application

To securely connect GitLab Duo Agent Platform to your Jira instance, you'll need to create an OAuth 2.0 application in the Atlassian Developer Console. This grants to GitLab the MCP server authorized access to your Jira data.

Setup steps

If you prefer to configure manually, follow these steps:

1. Navigate to the Atlassian Developer Console
   • Go to developer.atlassian.com/console/myapps
   • Sign in with your Atlassian account
2. Create a new OAuth 2.0 app
   • Click Create → OAuth 2.0 integration
   • Enter a name (e.g., "gitlab-dap-mcp")
   • Accept the terms and click Create
3. Configure permissions
   • Navigate to Permissions in the left sidebar.
   • Add Jira API and configure the following scopes:
     • read:jira-work — Read issues, projects, and boards
     • write:jira-work — Create and update issues
     • read:jira-user — Read user information
4. Set up authorization
   • Go to Authorization in the left sidebar
   • Add a callback URL for your environment (https://gitlab.com/oauth/callback)
   • Save your changes
5. Retrieve credentials
   • Navigate to Settings
   • Copy your Client ID and Client Secret
   • Store these securely — you'll need them for the MCP configuration

Interactive walkthrough: Jira OAuth setup

Click on the image below to get started.

Part 2: Configure GitLab Duo Agent Platform MCP client

With your OAuth credentials ready, you can now configure GitLab Duo Agent Platform to connect to the Atlassian MCP server.

Create your MCP configuration file

Create the MCP configuration file in your GitLab project at .gitlab/duo/mcp.json:

{
  "mcpServers": {
    "atlassian": {
      "type": "http",
      "url": "https://mcp.atlassian.com/v1/mcp",
      "auth": {
        "type": "oauth2",
        "clientId": "YOUR_CLIENT_ID",
        "clientSecret": "YOUR_CLIENT_SECRET",
        "authorizationUrl": "https://auth.atlassian.com/oauth/authorize",
        "tokenUrl": "https://auth.atlassian.com/oauth/token"
      },
      "approvedTools": true
    }
  }
}

Replace YOUR_CLIENT_ID and YOUR_CLIENT_SECRET with the credentials you generated in Part 1.

Enable MCP in GitLab

1. Navigate to your Group Settings → GitLab Duo → Configuration
2. Make sure “Allow external MCP tools” is checked

Verify the connection

Open your project in VS Code and ask in GitLab Duo Agent Platform chat:

What MCP tools do you have access to?

Then

Test the MCP JIRA configuration in this project

At this point you'll be redirected from the IDE to the MCP Atlassian website to approve access:

Verify with the MCP Dashboard

GitLab also provides a built-in MCP Dashboard directly in your IDE for this.

In VS Code or VSCodium, open the Command Palette (Cmd+Shift+P on macOS, Ctrl+Shift+P on Windows/Linux) and search for "GitLab: Show MCP Dashboard". The dashboard opens in a new editor tab and gives you:

• Connection status for each configured MCP server
• Available tools exposed by the server (e.g., jira_get_issue, jira_create_issue)
• Server logs so you can see exactly which tools are being called in real time

Interactive walkthrough: Testing MCP

Part 3: Use cases in action

Now that your integration is configured, let's explore three practical workflows that demonstrate the power of connecting Jira to GitLab Duo Agent Platform.

Planning assistant

Scenario: You're preparing for sprint planning and need to quickly assess the backlog, understand priorities, and identify blockers.

This demo shows you how to:

• Query the backlog
• Identify unassigned high-priority issues
• Get AI-powered sprint recommendations

Example prompts

Try these prompts in GitLab Duo Agent Platform Chat:

List all the unassigned issues in JIRA for project GITLAB

Suggest the two top issues to prioritize and summarize them. Assign them to me.

Interactive walkthrough: Project planning

Issue triage and creation from code

Scenario: While reviewing code, you discover a bug and want to create a Jira issue with relevant context — without leaving your IDE.

This demo walks you through:

• Identifying a bug while coding
• Creating a detailed Jira issue via natural language
• Auto-populating issue fields with code context
• Linking the issue to your current branch

Example prompts

Search in JIRA for a bug related to: Null pointer exception in PaymentService.processRefund().
If it does not exist create it with all the context needed from the code. Find possible blockers that this bug may cause.

Create a new branch called issue-gitlab-18, checkout, and link it to the issue we just created. Assign the JIRA issue to me and mark it as in-progress.

Interactive walkthrough: Bug review and task automation

Cross-system incident investigation

Scenario: A production incident occurs, and you need to correlate information from Jira (incident ticket), GitLab Project Management, your codebase, and merge requests to identify the root cause.

This demo demonstrates:

• Fetching incident details from Jira
• Correlating with recent merge requests in GitLab
• Identifying potentially related code changes
• Generating an incident timeline
• Design a remediation plan and create it as a work item in GitLab

Example prompts

"We have a production incident INC-1 about checkout failures. Can you help me investigate with all available context?"

Create a timeline of events for incident INC-1 including related Jira issues and recent deployments

Propose a remediation plan

Interactive walkthrough: Cross-system troubleshooting and remediation

Troubleshooting

These are some common setup issues and quick fixes:

For detailed troubleshooting, see the GitLab MCP clients documentation.

Security considerations

When integrating Jira with GitLab Duo Agent Platform:

• OAuth tokens — Make sure credentials remain secure
• Principle of least privilege — Only grant the minimum required Jira scopes
• Token rotation — Regularly rotate your OAuth credentials as part of security hygiene

Summary

Connecting GitLab Duo Agent Platform to different tools through MCP transforms how you interact with your development lifecycle. In this article, you have learned how to:

• Query issues naturally — Ask questions about your backlog, sprints, and incidents in natural language.
• Create and update issues on all your DevSecOps environment — File bugs and update tickets without leaving your IDE.
• Correlate across systems — Combine Jira data with GitLab project management, merge requests, and pipelines for complete visibility.
• Reduce context switching — Keep your focus on code while staying connected to project management.

This integration exemplifies the power of MCP: standardized, secure access to your tools through AI, enabling developers to work more efficiently without sacrificing governance or security.

Read more

• GitLab Duo Agent Platform adds support for Model Context Protocol
• What is Model Context Protocol?
• Agentic AI guides and resources
• GitLab MCP clients documentation
• Get started with GitLab Duo Agent Platform: The complete guide

In this guide, we'll explore the different types of container scanning GitLab offers, how to enable each one, and common configurations to get you started.

Why container scanning matters

Security vulnerabilities in container images create risk throughout your application lifecycle. Base images, OS packages, and application dependencies can all harbor vulnerabilities that attackers actively exploit. Container scanning detects these risks early, before they reach production, and provides remediation paths when available.

Container scanning is a critical component of Software Composition Analysis (SCA), helping you understand and secure the external dependencies your containerized applications rely on.

The five types of GitLab Container Scanning

GitLab offers five distinct container scanning approaches, each serving a specific purpose in your security strategy.

1. Pipeline-based Container Scanning

• What it does: Scans container images during your CI/CD pipeline execution, catching vulnerabilities before deployment
• Best for: Shift-left security, blocking vulnerable images from reaching production
• Tier availability: Free, Premium, and Ultimate (with enhanced features in Ultimate)
• Documentation

GitLab uses the Trivy security scanner to analyze container images for known vulnerabilities. When your pipeline runs, the scanner examines your images and generates a detailed report.

How to enable pipeline-based Container Scanning

Option A: Preconfigured merge request

• Navigate to Secure > Security configuration in your project.
• Find the "Container Scanning" row.
• Select Configure with a merge request.
• This automatically creates a merge request with the necessary configuration.

Option B: Manual configuration

• Add the following to your .gitlab-ci.yml:

include:
  - template: Jobs/Container-Scanning.gitlab-ci.yml

Common configurations

Scan a specific image:

To scan a specific image, overwrite the CS_IMAGE variable in the container_scanning job.

include:
  - template: Jobs/Container-Scanning.gitlab-ci.yml

container_scanning:
  variables:
    CS_IMAGE: myregistry.com/myapp:latest

Filter by severity threshold:

To only find vulnerabilities with a certain severity criteria, overwrite the CS_SEVERITY_THRESHOLD variable in the container_scanning job. In the example below, only vulnerabilities with a severity of High or greater will be displayed.

include:
  - template: Jobs/Container-Scanning.gitlab-ci.yml

container_scanning:
  variables:
    CS_SEVERITY_THRESHOLD: "HIGH"

Viewing vulnerabilities in a merge request

Viewing Container Scanning vulnerabilities directly within merge requests makes security reviews seamless and efficient. Once Container Scanning is configured in your CI/CD pipeline, GitLab automatically display detected vulnerabilities in the merge request's Security widget.

• Navigate to any merge request and scroll to the "Security Scanning" section to see a summary of newly introduced and existing vulnerabilities found in your container images.
• Click on a Vulnerability to access detailed information about the finding, including severity level, affected packages, and available remediation guidance.

This visibility enables developers and security teams to catch and address container vulnerabilities before they reach production, making security an integral part of your code review process rather than a separate gate.

Viewing vulnerabilities in Vulnerability Report

Beyond merge request reviews, GitLab provides a centralized Vulnerability Report that gives security teams comprehensive visibility across all Container Scanning findings in your project.

• Access this report by navigating to Security & Compliance > Vulnerability Report in your project sidebar.
• Here you'll find an aggregated view of all container vulnerabilities detected across your branches, with powerful filtering options to sort by severity, status, scanner type, or specific container images.
• You can click on a vulnerabilty to access its Vulnerablity page.

Vulnerability Details shows exactly which container images and layers are impacted, making it easier to trace the vulnerability back to its source. You can assign vulnerabilities to team members, change their status (detected, confirmed, resolved, dismissed), add comments for collaboration, and link related issues for tracking remediation work.

This workflow transforms vulnerability management from a spreadsheet exercise into an integrated part of your development process, ensuring that container security findings are tracked, prioritized, and resolved systematically.

View the Dependency List

GitLab's Dependency List provides a comprehensive software bill of materials (SBOM) that catalogs every component within your container images, giving you complete transparency into your software supply chain.

• Navigate to Security & Compliance > Dependency List to access an inventory of all packages, libraries, and dependencies detected by Container Scanning across your project.
• This view is invaluable for understanding what's actually running inside your containers, from base OS packages to application-level dependencies.

You can filter the list by package manager, license type, or vulnerability status to quickly identify which components pose security risks or compliance concerns. Each dependency entry shows associated vulnerabilities, allowing you to understand security issues in the context of your actual software components rather than as isolated findings.

2. Container Scanning for Registry

• What it does: Automatically scans images pushed to your GitLab Container Registry with the latest tag
• Best for: Continuous monitoring of registry images without manual pipeline triggers
• Tier availability: Ultimate only
• Documentation

When you push a container image tagged latest, GitLab's security policy bot automatically triggers a scan against the default branch. Unlike pipeline-based scanning, this approach works with Continuous Vulnerability Scanning to monitor for newly published advisories.

How to enable Container Scanning for Registry

1. Navigate to Secure > Security configuration.
2. Scroll to the Container Scanning For Registry section.
3. Toggle the feature on.

Prerequisites

• Maintainer role or higher in the project
• Project must not be empty (requires at least one commit on the default branch)
• Container Registry notifications must be configured
• Package Metadata Database must be configured (enabled by default on GitLab.com)

Vulnerabilities appear under the Container Registry vulnerabilities tab in your Vulnerability Report.

3. Multi-Container Scanning

• What it does: Scans multiple container images in parallel within a single pipeline
• Best for: Microservices architectures and projects with multiple container images
• Tier availability: Free, Premium, and Ultimate (currently in Beta)
• Documentation

Multi-Container Scanning uses dynamic child pipelines to run scans concurrently, significantly reducing overall pipeline execution time when you need to scan multiple images.

How to enable Multi-Container scanning

1. Create a .gitlab-multi-image.yml file in your repository root:

scanTargets:
  - name: alpine
    tag: "3.19"
  - name: python
    tag: "3.9-slim"
  - name: nginx
    tag: "1.25"

2. Include the template in your .gitlab-ci.yml:

include:
  - template: Jobs/Multi-Container-Scanning.latest.gitlab-ci.yml

Advanced configuration

Scan images from private registries:

auths:
  registry.gitlab.com:
    username: ${CI_REGISTRY_USER}
    password: ${CI_REGISTRY_PASSWORD}

scanTargets:
  - name: registry.gitlab.com/private/image
    tag: latest

Include license information:

includeLicenses: true

scanTargets:
  - name: postgres
    tag: "15-alpine"

4. Continuous Vulnerability Scanning

• What it does: Automatically creates vulnerabilities when new security advisories are published, no pipeline required
• Best for: Proactive security monitoring between deployments
• Tier availability: Ultimate only
• Documentation

Traditional scanning only catches vulnerabilities at scan time. But what happens when a new CVE is published tomorrow for a package you scanned yesterday? Continuous Vulnerability Scanning solves this by monitoring the GitLab Advisory Database and automatically creating vulnerability records when new advisories affect your components.

How it works

1. Your Container Scanning or Dependency Scanning job generates a CycloneDX SBOM.
2. GitLab registers your project's components from this SBOM.
3. When new advisories are published, GitLab checks if your components are affected.
4. Vulnerabilities are automatically created in your vulnerability report.

Key considerations

• Scans run via background jobs (Sidekiq), not CI pipelines.
• Only advisories published within the last 14 days are considered for new component detection.
• Vulnerabilities use "GitLab SBoM Vulnerability Scanner" as the scanner name.
• To mark vulnerabilities as resolved, you still need to run a pipeline-based scan.

5. Operational Container Scanning

• What it does: Scans running containers in your Kubernetes cluster on a scheduled cadence
• Best for: Post-deployment security monitoring and runtime vulnerability detection
• Tier availability: Ultimate only
• Documentation

Operational Container Scanning bridges the gap between build-time security and runtime security. Using the GitLab Agent for Kubernetes, it scans containers actually running in your clusters—catching vulnerabilities that emerge after deployment.

How to enable Operational Container Scanning

If you are using the GitLab Kubernetes Agent, you can add the following to your agent configuration file:

container_scanning:
  cadence: '0 0 * * *'  # Daily at midnight
  vulnerability_report:
    namespaces:
      include:
        - production
        - staging

You can also create a scan execution policy that enforces scanning on a schedule by the GitLab Kubernetes Agent.

Viewing results

• Navigate to Operate > Kubernetes clusters.
• Select the Agent tab, and choose your agent.
• Then select the Security tab to view cluster vulnerabilities.
• Results also appear under the Operational Vulnerabilities tab in the Vulnerability Report.

Enhancing posture with GitLab Security Policies

GitLab Security Policies enable you to enforce consistent security standards across your container workflows through automated, policy-driven controls. These policies shift security left by embedding requirements directly into your development pipeline, ensuring vulnerabilities are caught and addressed before code reaches production.

Scan execution and pipeline policies

Scan execution policies automate when and how Container Scanning runs across your projects. Define policies that trigger container scans on every merge request, schedule recurring scans of your main branch, and more. These policies ensure comprehensive coverage without relying on developers to manually configure scanning in each project's CI/CD pipeline.

You can specify which scanner versions to use and configure scanning parameters centrally, maintaining consistency across your organization while adapting to new container security threats.

Pipeline execution policies provide flexible controls for injecting (or overriding) custom jobs into a pipeline based on your compliance needs.

Use these policies to automatically inject Container Scanning jobs into your pipeline, fail builds when container vulnerabilities exceed your risk tolerance, trigger additional security checks for specific branches or tags, or enforce compliance requirements for container images destined for production environments. Pipeline execution policies act as automated guardrails, ensuring your security standards are consistently applied across all container deployments without manual intervention.

Merge request approval policies

Merge request approval policies enforce security gates by requiring designated approvers to review and sign off on merge requests containing container vulnerabilities.

Configure policies that block merge when critical or high-severity vulnerabilities are detected, or require security team approval for any merge request introducing new container findings. These policies prevent vulnerable container images from advancing through your pipeline while maintaining development velocity for low-risk changes.

Choosing the right approach

For comprehensive security, consider combining multiple approaches. Use pipeline-based scanning to catch issues during development, container scanning for registry for continuous monitoring, and operational scanning for production visibility.

Get started today

The fastest path to container security is enabling pipeline-based scanning:

1. Navigate to your project's Secure > Security configuration.
2. Click Configure with a merge request for Container Scanning.
3. Merge the resulting merge request.
4. Your next pipeline will include vulnerability scanning.

From there, layer in additional scanning types based on your security requirements and GitLab tier.

Container security isn't a one-time activity, it's an ongoing process. With GitLab's comprehensive container scanning capabilities, you can detect vulnerabilities at every stage of your container lifecycle, from build to runtime.

For more information on how GitLab can help enhance your security posture, visit the GitLab Security and Governance Solutions Page.

So we built our own.

Here's what we learned and why creating your own custom security control framework might be the right move for your compliance program.

The journey through frameworks

When I joined GitLab's Security Compliance team in November 2022, we were using the Secure Controls Framework to manage controls across our external certifications and internal compliance needs. But as our requirements grew, we realized we needed something more comprehensive.

With FedRAMP authorization on our roadmap, we chose to adopt NIST SP 800-53 next. NIST SP 800-53 includes more than 1,000 controls, but its comprehensiveness isn’t perfectly suited to GitLab’s environment.

We didn't need to implement every NIST control, only those applicable to our specific requirements. Our focus was on the quality of controls rather than quantity. Implementing unnecessary controls doesn't improve security; in fact, too many can make an environment less secure as individuals find ways to circumvent overly restrictive or irrelevant controls.

Some controls also lacked the necessary granularity for our needs. For example, NIST’s AC-2 “Account Management” control covers account creation and provisioning, account modification and disabling, account removal and termination, shared and group account management, and account monitoring and reviews.

In practice, these are at least six distinct controls with different owners, testing procedures, and risks. For attestations like SOC 2, each activity is tested as a separate control because they have different evidence requirements and operational contexts. NIST's all-encompassing AC-2 didn't match how we actually operate controls or how auditors actually assess us, and we needed controls granular enough to reflect our operational environment.

We found ourselves constantly customizing, adding, and adapting NIST controls to fit our environment. At some point, we realized we weren't really using NIST SP 800-53 anymore, we were building our own framework on top of it. We decided a custom control framework, one tailored to GitLab’s environment, would best accommodate our multi-product offering and each product’s unique compliance needs.

Building the GitLab Control Framework

Through five methodical steps, we built our own common controls framework: the GitLab Control Framework (GCF).

1. Analyze what we need

We reviewed our existing controls and mapped every requirement from external certifications we already maintained, certifications on our roadmap, and our internal compliance program:

External certifications:

• SOC 2 Type II
• ISO 27001, ISO 27017, ISO 27018, ISO 42001
• PCI DSS
• TISAX
• Cyber Essentials
• FedRAMP

Internal compliance needs:

• Controls for mission-critical systems that are not in-scope for external certifications
• Controls for systems with access to sensitive data

This gave us the baseline: what controls must exist to meet our compliance obligations.

2. Learn from industry frameworks

Next, we compared our requirements against industry-recognized frameworks:

• NIST SP 800-53
• NIST Cybersecurity Framework (CSF)
• Secure Controls Framework (SCF)
• Adobe and Cisco Common Controls Framework (CCF)

Having adopted frameworks in the past, we wanted to learn from their structure and ensure we weren't missing critical security domains, controls, or best practices.

3. Create custom control domains

Through this analysis, we created 18 custom control domains tailored to GitLab's environment:

Each domain groups related controls into logical families that align with how GitLab's security program is actually organized and operated. This structure provides a methodical approach for adding, updating, or removing controls as our needs evolve.

4. Add context and data

With our domains defined, we needed to address two critical challenges: how to represent controls across multiple products without duplicating the framework, and how to capture meaningful implementation context to actually operate and audit at scale.

Scaling across multiple products

GitLab provides multiple product offerings: GitLab.com (multi-tenant SaaS on GCP), GitLab Dedicated (single-tenant SaaS on AWS), and GitLab Dedicated for Government (GitLab’s single-tenant FedRAMP offering on AWS). Each offering has different infrastructure, compliance scopes, and audit requirements. We needed to support product-specific audits without creating entirely separate frameworks.

We designed a control hierarchy where Level 1 controls are the framework, defining what should be implemented at the organizational level. Level 2 controls are the implementation, capturing the product-specific details of how each requirement is actually fulfilled.

%%{init: { "fontFamily": "GitLab Sans" }}%%
graph TD
    accTitle: Control Hierarchy
    accDescr: Level 1 requirements cascade to Level 2 implementations.
    
    L1["Level 1: Framework<br/>What must be implemented"];
    L2A["Level 2: GitLab.com<br/>How it's implemented"];
    L2B["Level 2: Dedicated<br/>How it's implemented"];
    L2C["Level 2: Dedicated for Gov<br/>How it's implemented"];
    L2D["Level 2: Entity<br/>(inherited by all)"];
    
    L1-->L2A;
    L1-->L2B;
    L1-->L2C;
    L1-->L2D;

This separation allows us to maintain one framework with product-specific implementations, rather than managing duplicate frameworks for each offering. Entity controls apply organization-wide and are inherited by GitLab.com, GitLab Dedicated, and GitLab Dedicated for Government.

Adding context to controls

Traditional control frameworks track minimal information: a control ID, description, and owner. The GCF takes a different approach and its superpower is the extensive metadata we track for each control. Beyond just stating the control description or implementation statement, we capture:

• Control owner: Who is accountable for the control and its risk?
• Environment: Does this apply organization-wide (Entity, inherited by all product offerings), to GitLab.com, or to Dedicated?
• Assets: What specific systems does this control cover?
• Frequency: How often is the control performed or tested?
• Nature: Is it manual, semi-automated, or fully automated?
• Classification: Is this for external certifications or internal risk?
• Testing details: How do we assess it? What evidence do we collect?

This context transforms the GCF from a simple control list into an operationalized control inventory.

With this structure, we can answer questions like:

• Which controls apply to GitLab.com for our SOC 2 audit vs. GitLab Dedicated? → Filter by environment: GitLab.com
• What controls does the Infrastructure team own? → Filter by owner
• Which controls can we automate? → Filter by nature: Manual

5. Iterate, mature, and scale

The GCF isn't static and was designed to evolve with our business and compliance landscape.

Pursuing new certifications

Because we've operationalized context into the GCF, we can quickly determine the scope and gaps when pursuing new certifications (ISMAP, IRAP, C5, etc.):

1. Determine scope: Which product has the business need (GitLab.com, GitLab Dedicated, or both)?
2. Map requirements: Do existing controls already cover the new certification requirements?
3. Identify gaps: What new controls need to be created?
4. Update mappings: Link existing controls to the new certification requirements.

Adapting to new regulations

When new regulations emerge or existing requirements change:

• Review existing controls: Does an existing control already cover the new requirement?
• Update or create: Either update existing control language or create a new control.
• Apply the most stringent: When multiple certifications have similar requirements, we implement the most stringent version — secure once, comply with many.
• Map across certifications: Link the control to all relevant certification requirements.

Managing control lifecycle

The framework adapts to various changes:

• Requirement changes: When certifications update their requirements, we review impacted controls and update descriptions or mappings.
• Deprecated controls: If a requirement is removed or a control is no longer needed, we mark it as deprecated and remove it from our monitoring schedule.
• New risks identified: Risk assessments may identify gaps requiring new internal controls.

The power of common controls: One control, multiple requirements

Securing once and complying with many isn't just a principle, it has tangible benefits across how we prepare for audits, support control owners, and pursue new certifications. Here's what that looks like in practice, both qualitatively and in the numbers.

Qualitative results

Since implementing the GCF, we've seen significant improvements in how we manage compliance:

Integrated audit approach

The GCF enables us to maintain one framework with controls mapped to multiple certification requirements, instead of managing separate control sets for each audit. One control can satisfy SOC 2, ISO 27001, and PCI DSS requirements simultaneously.

Faster audit preparation

Through the GCF, we maintain one consolidated request list instead of separate lists for each audit. Because we've defined controls with specific context, our request lists say "Okta user list" instead of generic "production user list," eliminating ambiguity and interpretation. We're not collecting “N/A” evidence or leaving it up to auditors to interpret what "production" means in our environment. Everything is already scoped to our actual systems.

Reduced stakeholder burden

This integration directly reduces burden on our stakeholders. Control owners provide evidence once instead of responding to separate requests from SOC 2, ISO, and PCI auditors. When we collect evidence for access controls, it satisfies SOC 2, ISO 27001, and PCI DSS requirements simultaneously. One control, one test, one piece of evidence with multiple certifications and requirements satisfied.

Efficient gap assessments

When pursuing new certifications or launching new features, the operationalized context enables more efficient gap analysis. We can determine which controls already exist, what's missing, and what implementation is required.

Quantifiable results

Control efficiency:

• Reduced SOC controls by 58% (200 controls → 84) for GitLab.com and 55% (181 → 82) for GitLab Dedicated
• One framework now supports 8+ certifications

Audit efficiency:

• Consolidated 4 audit request lists into 1, reducing requests by 44% (415 → 231)
• 95% evidence acceptance rate before fieldwork for recent PCI audits

Framework scale:

• 220+ active controls across 18 custom domains
• Mapped to 1,300+ certification requirements
• Supports multiple product offerings

The path forward

The GCF continues to evolve as we add security and AI controls, pursue new certifications, and refine our approach.

For security compliance practitioners: Don't be afraid to build your own framework if industry standards don't fit. The upfront investment pays dividends in scalability, efficiency, and controls that actually make sense for your environment. Sometimes the best framework is the one you design yourself.

If you found this helpful, check out our complete GitLab Control Framework documentation, where we detail our framework methodology, control domains, and field structures.

Because coding is only 20% of the software delivery lifecycle, the remaining 80% becomes the bottleneck: code review backlogs grow, security scanning can’t keep pace, documentation falls behind, and manual coordination overhead increases.

The good news is that the same AI capabilities that accelerate individual coding can eliminate these team-level delays. You just need to apply AI across your entire software lifecycle, not only during the coding phase.

Below are 10 ready-to-use prompts from the GitLab Duo Agent Platform Prompt Library that help teams overcome common obstacles to faster software delivery. Each prompt addresses a specific slowdown that emerges when individual productivity increases without corresponding improvements in team processes.

How do you move code review from bottleneck to accelerator?

Developers generate merge requests faster with AI assistance, but human reviewers can quickly become overwhelmed as code review cycles stretch from hours to days. AI can handle routine review tasks, freeing reviewers to focus on architecture and business logic instead of catching basic logical errors and API contract violations.

Review MR for logical errors

Complexity: Beginner

Category: Code Review

Prompt from library:

Review this MR for logical errors, edge cases, and potential bugs: [MR URL or paste code]

Why it helps: Automated linters catch syntax issues, but logical errors require understanding intent. This prompt catches bugs before human reviewers even look at the code, reducing review cycles from multiple rounds to often just one approval.

Identify breaking changes in MR

Complexity: Beginner

Category: Code Review

Prompt from library:

Does this MR introduce any breaking changes?

Changes:
[PASTE CODE DIFF]

Check for:
1. API signature changes
2. Removed or renamed public methods
3. Changed return types
4. Modified database schemas
5. Breaking configuration changes

Why it helps: Breaking changes discovered during deployment can cause rollbacks and incidents. This prompt shifts that discovery left to the MR stage, when fixes are faster and less expensive.

How can you shift security left without slowing down?

Security scans generate hundreds of findings. Security teams manually triage each one while developers wait for approval to deploy. Most findings are false positives or low-risk issues, but identifying the real threats requires expertise and time. AI can prioritize findings by actual exploitability and auto-remediate common vulnerabilities, allowing security teams to focus on the threats that matter.

Analyze security scan results

Complexity: Intermediate

Category: Security

Agent: Duo Security Analyst

Prompt from library:

@security_analyst Analyze these security scan results:

[PASTE SCAN OUTPUT]

For each finding:
1. Assess real risk vs false positive
2. Explain the vulnerability
3. Suggest remediation
4. Prioritize by severity

Why it helps: Most security scan findings are false positives or low-risk issues. This prompt helps security teams focus on the findings that actually matter, reducing remediation time from weeks to days.

Review code for security issues

Complexity: Intermediate

Category: Security

Agent: Duo Security Analyst

Prompt from library:

@security_analyst Review this code for security issues:

[PASTE CODE]

Check for:
1. Injection vulnerabilities
2. Authentication/authorization flaws
3. Data exposure risks
4. Insecure dependencies
5. Cryptographic issues

Why it helps: Traditional security reviews happen after code is written. This prompt enables developers to find and fix security issues before creating an MR, eliminating the back and forth that delays deployments.

How do you keep documentation current as code changes?

Code changes faster than documentation. Onboarding new developers takes weeks because docs are outdated or missing. Teams know documentation is important, but it always gets deferred when deadlines approach. Automating documentation generation and updates as part of your standard workflow ensures docs stay current without adding manual work.

Generate release notes from MRs

Complexity: Beginner

Category: Documentation

Prompt from library:

Generate release notes for these merged MRs:
[LIST MR URLs or paste titles]

Group by:
1. New features
2. Bug fixes
3. Performance improvements
4. Breaking changes
5. Deprecations

Why it helps: Manual release note compilation takes hours and often includes errors or omissions. Automated generation ensures every release has comprehensive notes without adding work to your release process.

Update documentation after code changes

Complexity: Beginner

Category: Documentation

Prompt from library:

I changed this code:

[PASTE CODE CHANGES]

What documentation needs updating? Check:
1. README files
2. API documentation
3. Architecture diagrams
4. Onboarding guides

Why it helps: Documentation drift happens because teams forget which docs need updates after code changes. This prompt makes documentation maintenance part of your development workflow, not a separate task that gets deferred.

How do you break down planning complexity?

Large features get stuck in planning. Teams spend weeks in meetings trying to scope work and identify dependencies. The complexity feels overwhelming, and it's hard to know where to start. AI can systematically decompose complex work into concrete, implementable tasks with clear dependencies and acceptance criteria, transforming weeks of planning into focused implementation.

Break down epic into issues

Complexity: Intermediate

Category: Documentation

Agent: Duo Planner

Prompt from library:

Break down this epic into implementable issues:

[EPIC DESCRIPTION]

Consider:
1. Technical dependencies
2. Reasonable issue sizes
3. Clear acceptance criteria
4. Logical implementation order

Why it helps: This prompt transforms a week of planning meetings into 30 minutes of AI-assisted decomposition followed by team review. Teams start implementation sooner with clearer direction.

How can you expand test coverage without expanding effort?

Developers are writing code faster, but if testing doesn't keep pace, test coverage decreases and bugs slip through. Writing comprehensive tests manually is time-consuming, and developers often miss edge cases under deadline pressure. Generating tests automatically means developers can review and refine rather than write from scratch, maintaining quality without sacrificing velocity.

Generate unit tests

Complexity: Beginner

Category: Testing

Prompt from library:

Generate unit tests for this function:

[PASTE FUNCTION]

Include tests for:
1. Happy path
2. Edge cases
3. Error conditions
4. Boundary values
5. Invalid inputs

Why it helps: Writing tests manually is time consuming, and developers often miss edge cases. This prompt generates thorough test suites in seconds, which developers can review and adjust rather than write from scratch.

Review test coverage gaps

Complexity: Beginner

Category: Testing

Prompt from library:

Analyze test coverage for [MODULE/COMPONENT]:

Current coverage: [PERCENTAGE]

Identify:
1. Untested functions/methods
2. Uncovered edge cases
3. Missing error scenario tests
4. Integration points without tests
5. Priority areas to test next

Why it helps: This prompt reveals blind spots in your test suite before they cause production incidents. Teams can systematically improve coverage where it matters most.

How do you reduce mean time to resolution when debugging?

Production incidents take hours to diagnose. Developers wade through logs and stack traces while customers experience downtime. Every minute of debugging is a minute of lost productivity and potential revenue. AI can accelerate root cause analysis by parsing complex error messages and suggesting specific fixes, cutting diagnostic time from hours to minutes.

Debug failing pipeline

Complexity: Beginner

Category: Debugging

Prompt from library:

This pipeline is failing:

Job: [JOB NAME]
Stage: [STAGE]
Error: [PASTE ERROR MESSAGE/LOG]

Help me:
1. Identify the root cause
2. Suggest a fix
3. Explain why it started failing
4. Prevent similar issues

Why it helps: CI/CD failures block entire teams. This prompt diagnoses failures in seconds instead of the 15-30 minutes developers typically spend investigating, keeping deployment velocity high.

Moving from individual gains to team acceleration

These prompts represent a shift in how teams apply AI to software delivery. Rather than focusing solely on individual developer productivity, they address the coordination, quality, and knowledge-sharing challenges that actually constrain team velocity.

The complete prompt library contains more than 100 prompts across all stages of the software lifecycle: planning, development, security, testing, deployment, and operations. Each prompt is tagged by complexity level (Beginner, Intermediate, Advanced) and categorized by use case, making it easy to find the right starting point for your team.

Start with prompts tagged “Beginner” that address your team’s most pressing obstacles. As your team builds confidence, explore intermediate and advanced prompts that enable more sophisticated workflows. The goal is not just faster coding — it's faster, safer, higher-quality software delivery from planning through production.

If security only meant scanning code, the answer might be yes. But enterprise security has never been about detection alone.

Organizations are not asking whether AI can find vulnerabilities. They are asking three much harder questions:

• Is what we are about to ship safe?
• Has our risk posture changed as environments evolve and dependencies, third-party services, tools, and infrastructure continuously shift?
• How do we govern a codebase that is increasingly assembled by AI and third-party sources, and that we are still accountable for?

Those questions require a platform answer: Detection surfaces risk, but governance determines what happens next.

GitLab is the orchestration layer built to govern the software lifecycle end-to-end. It gives teams the enforcement, visibility, and auditability they need to keep pace with the speed of AI-assisted development.

Trusting AI requires governing risk

AI systems are rapidly getting better at identifying vulnerabilities and suggesting fixes. This is a meaningful and welcome advancement, but analysis is not accountability.

AI cannot enforce company policy or define acceptable risk on its own. Humans must set the boundaries, policies, and guardrails that agents operate within, establishing separation of duties, ensuring audit trails, and maintaining consistent controls across thousands of repositories and teams. Trust in agents comes not from autonomy alone, but from clearly defined governance set by people.

In an agentic world, where software is increasingly written and modified by autonomous systems, governance becomes more important, not less. The more autonomy organizations grant to AI, the stronger the governance must be.

Governance is not friction. It is the foundation that makes AI-assisted development trustworthy at scale.

LLMs see code, but platforms see context

A large language model (LLM) evaluates code in isolation. An enterprise application security platform understands context. This difference matters because risk decisions are contextual:

• Who authored the change?
• How critical is the application to the business?
• How does it interact with infrastructure and dependencies?
• Does the vulnerability exist in code that is actually reachable in production, or is it buried in a dependency that never executes?
• Is it actually exploitable in production, given how the application runs, its APIs, and the environment around it?

Security decisions depend on this context. Without it, detection produces noisy alerts that slow down development rather than reducing risk. With it, organizations can triage quickly and manage risk effectively. Context evolves continuously as software changes, which means governance cannot be a one-time decision.

Static scans can’t keep up with dynamic risk

Software risk is dynamic. Dependencies change, environments evolve, and systems interact in ways no single analysis can fully predict. A clean scan at one moment does not guarantee safety at release.

Enterprise security depends on continuous assurance: controls embedded directly into development workflows that evaluate risk as software is built, tested, and deployed.

Detection provides insight. Governance provides trust. Continuous governance is what allows organizations to ship safely at scale.

Governing the agentic future

AI is reshaping how software is created. The question is no longer whether teams will use AI, but how safely they can scale it.

Software today is assembled as much as it is written, from AI-generated code, open-source libraries, and third-party dependencies that span thousands of projects. Governing what ships across all of those sources is the hardest and most consequential part of application security, and it is the part that no developer-side tool is built to address.

As an intelligent orchestration platform, GitLab is built to address this problem. GitLab Ultimate embeds governance, policy enforcement, security scanning, and auditability directly into the workflows where software is planned, built, and shipped, so security teams can govern at the speed of AI.

AI will accelerate development dramatically. The organizations that benefit most from AI will not be those with the smartest assistants alone, but those that build trust through strong governance.

To learn how GitLab helps organizations govern and ship AI-generated code safely, talk to our team today

Related reading

• Integrating AI with DevOps for enhanced security
• The GitLab AI Security Framework for security leaders
• Improve AI security in GitLab with composite identities

What is Agent Engine and why does it matter?

Agent Engine is Google Cloud's managed runtime specifically designed for AI agents. Think of it as the production home for your agents — where they live, run, and scale without you having to manage the underlying infrastructure. Agent Engine handles infrastructure, scaling, session management, and memory storage so you can focus on building your agent — not managing servers. It also integrates natively with Google Cloud's logging, monitoring, and IAM.

Why use GitLab to deploy to Agent Engine?

AI agent deployment is typically difficult to configure correctly. Security considerations, CI/CD orchestration, and cloud permissions create friction that slows down development cycles.

GitLab streamlines this entire process while enhancing security:

• Built-in security scanning — Every deployment is automatically scanned for vulnerabilities without additional configuration.
• Native Google Cloud integration — Workload Identity Federation eliminates the need for service account keys.
• Simplified CI/CD — GitLab's templates handle complex deployment logic.

Prerequisites

Before you begin, ensure you have:

• A Google Cloud project with the following APIs enabled:
  • Cloud Storage API
  • Vertex AI API
• A GitLab project for your source code and CI/CD pipeline
• A Google Cloud Storage bucket for staging deployments
• Google Cloud IAM integration configured in GitLab (see Step 1)

Here are the steps to follow.

1. Configure IAM integration

The foundation of secure deployment is proper IAM configuration between GitLab and Google Cloud using Workload Identity Federation.

In your GitLab project:

1. Navigate to Settings > Integrations.
2. Locate the Google Cloud IAM integration.
3. Provide the following information:
   • Project ID: Your Google Cloud project ID
   • Project Number: Found in your Google Cloud console
   • Workload Identity Pool ID: A unique identifier for your identity pool
   • Provider ID: A unique identifier for your identity provider

GitLab generates a script for you. Copy and run this script in Google Cloud Shell to establish the Workload Identity Federation between platforms.

Important: Add these additional roles to your service principal for Agent Engine deployment:

• roles/aiplatform.user
• roles/storage.objectAdmin

You can add these roles using gcloud commands:

GCP_PROJECT_ID="<your-project-id>"
GCP_PROJECT_NUMBER="<your-project-number>"
GCP_WORKLOAD_IDENTITY_POOL="<your-pool-id>"

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/aiplatform.user'

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/storage.objectAdmin'

2. Create the CI/CD pipeline

Now for the core of the deployment — the CI/CD pipeline. Create a .gitlab-ci.yml file in your project root:

stages:
  - test
  - deploy

cache:
  paths:
    - .cache/pip
  key: ${CI_COMMIT_REF_SLUG}

variables:
  GCP_PROJECT_ID: "<your-project-id>"
  GCP_REGION: "us-central1"
  STORAGE_BUCKET: "<your-staging-bucket>"
  AGENT_NAME: "Canada City Advisor"
  AGENT_ENTRY: "canada_city_advisor"

image: google/cloud-sdk:slim

# Security scanning templates
include:
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml
  - template: Jobs/SAST.gitlab-ci.yml
  - template: Jobs/Secret-Detection.gitlab-ci.yml

deploy-agent:
  stage: deploy
  identity: google_cloud
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
  before_script:
    - gcloud config set core/disable_usage_reporting true
    - gcloud config set component_manager/disable_update_check true
    - pip install -q --no-cache-dir --upgrade pip google-genai google-cloud-aiplatform -r requirements.txt --break-system-packages
  script:
    - gcloud config set project $GCP_PROJECT_ID
    - adk deploy agent_engine 
        --project=$GCP_PROJECT_ID 
        --region=$GCP_REGION 
        --staging_bucket=gs://$STORAGE_BUCKET 
        --display_name="$AGENT_NAME" 
        $AGENT_ENTRY

The pipeline consists of two stages:

Test stage — GitLab's security scanners run automatically. The included templates provide dependency scanning, static application security testing (SAST), and secret detection without additional configuration.

Deploy stage — Uses the ADK CLI to deploy your agent directly to Agent Engine. The staging bucket temporarily holds your application workload before Agent Engine picks it up for deployment.

Key configuration notes

• The identity: google_cloud directive enables keyless authentication via Workload Identity Federation.
• Security scanners are included as templates, meaning they run by default with no setup required.
• The adk deploy agent_engine command handles all the complexity of packaging and deploying your agent.
• Pipeline caching speeds up subsequent deployments by preserving pip dependencies.

3. Deploy and verify

With your pipeline configured:

1. Commit your agent code and .gitlab-ci.yml to GitLab.
2. Navigate to Build > Pipelines to monitor execution.
3. Watch the test stage complete security scans.
4. Observe the deploy stage push your agent to Agent Engine.

Once the pipeline succeeds, verify your deployment in the Google Cloud Console:

1. Navigate to Vertex AI > Agent Engine.
2. Locate your deployed agent.
3. Note the resource name — you'll need this for testing.

4. Test your deployed agent

Test your agent using a curl command. You'll need three pieces of information:

• Agent ID: From the Agent Engine console (the resource name's numeric identifier)
• Project ID: Your Google Cloud project
• Location: The region where you deployed (e.g., us-central1)

PROJECT_ID="<your-project-id>"
LOCATION="us-central1"
AGENT_ID="<your-agent-id>"
TOKEN=$(gcloud auth print-access-token)

curl -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  "https://${LOCATION}-aiplatform.googleapis.com/v1/projects/${PROJECT_ID}/locations/${LOCATION}/reasoningEngines/${AGENT_ID}:streamQuery" \
  -d '{
    "input": {
      "message": "I make $85,000 per year and I prefer cities with mild winters and a vibrant cultural scene. I also want to be near the coast if possible. What Canadian cities would you recommend?",
      "user_id": "demo-user"
    }
  }' | jq -r '.content.parts[0].text'

If everything is configured correctly, your agent will respond with personalized city recommendations based on the budget and lifestyle preferences provided.

Security benefits of this approach

This deployment pattern provides several security advantages:

• No long-lived credentials: Workload Identity Federation eliminates service account keys entirely.
• Automated vulnerability scanning: Every deployment is scanned before reaching production.
• Complete audit trail: GitLab maintains full visibility of who deployed what and when.
• Principle of least privilege: Fine-grained IAM roles limit access to only what's needed.

Summary

Deploying AI agents to production doesn't have to be complex. By combining GitLab's DevSecOps platform with Google Cloud's Agent Engine, you get:

• A managed runtime that handles scaling and infrastructure
• Built-in security scanning without additional tooling
• Keyless authentication via native cloud integration
• A streamlined deployment process that fits modern AI development workflows

Watch the full demo:

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

Many organizations know they need a modern DevSecOps platform. What they often don't have is the bandwidth to deploy, manage, and continuously optimize one while shipping software at the pace the business demands. That's a real opportunity for MSPs, and now GitLab has a defined program to support them.

We're excited to introduce the GitLab MSP Partner Program, a new global program that enables qualified MSPs to deliver GitLab as a fully managed service to their customers.

Why this matters for partners and customers

For the first time, GitLab has a formally defined, globally available program built specifically for MSPs. This means clear requirements, structured enablement, dedicated support, and real financial benefits, so partners can confidently invest in building a GitLab managed services practice.

The timing is right. Organizations are accelerating their DevSecOps journeys, but many are navigating complex migrations, sprawling toolchains, and growing security requirements on top of their core work of building and shipping software.

GitLab MSP partners handle the operational side of running the platform, including deployment, migration, administration, and ongoing support, so development teams can stay focused on what they do best.

What MSP partners get

Financial benefits: MSP partners earn GitLab partner margins plus an additional MSP premium on all transactions, new business, and renewals. You also retain 100% of the service fees you charge customers for deployment, migration, training, enablement, and strategic consulting. That's multiple recurring revenue streams built around a single platform.

Enablement and education: Partners have access to quarterly technical bootcamps covering version updates, new features, best practices, ongoing roadmap updates, and peer sharing. Recommended cloud certifications (AWS Solutions Architect Associate, GCP Associate Cloud Engineer) round out the technical foundation.

Go-to-market support: MSPs receive a GitLab Certified MSP Partner badge, co-brandable assets, eligibility for joint customer case studies, a Partner Locator listing, and access to Marketing Development Funds (MDF) for qualified demand generation activities.

What customers can expect

Customers working with a GitLab MSP partner get a structured, managed DevSecOps experience, documented and repeatable implementation methodologies, regular business reviews, and support with clearly defined response and escalation paths.

The result: Development teams can stay focused on building great software while their MSP partner focuses on running and optimizing the platform.

A new opportunity around AI

Organizations are increasingly looking to safely introduce AI into their software development workflows, and even experienced teams can benefit from a structured approach to rolling it out at scale. GitLab MSP partners are well-positioned to guide customers through GitLab Duo Agent Platform as part of a broader managed services offering.

By combining GitLab's DevSecOps platform with MSP-delivered operational expertise, customers can experiment with AI-assisted workflows in a governed environment, meet data residency and compliance requirements, and scale AI adoption across teams without overburdening internal resources.

Is this right for your business?

The GitLab MSP Partner Program is a strong fit if you:

• Already deliver managed services in cloud, infrastructure, or application operations
• Want to add high-value DevSecOps to your portfolio
• Have or want to build technical talent interested in modern development platforms
• Prefer long-term customer relationships over one-time transactions

If you're already a GitLab Select and Professional Services Partner, the MSP program gives you a structured way to turn your existing expertise into a repeatable managed offering.

Getting started

The program launches with the Certified MSP Partner designation. There's no minimum ARR or customer count required to join. Here's how the path looks:

1. Confirm fit - Verify you meet the business and technical requirements outlined in the handbook page.
2. Apply via the GitLab Partner Portal - Submit your application with business and technical documentation.
3. Complete 90-day onboarding - A structured onboarding journey covers contracts, technical enablement, sales training, and your first customer engagement.
4. Launch your managed offering - Package your services, set your SLAs, and begin engaging customers.

Completed applications are reviewed within approximately three business days.

Interested in building a GitLab managed services practice? New partners can apply to become a GitLab Partner. Existing partners can reach out to your GitLab representative to learn more about the program and tell us about the solutions you're currently offering customers through your MSP practice!