techlist.io
KREN

GitLab

135 posts

about.gitlab.com/blog

Filter by tag

Gitlab94DevSecOps52CI/CD50AI Agents27Machine Learning25Database Design19Gitlab Duo Agent Platform16Gitlab Duo12Model Context Protocol12Code Review11Sast10Vulnerability Management10+455
gitlab3 min readCurated summary

Streamline test management with SmartBear QMetry GitLab component

The SmartBear QMetry GitLab Component automates the transfer of test results from GitLab CI/CD pipelines into QMetry Test Management Enterprise. By publishing JUnit, TestNG, and other supported results automatically, it removes manual uploads and provides a centralized, traceable view of testing. The integration helps teams accelerate release decisions while supporting compliance and audit requirements. ## Why Integrate GitLab with QMetry? - **Eliminate manual uploads:** Test results are transferred automatically after pipeline execution, reducing effort and preventing outdated or inconsistent records. - **Improve traceability:** Teams can connect requirements, test cases, executions, commits, builds, and pipelines in a single audit trail. - **Accelerate feedback:** QA teams, product managers, and stakeholders gain access to results immediately after tests finish. - **Support regulated development:** Centralized, versioned test records help organizations in aerospace, financial services, automotive, and medical-device industries demonstrate test coverage and compliance. - **Enable AI-driven insights:** QMetry can analyze execution history to identify flaky tests, predict failures, and suggest optimization opportunities. ## GitLab–SmartBear Integration - The component is part of a broader partnership connecting GitLab’s CI/CD and DevSecOps capabilities with SmartBear’s testing and quality-management tools. - The integration is intended for organizations that need centralized visibility across complex or regulated software-development lifecycles. - QMetry acts as the system of record for test planning, execution, tracking, and reporting. ## Requirements and Test Result Flow Before configuring the integration, teams need: - A GitLab project with automated tests that generate JUnit XML, TestNG XML, or another supported format. - A QMetry Test Management Enterprise account with API access enabled. - A QMetry API key with permission to upload test results. - An existing QMetry project. - Basic knowledge of GitLab CI/CD and `.gitlab-ci.yml`. - Optionally, a configured QMetry test suite for better organization. The automated flow is: - GitLab runs unit, integration, end-to-end, or other automated tests. - The tests generate result files. - The QMetry component runs as a pipeline job. - It reads the result files and uploads them to QMetry through the API. - QMetry processes the results for reporting and analysis. ## Obtaining QMetry API Credentials - Log in to QMetry Test Management Enterprise. - Open the user profile and navigate to **Settings** or **API Access**. - Generate a named API key, such as `GitLab CI/CD Integration`. - Grant the key write access for test-result uploads. - Copy the key immediately because it is displayed only once. - Record the QMetry instance URL, typically in the form `https://your-company.qmetry.com`. The API key should be treated like a password. It should not be committed to `.gitlab-ci.yml` or stored in plain text; GitLab CI/CD variables should be used to protect it. The component provides a practical way to make QMetry the centralized source of truth for pipeline testing. Organizations should secure the API credentials, configure the component in their GitLab pipeline, and continuously publish results so teams can improve visibility, traceability, and release confidence.

Read original(opens in new tab)
AICI/CDGitlabDevSecOps+4
gitlab2 min readCurated summary

GitLab Duo CLI: Agentic AI now in the terminal

GitLab Duo CLI brings GitLab’s agentic AI capabilities into the terminal, extending AI assistance beyond interactive coding in an IDE. Its public beta supports both human-guided sessions and unattended automation across the software development lifecycle, including coding, CI/CD, testing, and troubleshooting. GitLab emphasizes security through approvals, prompt-injection detection, auditing, and configurable permissions. ## Terminal-Based Agentic Development - The CLI is designed for work outside the IDE and GitLab UI. - Terminals are well suited to: - Automation and scripting - Piping and chaining commands - Portable workflows - Reproducible debugging - IDEs remain better for interactive, context-rich development, while Duo CLI targets automation and machine-driven workflows. ## Installation - Users with GitLab’s `glab` CLI can start Duo CLI with: ```bash glab duo cli ``` - GitLab Duo CLI can also be installed as a standalone tool. ## Capabilities and Operating Modes - Duo CLI can build, modify, refactor, and modernize code. - It can access agents and flows defined in GitLab Duo Agent Platform. - Potential uses include: - Creating and optimizing CI/CD configurations - Running multi-step development tasks - Debugging failed pipelines - Integrating AI into unattended workflows ### Interactive Mode - Provides editor-independent terminal chat. - Keeps a human in the loop by requiring approval before actions. - Supports codebase exploration, code creation, error fixing, and pipeline troubleshooting. ### Headless Mode - Runs without user interaction. - Designed for CI/CD runners, scripts, and automated workflows. - Enables agents to operate in environments where no developer is present. ## Security and Governance - Interactive actions require human approval by default. - Prompt-injection detection is built into the Duo Agent Platform. - Composite identity controls agent access and makes AI-driven actions auditable. - Instruction files such as `chat-rules.md`, `AGENTS.md`, and `SKILL.md` define permitted tasks, resources, context, and actions. - These controls apply least-privilege principles to AI agents. ## Availability - Duo CLI is available through a free trial of GitLab Duo Agent Platform. - Free-tier GitLab users can sign up for the platform. - GitLab Premium and Ultimate subscribers can enable Duo Agent Platform and use included GitLab Credits. GitLab Duo CLI is best suited to teams that want AI assistance across the full development lifecycle rather than only inside an editor. Its combination of interactive approvals, headless execution, and platform-level security makes it useful for both developer support and automated DevSecOps workflows.

Read original(opens in new tab)
Machine LearningCI/CDGitlabDevSecOps+4
gitlab2 min readCurated summary

Changes to packages.gitlab.com: What you need to know

GitLab is migrating `packages.gitlab.com` to a new package hosting system while keeping the base domain unchanged. Existing configurations will continue working through rewrite rules until September 30, 2026, but old URL formats, GPG key locations, network requirements, and download paths must be updated before then. New installations already use the updated formats. ## Timeline and Required Updates - The legacy PackageCloud system and UI shut down on March 31, 2026. - Backward-compatible URL rewrites will be removed by the end of September 2026. - Existing users should: - Re-run the latest DEB or RPM installation script, or update repository configuration manually. - Change the GPG key URL to `https://packages.gitlab.com/gpgkey/gpg.key`. - Allow `https://storage.googleapis.com/packages-ops` through firewalls and proxies. - Update repository mirrors and direct-download automation. - Change GitLab Runner RPM references from `noarch` to `x86_64`. ## DEB Repository URL Changes - `gitlab/*` repositories such as `gitlab-ee` and `gitlab-ce` now include the distribution codename in the URL path. - Example: - Old: `.../ubuntu/` - New: `.../ubuntu/jammy` - This produces standard Debian paths containing `dists/jammy` and `pool`. - Re-running the installation script is the simplest migration method: - DEB: `script.deb.sh` - RPM: `script.rpm.sh` - `runner/*` DEB repositories, including `runner/gitlab-runner`, are unchanged. ## GPG Keys and Installation Scripts - Replace: - `https://packages.gitlab.com/gpg.key` - With: - `https://packages.gitlab.com/gpgkey/gpg.key` - Previously saved installation scripts should not be reused; download current versions from GitLab. ## Direct Package Downloads - The old PackageCloud UI used URLs ending in `download.deb` or `download.rpm`. - The new UI links directly to the actual package paths. - Automation that scrapes the old UI or constructs these legacy URLs must be changed to use the new paths or standard package-manager repositories. ## GitLab Runner RPM Packages - Runner RPM packages that were previously under a `noarch` path have moved to `x86_64`. - This affects RPM-based systems such as EL8 and EL9. - Debian-based Runner packages are unaffected. - Update scripts or configurations that reference the old `noarch/Packages` paths. ## Firewall and Network Requirements - Package downloads now redirect to Google Cloud Storage instead of AWS CloudFront. - Permit both `packages.gitlab.com` and `storage.googleapis.com/packages-ops`. - Missing allowlist entries can cause HTTP 503 errors or connection timeouts. Existing installations should be migrated well before September 30, 2026. For new setups, following GitLab’s current installation documentation handles the changes automatically.

Read original(opens in new tab)
GitlabGpgCloud StorageDeb+4
gitlab3 min readCurated summary

Getting started with GitLab feature flags in Python

GitLab feature flags let teams deploy code without immediately exposing it to users, reducing the risk of production failures and eliminating redeployments for rollbacks. Using the Unleash Python SDK, a Flask application can retrieve flag definitions from GitLab, cache them locally, and evaluate them quickly without a network request on every check. The tutorial demonstrates a practical setup using configurable rollout strategies such as user targeting, percentage rollouts, and all-user releases. ## Requirements and Project Setup - A GitLab project with Feature Flags enabled under **Settings > General > Visibility, project features, permissions**. - A fork or clone of the demo repository: - `app.py` contains the Flask and Unleash integration. - `requirements.txt` lists dependencies. - `.env.example` documents required configuration. - `templates/index.html` and `static/styles.css` provide the demo interface. - The example repository is available at `gitlab.com/omid-blogs/gitlab-feature-flags-demo`. ## How the Unleash Integration Works - GitLab provides an Unleash-compatible API for each project, so no separate Unleash server is required. - The SDK downloads flag definitions when the application starts. - It refreshes the cached configuration periodically; the demo uses a 15-second interval. - Calls to `is_enabled()` evaluate flags locally, avoiding a network request for each check. - Local evaluation makes flag checks fast and more resilient to temporary connectivity problems. ## Creating Feature Flags The tutorial creates four active flags, initially using the **All users** strategy: - `dark_mode` enables a dark color scheme. - `holiday_banner` displays a festive banner. - `new_layout` changes the card grid to a single-column layout. - `fun_fonts` applies a playful handwritten font. A flag must be both **Active** and assigned at least one strategy. An active flag without a strategy is evaluated as disabled. ## Choosing Rollout Strategies GitLab supports several built-in strategies: - **Percent rollout:** Gradually enables a feature based on user ID, session ID, or random assignment. - **Percent of users:** Targets a percentage of authenticated users. - **User IDs:** Limits access to explicitly named users, useful for QA. - **User list:** Enables a feature for a predefined user group. - **All users:** Enables the feature for everyone. A typical release process is to begin with QA users, move to a 10% rollout, and eventually enable the feature for all users entirely through GitLab’s UI. ## Configuring Unleash Credentials From the project’s Feature Flags page, the **Configure** panel provides: - `UNLEASH_URL`, such as `https://gitlab.com/api/v4/feature_flags/unleash/<your-project-id>` - `UNLEASH_INSTANCE_ID`, a project-scoped read-only token - `UNLEASH_APP_NAME`, used to identify the application, for example `production` The Instance ID can read flag state but cannot modify flags. It should still be treated as a secret because it can expose project flag information. ## Running the Application Locally - Install dependencies with: ```bash pip install -r requirements.txt ``` - Copy `.env.example` to `.env` and replace the placeholders with the GitLab credentials. - Export the variables from the `.env` file or define them directly in the terminal. - The three environment variables driving the integration are: - `UNLEASH_URL` - `UNLEASH_INSTANCE_ID` - `UNLEASH_APP_NAME` - Never commit `.env`; the repository’s `.gitignore` excludes it because the Instance ID is sensitive. The recommended approach is to use the `UnleashClient` Python SDK to handle polling, caching, and local feature-flag evaluation, while GitLab remains the control center for changing rollout behavior.

Read original(opens in new tab)
GitlabPythonApi IntegrationFeature Flags+4
gitlab3 min readCurated summary

Manage vulnerability noise at scale with auto-dismiss policies

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

Read original(opens in new tab)
GitlabDevSecOpsVulnerability ManagementYaml+3
gitlab2 min readCurated summary

Agile planning gets a boost from new features in GitLab 18.10

GitLab 18.10 introduces a unified work items list and saved views to improve Agile planning. Teams can now manage epics, issues, and other work items in one place while saving filters, sorting, and display settings for repeated workflows. These changes reduce context switching and establish the foundation for broader planning views and customizable work item types. ## Unified Work Items List - Combines epics, issues, and other work item types into a single list. - Replaces the need to navigate between separate epic and issue pages. - Provides a foundation for future hierarchy and table views that show relationships between work items. - GitLab plans to bring additional planning workflows, including Boards, into the same unified experience. - The term “work items” supports future customization of item types and names instead of limiting the system to traditional “issues.” ## Why GitLab Is Making the Change - GitLab’s 2024 Agile planning vision identified separate epic and issue experiences as a source of friction. - The work items framework provides a shared architecture for consistent functionality across planning objects. - The new list and saved views represent progress toward that unified planning model. ## Saved Views - Save customized list configurations for future use. - Configurations can include: - Filters - Sort order - Display options - Help teams avoid repeatedly setting up common workflows. - Support consistent reporting, status checks, iteration planning, backlog refinement, and portfolio planning. - Saved views can be shared with teammates to standardize how work is reviewed. ## Future Planning Experience - Users will be able to move between list, board, table, and other views while retaining the same filter scope. - Planned hierarchy and nested table views will improve portfolio-level planning. - Future board capabilities may include swimlanes based on any work item attribute. - The unified framework is intended to make planning views more flexible and interconnected. ## Transition and Feedback - Existing workflows based on separate epic and issue pages may require adjustment. - GitLab acknowledges the change could be disruptive but says it reflects years of feedback and substantial investment in the work items framework. - Users are encouraged to try the new capabilities and provide feedback through GitLab’s feedback issue. Teams should begin testing the unified work items list and saved views in their everyday planning workflows, while offering feedback to help GitLab refine the transition.

Read original(opens in new tab)
GitlabAgile PlanningWork ItemsSaved Views+3
gitlab2 min readCurated summary

GitLab 18.10 brings AI-native triage and remediation

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

Read original(opens in new tab)
GitlabVulnerability ManagementSastMerge Requests+4
gitlab3 min readCurated summary

Code Review without the bottlenecks or the bill

GitLab presents Code Review Flow as an agentic review capability designed to reduce code-review bottlenecks caused by AI-accelerated development. It runs automated, context-aware reviews for every merge request at a flat cost of $0.25 each, enabling teams to review changes in parallel rather than rationing reviews or waiting hours in a queue. The post concludes that predictable pricing and organization-wide automation can make continuous AI review practical. ## The Code-Review Bottleneck - AI coding tools have increased development speed, but review capacity has not kept pace. - Code-review times reportedly rose 91% on teams using AI coding tools. - Engineers at large companies wait a median of 13 hours for pull requests to merge. - 44% of engineering teams identify slow reviews as their biggest delivery blocker. - Competing AI review tools may cost $15–$25 per review, encouraging teams to limit their use. ## How Code Review Flow Works - Automatically starts when a merge request is opened. - Scans the code changes and explores relevant repository context. - Checks pipeline status, security findings, and compliance requirements. - Produces structured inline feedback grounded in the project’s broader context, not only the diff. - Runs within GitLab and can process hundreds of reviews in parallel across an organization. - Supports project-specific review instructions and different agents, including Claude Code, Codex, or custom agents. ## Flat-Rate Pricing and Savings - Each review costs 0.25 GitLab Credits, equivalent to $0.25 at list pricing. - Four reviews cost one credit, regardless of merge-request size or complexity. - The predictable pricing avoids token estimates and unexpected bills. - Compared with an estimated $25 cost for 15 minutes of senior-engineer review time, the post claims a 99% reduction in per-review cost. - Parallel execution can unblock merge requests in minutes instead of hours. ## Enabling Reviews by Default - The low fixed price is intended to remove the need to prioritize which merge requests receive AI review. - Teams can enable Code Review Flow automatically for every merge request and project. - Automated reviews handle routine feedback while engineers focus on architecture, mentorship, and higher-level decisions. - Consistent project-specific guardrails can be applied across different review workflows. ## Availability - The pricing is available through GitLab Duo Agent Platform on GitLab.com and GitLab Dedicated. - Self-managed GitLab instances must run version 18.8.4 or later. - GitLab recommends starting a trial or contacting an account representative to enable the feature. Teams seeking to reduce review delays can consider enabling Code Review Flow by default, while still treating automated feedback as a supplement to human review for architectural and judgment-intensive changes.

Read original(opens in new tab)
GitlabDevSecOpsCode ReviewAi Assistance+3
gitlab3 min readCurated summary

GitLab 18.10: Agentic AI now open to even more teams on GitLab

GitLab 18.10 makes agentic AI available to Free GitLab.com teams without requiring a subscription upgrade. By purchasing shared monthly GitLab Credits, teams gain access to planning, code generation, automated code review, and pipeline troubleshooting. The update also introduces predictable flat-rate pricing for code reviews, while Premium remains attractive for teams needing broader platform capabilities and included credits. ## Agentic AI for Free-tier teams - Free top-level GitLab.com groups can purchase a monthly commitment of GitLab Credits through group billing. - Credits are shared across the entire team, so organizations pay for AI usage rather than per-user access. - Teams receive access to capabilities previously 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 - Group owners can use the GitLab Credits dashboard to monitor which agents and workflows consume credits. ## From planning to deployment GitLab describes a workflow covering the full software lifecycle: - **Planner Agent** turns a natural-language feature request into structured issues with descriptions, labels, and relationships. - **Developer Flow** reads an issue, generates code, runs tests, and opens a merge request. - **Code Review Flow** performs multi-step automated reviews and posts inline feedback based on repository context and code changes. - **Fix CI/CD Pipeline Flow** analyzes failed job logs, identifies likely root causes, and proposes fixes. - Agentic Chat supports iterative tasks such as refactoring, extending, or explaining code. ## Flat-rate automated code review - Code Review Flow costs **0.25 GitLab Credits per review**, regardless of merge request size, repository complexity, or internal processing steps. - Four reviews consume one credit. - The fixed price makes costs easier to forecast for both small and high-volume teams. - Automated reviews can run concurrently, reducing review queues and freeing human reviewers to focus on architecture and business logic. ## Why Premium may be the next step - GitLab Premium costs **$29 per user per month** and includes 12 promotional credits per user. - A 20-person team would receive 240 credits monthly—enough for approximately 960 automated code reviews or a mixture of AI workflows. - Premium also adds advanced CI/CD, merge approvals, code owners, governance features, and unified project context. - Teams that begin with Free plus purchased credits may find Premium more economical as AI becomes central to their development process. ## Getting started Free GitLab.com teams can purchase credits through group billing and begin using the Duo Agent Platform immediately. Teams seeking broader collaboration, governance, and CI/CD features can instead evaluate GitLab Premium or Ultimate.

Read original(opens in new tab)
Database DesignAI AgentsCI/CDGitlab+3
gitlab2 min readCurated summary

Agentic code reviews for $0.25 each

GitLab introduces Code Review Flow, an agentic AI review feature priced at a flat $0.25 per merge request. It automatically analyzes code, repository context, pipelines, security findings, and compliance requirements, producing structured inline feedback. The post argues that predictable pricing and parallel execution can reduce review costs and shorten merge queues. ## The Code Review Bottleneck - AI coding tools have increased development speed, but review capacity has not kept pace. - Code review times have reportedly risen 91% on teams using AI coding tools. - Engineers at large companies wait a median of 13 hours for pull requests to merge. - 44% of engineering teams identify slow reviews as their biggest delivery blocker. - Existing AI review tools often use unpredictable token-based pricing, with some costing $15–$25 per review. ## How Code Review Flow Works - It starts automatically when a merge request is opened. - The agent: - Scans the code changes. - Explores relevant repository context. - Checks pipeline status and results. - Reviews security findings and compliance requirements. - Produces structured inline comments. - Because it runs within GitLab, reviews can execute in parallel across projects and organizations rather than sequentially in individual developers’ environments. ## Flat-Rate Pricing and Savings - Each review costs 0.25 GitLab Credits, or $0.25 at list pricing. - The price is the same regardless of merge request size or complexity. - Four reviews cost one GitLab Credit, making usage easy to forecast. - Compared with an estimated $25 cost for 15 minutes of senior-engineer review time, GitLab claims a 99% reduction in per-review cost. - Parallel reviews can unblock merge requests within minutes instead of hours. ## Scaling Reviews Across Teams - The low fixed price makes it practical to run reviews on every merge request. - Teams can define project-specific review instructions and guardrails. - Different projects can use Code Review Flow, Claude Code, Codex, or custom agents. - Results remain visible in GitLab while reviews run concurrently. ## Availability - The $0.25 pricing is available on GitLab.com, Dedicated, and self-managed GitLab instances running version 18.8.4 or later. - Users can try GitLab Duo Agent Platform through a free trial or contact their GitLab account representative. The post recommends enabling automated reviews broadly rather than reserving them for high-priority changes, using AI to handle routine feedback while engineers focus on architecture, mentorship, and higher-value decisions.

Read original(opens in new tab)
GitlabDevSecOpsMerge RequestsAi Code Review+3
gitlab3 min readCurated summary

GitLab Container Virtual Registry with Docker Hardened Images

GitLab Container Virtual Registry provides a single, authenticated endpoint for pulling images from multiple registries while caching manifests and layers locally. It reduces repeated network downloads, centralizes upstream credentials, and makes it easier to adopt Docker Hardened Images without changing every team’s CI/CD configuration. The article recommends using it as an operational layer between pipelines and registries such as Docker Hub, dhi.io, MCR, and Quay.io. ## The Container Image Management Problem Platform teams often depend on several registries: - Docker Hub for common base images - dhi.io for Docker Hardened Images - MCR for .NET and Azure tooling - Quay.io for Red Hat ecosystem images - Internal registries for proprietary images This creates: - Different authentication mechanisms and image paths - Registry-specific CI/CD configuration - Repeated credential-management work - Slow builds caused by downloading identical images in every job ## How Container Virtual Registry Works - Pipelines pull through a GitLab URL such as: `gitlab.com/virtual_registries/container/<id>/image` - GitLab checks configured upstreams in priority order. - If the image is cached, GitLab serves it directly. - If not, GitLab fetches it from the appropriate upstream, caches the manifest and layers, and returns it. - Cache validity is configurable, with 24 hours presented as the default. - Developers and pipeline authors do not need to know which upstream registry provides an image. ## Benefits for Docker Hardened Images Docker Hardened Images offer: - Minimal attack surfaces - Near-zero CVEs - Software bills of materials (SBOMs) - SLSA provenance The virtual registry reduces the friction of adopting them by providing: - **Centralized authentication:** Teams authenticate to GitLab while GitLab stores and uses the dhi.io credentials. - **Simpler CI/CD:** Pipelines use one GitLab endpoint rather than configuring dhi.io separately. - **Gradual adoption:** Teams can migrate incrementally while cached image paths reveal which variants are being used. - **Improved visibility:** The cache provides an inventory of active dependencies, such as whether teams pull `library/python:3.11` instead of a hardened alternative. - **An audit trail:** Cached images help with compliance and understanding fleet-wide dependencies. ## Setting Up the Registry The article demonstrates setup with a Python client. - Create a virtual registry under a GitLab top-level group: ```python registry = client.create_virtual_registry( group_id="785414", name="platform-images", description="Cached container images for platform teams" ) ``` - Add Docker Hub as an upstream, using a 24-hour cache period. - Add dhi.io with a Docker username and access token: ```python 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 sources such as: - `https://mcr.microsoft.com` for Microsoft images, with a 48-hour cache period - `https://quay.io` for Quay-hosted images, with a 24-hour cache period ## Practical Recommendation Use GitLab Container Virtual Registry as a centralized pull-through cache when multiple teams rely on several container registries. Configure Docker Hardened Images as an upstream, point pipelines to the GitLab virtual registry endpoint, and use the cache contents to monitor adoption, performance, and image dependencies.

Read original(opens in new tab)
CI/CDGitlabPythonDocker & Containers+4
gitlab3 min readCurated summary

Automating detection gap analysis with GitLab Duo Agent Platform

GitLab’s Signals Engineering team uses GitLab Duo Agent Platform to automate detection gap analysis after security incidents. The approach replaces inconsistent manual reviews with AI agents that examine incident issues, map attacker behavior to MITRE ATT&CK, and recommend actionable detection improvements. GitLab recommends starting with the built-in Security Analyst Agent, then creating a custom agent when organization-specific context is required. ## The Detection Gap Problem - A detection gap occurs when an attacker performs an action that existing detections fail to identify. - Reviewing gaps requires analysts to: - Read incident timelines, comments, and related artifacts. - Map attacker actions to detection opportunities. - Identify missing or insufficient alerts. - Recommend concrete detection improvements. - Manual analysis is time-consuming, inconsistent across reviewers, and easy to postpone. - GitLab embeds this process in the workflow where incidents already reside: GitLab issues. ## GitLab Duo Agent Platform - Duo Agent Platform supports agents that can reason, take actions, and interact with GitLab resources such as issues, merge requests, and code. - Teams can either: - Use pre-built agents with existing domain knowledge. - Build custom agents using a name, description, and system prompt. - The system prompt defines the agent’s role, knowledge, tools, and expected behavior. ## Security Analyst Agent - The built-in Security Analyst Agent can be invoked directly from a closed incident issue. - It reviews: - Incident descriptions and timelines. - Tasks and comments. - Linked artifacts and other issue content. - It can identify missed attacker tactics, techniques, and procedures and map them to MITRE ATT&CK. - It is useful for quick, low-configuration assessments, particularly when incident documentation is thorough. - Its limitation is a lack of knowledge about an organization’s specific SIEM, log sources, detection stack, and engineering standards. ## Detection Engineering Assistant - GitLab created a custom agent to provide recommendations tailored to its environment. - Building the agent requires only: - A name. - A description. - A system prompt. - The system prompt is central to the agent’s usefulness; detailed instructions produce more consistent and relevant results. ### Defining the Agent’s Role - The prompt explicitly identifies the agent as a detection engineering assistant responsible for analyzing incidents and finding coverage gaps. - Clear framing helps anchor the agent’s responses to the team’s actual responsibilities. ### Encoding Detection Principles - GitLab describes its preferred detection characteristics: - Low false-positive rates. - High signal fidelity. - Actionable alerts with useful response context. - The prompt favors behavioral detections over indicator-of-compromise approaches when practical. - It also addresses the tradeoff between broad coverage and alert fatigue. ### Providing Environment and Telemetry Context - The agent is told which log sources are available, what SIEM is used, and what telemetry is missing. - This prevents it from recommending detections that depend on data the team cannot access. ### Structuring Findings with MITRE ATT&CK - Gap findings are organized around ATT&CK tactics and techniques. - This provides consistent reporting and supports internal coverage tracking and prioritization. ### Standardizing Output - Each finding should include: - The relevant ATT&CK technique. - What attacker behavior was missed. - The log source or data needed for detection. - A recommended detection approach. - Consistent formatting makes findings easier to triage and convert into engineering work. - GitLab’s full system prompt contains 1,870 words and 337 lines, illustrating the level of detail used to tailor the agent. ## Practical Recommendation Use the Security Analyst Agent for an immediate first pass, but build a custom detection engineering agent when recommendations need to reflect your own telemetry, tooling, standards, and detection philosophy. A detailed system prompt is the key to turning general AI analysis into repeatable, actionable security engineering work.

Read original(opens in new tab)
Machine LearningGitlabDevSecOpsAutomation+4
gitlab2 min readCurated summary

Navigate repositories faster with the file tree browser

GitLab 18.9 introduces a collapsible file tree browser that makes repository navigation more like using an IDE. The panel keeps files and directories visible while reading code, reducing back-and-forth navigation and preserving context. It is available on GitLab.com, Self-Managed, and Dedicated, with support for accessibility, responsive layouts, and large repositories. ## Persistent Repository Context - A resizable, collapsible panel appears alongside file lists and code. - Users can expand or collapse directories and switch files without losing their place. - When opening a nested file directly, parent directories expand and the current file is highlighted. - The tree stays synchronized with the selected file or directory in the main content area. ## Filename Search - Press `F` to open the global file search dialog. - Search results can match part of a filename or extension. - Each result includes its parent directories, making the destination clear before navigation. - Press `Enter` to open the selected file. ## Keyboard and Accessibility Support - The browser follows the W3C ARIA treeview pattern. - Users can navigate with arrow keys, `Enter`, `Space`, `Home`, `End`, and character keys. - The design supports screen readers and keyboard-first workflows. ## Responsive Design and Performance - On desktop, the tree appears beside the file list and code. - On smaller screens, it becomes a toggleable left-side drawer. - On mobile, it is hidden to maximize the code-view area. - Pagination prevents large repositories from overwhelming the page and keeps the interface responsive. ## Availability and Usage - Open a repository at `/<project>/-/tree/<branch>`. - Select the file tree icon or press `Shift+F` to toggle the browser. - The feature is available on GitLab.com and was released in version 18.9 for GitLab Self-Managed and GitLab Dedicated. The file tree browser is recommended for anyone navigating large repositories, especially users who want IDE-like structure, faster file discovery, and better keyboard accessibility.

Read original(opens in new tab)
GitlabAccessibilityDevSecOpsKeyboard Navigation+4
gitlab3 min readCurated summary

A complete guide to GitLab Container Scanning

GitLab provides multiple container-scanning methods to detect vulnerabilities throughout the container lifecycle, from CI builds to registry monitoring. The guide emphasizes scanning early to identify risks in base images, operating-system packages, and application dependencies before they reach production. It covers pipeline-based scanning in detail and introduces registry scanning for continuously monitoring published images. ## Why Container Scanning Matters - Container vulnerabilities can arise during image creation or while containers are running in production. - Base images, OS packages, and application dependencies may contain exploitable flaws. - Scanning supports a shift-left security strategy by detecting issues before deployment. - Container scanning is part of Software Composition Analysis (SCA), helping teams understand and secure external dependencies. ## Pipeline-Based Container Scanning Pipeline-based scanning analyzes container images during CI/CD execution. - **Purpose:** Detect vulnerabilities before deployment and help prevent unsafe images from reaching production. - **Scanner:** GitLab uses Trivy to identify known vulnerabilities. - **Availability:** Free, Premium, and Ultimate tiers, with additional features in Ultimate. - **Automatic setup:** Use **Secure > Security configuration** and configure Container Scanning through a generated merge request. - **Manual setup:** Include the following template in `.gitlab-ci.yml`: ```yaml include: - template: Jobs/Container-Scanning.gitlab-ci.yml ``` ### Common Configuration Options - Scan a specific image by overriding `CS_IMAGE`: ```yaml include: - template: Jobs/Container-Scanning.gitlab-ci.yml container_scanning: variables: CS_IMAGE: myregistry.com/myapp:latest ``` - Restrict findings to a severity threshold with `CS_SEVERITY_THRESHOLD`: ```yaml container_scanning: variables: CS_SEVERITY_THRESHOLD: "HIGH" ``` This example reports only High and Critical vulnerabilities. ### Merge Request Integration - Findings appear in the merge request’s **Security Scanning** section. - Developers can review newly introduced and existing vulnerabilities during code review. - Each finding includes severity, affected packages, and remediation guidance. - This integrates container security into the development workflow instead of treating it as a separate post-deployment gate. ### Vulnerability Report The centralized Vulnerability Report is available under **Security & Compliance > Vulnerability Report**. - Aggregates container vulnerabilities across project branches. - Supports filtering by severity, status, scanner type, and container image. - Vulnerabilities can be assigned to team members and marked as detected, confirmed, resolved, or dismissed. - Teams can add comments and link related issues to track remediation. - Details show the affected images and layers, helping identify the source of a vulnerability. ### Dependency List and SBOM GitLab’s Dependency List provides a software bill of materials for container images. - Lists packages, libraries, and dependencies detected by Container Scanning. - Shows both base operating-system packages and application dependencies. - Supports filtering by package manager, license type, and vulnerability status. - Connects dependencies with their vulnerabilities for security and compliance analysis. ## Container Scanning for the Registry Registry scanning automatically analyzes images pushed to GitLab’s Container Registry with the `latest` tag. - **Purpose:** Continuously monitor registry images without requiring manual pipeline triggers. - **Availability:** Ultimate tier only. - **Trigger:** GitLab’s security policy bot scans `latest` images against the default branch. - **Continuous monitoring:** Works with Continuous Vulnerability Scanning to detect newly disclosed vulnerabilities. ### Enabling Registry Scanning - Go to **Secure > Security configuration**. - Find **Container Scanning for Registry**. - Toggle the feature on. ### Prerequisites - The user must have the Maintainer role or higher. - The project must contain at least one commit on its default branch. - Container Registry notifications must be configured. - The Package Metadata Database must be configured; it is enabled by default on GitLab.com. GitLab’s scanning options support both preventive CI/CD checks and ongoing registry monitoring. Teams should use pipeline-based scanning to catch vulnerabilities before deployment and registry scanning when they need continuous visibility into published images.

Read original(opens in new tab)
CI/CDGitlabSecurityTrivy+3
gitlab3 min readCurated summary

Extend GitLab Duo Agent Platform: Connect any tool with MCP

GitLab Duo Agent Platform can connect to Jira and other MCP-compatible tools, allowing developers to manage project data through natural-language requests inside their IDE. The post explains how to configure Atlassian OAuth, register Jira as an MCP server, and verify the connection in GitLab and VS Code. It concludes with practical workflows for backlog planning and creating or triaging issues directly from code context. ## MCP Architecture - GitLab Duo Agent Platform operates as the MCP client. - The Atlassian MCP server: - Authenticates users - Converts natural-language requests into Jira API calls - Returns structured results to GitLab Duo - Maintains security and audit controls - This integration reduces context switching between Jira, GitLab, and the IDE. ## Configure the Jira OAuth Application - Create an OAuth 2.0 integration in the Atlassian Developer Console. - Add Jira API permissions: - `read:jira-work` for issues, projects, and boards - `write:jira-work` for creating and updating issues - `read:jira-user` for user information - Configure the callback URL: - `https://gitlab.com/oauth/callback` - Copy the generated Client ID and Client Secret and store them securely. ## Configure GitLab Duo MCP - Create `.gitlab/duo/mcp.json` in the GitLab project. - Register the Atlassian MCP endpoint at: `https://mcp.atlassian.com/v1/mcp` - Configure OAuth authorization and token URLs: - `https://auth.atlassian.com/oauth/authorize` - `https://auth.atlassian.com/oauth/token` - Replace the placeholder credentials with the Jira OAuth values. - Enable **Allow external MCP tools** under **Group Settings → GitLab Duo → Configuration**. ## Verify the Connection - Ask GitLab Duo: - “What MCP tools do you have access to?” - “Test the MCP JIRA configuration in this project” - Approve access on the Atlassian MCP website and select the relevant Jira instance. - Use **GitLab: Show MCP Dashboard** from the VS Code or VSCodium Command Palette to inspect: - MCP server connection status - Available tools such as `jira_get_issue` and `jira_create_issue` - Real-time server logs and tool calls ## Planning and Backlog Prioritization - Query Jira from the GitLab Duo chat without leaving the IDE. - Find unassigned issues in a project. - Ask the assistant to: - Recommend the top issues to prioritize - Summarize their context - Assign selected issues to the current user - This supports sprint planning by combining Jira data with AI-generated prioritization. ## Issue Triage and Creation from Code - Developers can investigate bugs while reviewing code and interact with Jira conversationally. - Example workflows include: - Searching for an existing bug related to a code-level error - Creating a Jira issue if no matching ticket exists - Including relevant code context in the issue - Identifying possible blockers - Linking the issue to the current branch The integration is most useful when teams want Jira actions, planning, and issue management available directly within their development environment. Teams should configure OAuth scopes carefully, protect client credentials, and use the MCP Dashboard to monitor connections and tool activity.

Read original(opens in new tab)
Machine LearningModel Context ProtocolAutomationNatural Language Processing+4