23 posts
gitlab Published on: March 4, 2026 10 min read How GitLab built a security control framework from scratch GitLab's Security Compliance team created a custom control framework to scale across multiple certifications and products — here's why and how you can, too. security tutorial GitLa…
gitlab Organizations using GitLab.com SaaS can streamline access control by integrating SAML-based Single Sign-On (SSO) with Google Workspace. This setup enables automated user provisioning and dynamic permission management by mapping Google Workspace groups directly to GitLab roles. The result is a centralized security model that reduces manual administrative tasks while ensuring users have immediate, secure access to the platform. ### Prerequisites and Architectural Benefits * The integration requires a GitLab Premium or Ultimate subscription and Super Admin access to Google Workspace. * Once configured, the authentication flow redirects users to Google for credentials, after which Google sends a SAML assertion to GitLab containing user details and group memberships. * The system supports "Just-in-Time" provisioning, meaning GitLab accounts are created automatically upon a user's first successful login. * Permissions are dynamic; GitLab updates group memberships and roles every time a user signs in to reflect their current status in Google Workspace. ### Gathering GitLab Configuration Details * Configuration must be performed at the GitLab top-level group rather than within individual subgroups. * Administrators need to retrieve the Assertion Consumer Service (ACS) URL, which typically follows the format `https://gitlab.com/groups/[your-group]/-/saml/callback`. * The Identifier (Entity ID) must be copied to uniquely identify the GitLab group within the Google identity provider settings. * The GitLab SSO URL is the specific entry point users will utilize to initiate the authentication process. ### Configuring the Google Workspace SAML Application * Within the Google Admin Console, administrators must create a "Custom SAML app" to house the integration settings. * The setup process provides a Google SSO URL and a certificate file (typically a `.pem` format) that must be saved for the GitLab-side configuration. * The previously gathered GitLab ACS URL and Entity ID are entered into the Service Provider details section of the Google app configuration. ### Mapping User Attributes and Synchronizing Groups * Specific attribute mapping is required to ensure user data flows correctly: Google’s "Primary Email" should map to the "NameID," "First Name" to "firstName," and "Last Name" to "lastName." * For group synchronization to function, administrators must map selected Google Groups to an app attribute named exactly `groups` (lowercase). * Google allows for the synchronization of up to 75 groups, which GitLab uses to determine and update user permissions upon login. * The application must be explicitly turned "ON" for specific organizational units or the entire domain within the Google Admin Console to allow user access. ### Finalizing the Identity Provider Connection * GitLab requires a SHA-1 certificate fingerprint for security verification rather than the raw certificate file provided by Google. * Administrators must convert the downloaded Google `.pem` certificate into a SHA-1 fingerprint using an online conversion tool or a command-line utility. * This fingerprint, along with the Google SSO URL, is entered into GitLab’s SAML SSO settings to establish the trusted connection between the two platforms. To ensure a smooth rollout, it is recommended to test the integration with a small group of users before enforcing SAML for the entire organization. This allows administrators to verify that group-based permissions are mapping correctly to GitLab roles without disrupting existing workflows.
gitlab Published on: February 25, 2026 2 min read Passkeys now available for passwordless sign-in and 2FA on GitLab Learn how to register a passkey to your account and how two-factor authentication works as a phishing-resistant method. security product Passkeys are now available on Git…
gitlab The GitLab Duo Agent Platform introduces flows as a sophisticated orchestration layer that allows multiple specialized AI agents to collaborate on complex, multi-step developer workflows. Unlike standard interactive agents, flows are designed to work autonomously and asynchronously on GitLab’s platform compute, executing tasks ranging from initial requirement analysis to final merge request creation. This architecture enables teams to offload repetitive or high-compliance tasks to a background process that integrates directly with the existing GitLab ecosystem. ## Core Mechanics of Multi-Agent Flows * Flows function as event-driven systems triggered by specific actions such as @mentions, issue assignments, or being designated as a reviewer on a merge request. * Execution occurs on GitLab's platform compute, removing the need for users to maintain separate infrastructure for their automation logic. * While standard agents are interactive and synchronous, flows are designed to be autonomous, gathering context and making decisions across various project files and APIs without constant human intervention. * The system supports background processing, allowing developers to continue working on other tasks while the flow handles complex implementations or security audits. ## Foundational and Custom Flow Categories * Foundational flows are production-ready, general-purpose workflows maintained by GitLab and accessible through standard UI controls and IDE interfaces. * Custom flows are specialized workflows defined via YAML that allow teams to tailor AI behavior to unique organizational requirements, such as specific coding standards or regulatory compliance like PCI-DSS. * Custom flows utilize a YAML schema to define specific components, including "Routers" for logic steering and "Toolsets" that grant agents access to GitLab API functions. * Real-world applications for custom flows include automated security scanning, documentation generation, and complex dependency management across a project. ## Technical Configuration and Triggers * Flows are triggered through simple Git commands and UI actions, such as `/assign @flow-name` or `/assign_reviewer @flow-name`. * The configuration for a custom flow includes an "ambient" environment setting and defines specific `AgentComponents` that map to unique prompts and toolsets. * Toolsets provide agents with capabilities such as `get_repository_file`, `create_commit`, `create_merge_request`, and `blob_search`, enabling them to interact with the codebase programmatically. * YAML definitions also manage UI log events, allowing users to track agent progress through specific hooks like `on_tool_execution_success` or `on_agent_final_answer`. To maximize the value of the GitLab Duo Agent Platform, teams should identify repetitive compliance or boilerplate implementation tasks and codify them into custom flows. By defining precise prompts and toolsets within the YAML schema, organizations can ensure that AI-driven automation adheres to internal domain expertise and coding standards while maintaining a high level of transparency through integrated UI logging.
gitlab The GitLab AI Catalog serves as a centralized repository designed to streamline the discovery, creation, and distribution of AI agents and automated flows across an organization. By providing a structured environment for managing foundational and custom AI assets, it fosters team collaboration and ensures consistency throughout the development lifecycle. Ultimately, the catalog enables developers to scale AI-driven automation from experimental private prototypes to production-ready, instance-wide solutions. ## Discovering and Enabling AI Assets * The catalog acts as a central hub for two distinct asset types: Agents, which handle on-demand or context-specific tasks, and Flows, which are multi-step automations that orchestrate multiple agents. * Users can browse assets via the Explore menu, inspecting titles, descriptions, and visibility statuses before implementation. * To utilize an asset, it must first be added to a top-level group via the "Enable in group" button and then activated within specific projects. * The duplication feature allows teams to copy existing agents or flows to serve as templates for further customization. ## Development and Configuration * Custom agents are built by defining specialized system prompts and configuring specific tool access, such as granting read-only permissions for code and merge requests. * Custom flows utilize a YAML-based structure to define complex behaviors, incorporating components like prompts, routers, and agent hierarchies. * New assets are typically assigned a unique display name (e.g., `ci-cd-optimizer`) and initially set to private visibility to allow for safe experimentation. * Effective creation requires thorough documentation of prerequisites, dependencies, and specific use cases to ensure the asset is maintainable by other team members. ## Managing Visibility and Sharing * Private visibility restricts access to project members with at least a Developer role or top-level group Owners, making it ideal for sensitive or team-specific workflows. * Public visibility allows anyone on the GitLab instance to view and enable the asset in their own projects. * Best practices for sharing include using descriptive, purpose-driven names like `security-code-review` rather than generic identifiers. * Organizations are encouraged to validate and test assets privately before moving them to public status to ensure they solve real problems and handle edge cases. ## Versioning and Lifecycle Management * GitLab employs automated semantic versioning (e.g., 1.1.0) where any change to a prompt or configuration triggers an immutable version update. * The platform uses "version pinning" to ensure stability; when an asset is enabled, projects remain on a fixed version rather than updating automatically. * Updates are strictly opt-in, requiring users to manually review changes and click an "Update" button to adopt the latest version. * Version history and current status can be monitored through the "About" section in the Automate menu for both agents and flows. To maximize the benefits of the AI Catalog, organizations should establish a clear transition path from private experimentation to public sharing. By leveraging version pinning and granular tool access, teams can safely integrate powerful AI automations into their development workflows while maintaining full control over environment stability and security.
gitlab GitLab has introduced a 99.9% availability service-level agreement (SLA) specifically for Ultimate customers on GitLab.com and GitLab Dedicated. This commitment is backed by service credits to ensure that mission-critical DevSecOps workflows remain uninterrupted and to align GitLab's interests with customer business outcomes. By formalizing this uptime guarantee, GitLab aims to provide a reliable foundation for high-velocity teams that depend on continuous code pushes and automated deployments. ## Scope of Covered Services The SLA covers the core platform experiences essential to daily software delivery workflows: * Issues and merge requests management. * Git operations, including push, pull, and clone actions via both HTTPS and SSH protocols. * Operations within the Container Registry and Package Registry. * API requests associated with the aforementioned core services. ## Defining and Measuring Downtime Service availability is tracked via automated monitoring across multiple geographic locations to reflect actual user experience. * A "downtime minute" is triggered when 5% or more of valid customer requests result in server errors. * Server errors are strictly defined as HTTP 5xx status codes or connection timeouts exceeding 30 seconds. * While monitoring focuses on server-side failures, GitLab will also holistically review claims for issues that might not trigger 5xx errors, such as Sidekiq job processing outages or specific application bugs. ## Service Credit Claim Procedure To maintain accountability, GitLab has established a formal process for Ultimate customers to recoup costs during outages: * Customers must submit a support request at support.gitlab.com within 30 days of the end of the month in which the downtime occurred. * The GitLab team validates the claim against internal and external monitoring data. * Validated service credits are applied directly to the customer's next issued invoice, with the credit amount scaled based on the severity of the availability shortfall. Ultimate customers should familiarize their operations teams with these specific performance thresholds and the 30-day claim window to ensure they are adequately compensated during significant service disruptions.
gitlab Published on: March 5, 2026 11 min read A complete guide to GitLab Container Scanning Explore GitLab's various container scanning methods and learn how to secure containers at every lifecycle stage. security tutorial Container vulnerabilities don't wait for your next deployment.…
gitlab GitLab has extended the expiration of its GNU Privacy Guard (GPG) key used for signing Omnibus packages from February 2026 to February 16, 2028. This extension ensures the continued integrity of packages created within CI pipelines while remaining compliant with GitLab’s internal security policies regarding key exposure. By opting to extend the current key rather than rotating to a new one, GitLab aims to minimize administrative overhead for users who would otherwise be required to replace their trusted keys. ### Purpose and Scope of the Key Extension * The GPG key is specifically dedicated to signing Omnibus packages to prevent tampering; it is distinct from the keys used for repository metadata (apt/yum) and the GitLab Runner. * GitLab periodically extends the expiration of these keys to limit the potential impact of a compromise while adhering to modern security standards. * The decision to extend rather than rotate was made specifically to be less disruptive to the user base, as rotation mandates a manual replacement of the trusted key on all client systems. ### Impact and Required Actions * Users who do not specifically verify package signatures or have not configured their package managers to do so require no action to continue installing updates. * Administrators who validate Omnibus package signatures must update their local copies of the public key to reflect the 2028 expiration date. * The updated key can be found on GPG keyservers by searching for the ID `98BF DB87 FCF1 0076 416C 1E0B AD99 7ACC 82DD 593D` or the email `packages@gitlab.com`. * A direct download of the public key is also available through the official GitLab packages repository URL. Organizations that verify package signatures should refresh their trusted GPG keys as soon as possible to ensure seamless updates leading up to the original 2026 deadline. If technical issues arise during the update process, GitLab recommends opening an issue in the omnibus-gitlab tracker for support.
gitlab Published on: February 25, 2026 5 min read New GitLab metrics and registry features help reduce CI/CD bottlenecks See how CI/CD Job Performance Metrics and Container Virtual Registry, currently in beta, help platform teams quickly spot slow jobs and simplify multi-registry conta…
gitlab Published on: February 24, 2026 2 min read GPG key used to sign GitLab package repositories' metadata has been extended The GPG key used to sign repository metadata on GitLab's Packagecloud instance at packages.gitlab.com has been extended – here's what you need to know. product…
gitlab Data Intensity’s DevSecOps-as-a-Service provides a solution for organizations that require the granular control of GitLab Self-Managed but wish to eliminate the operational burden of infrastructure maintenance. By hosting dedicated GitLab instances on Oracle Cloud Infrastructure (OCI), the service combines the security and customization of a self-managed environment with the convenience of a fully managed platform. This partnership enables teams to focus on software delivery while leveraging expert management for high availability and disaster recovery. ### The Benefits of GitLab Self-Managed * Offers complete ownership of data residency and instance configuration to meet strict regulatory and compliance requirements. * Enables deep customization and integration possibilities that are often restricted in standard SaaS environments. * Addresses the challenges of manual server management, upgrades, and high-availability scaling by offloading these tasks to a managed provider. ### Managed Service Features and Support * Provides 24/7 monitoring, alarming, and expert technical support for standalone GitLab instances. * Includes scheduled quarterly patching performed during customer-specified maintenance windows to minimize disruption. * Ensures business continuity through automated backups and professional disaster recovery protection. * Utilizes tiered architectures designed to scale based on specific user capacities and recovery time objectives. ### Infrastructure Optimization via OCI * Delivers significant cost efficiency, with organizations typically realizing 40-50% reductions in infrastructure spending compared to other hyperscalers. * Supports diverse deployment models, including Public Cloud, Government Cloud, EU Sovereign Clouds, and dedicated infrastructure behind a corporate firewall. * Maintains consistent pricing and operational tooling across hybrid, global, and regulated environments. ### Implementation and Migration * Data Intensity offers optional migration services to transition existing code repositories and configurations to the OCI environment seamlessly. * The service is specifically designed for organizations with predictable cost requirements and those lacking in-house infrastructure expertise. * Deployment planning involves tailored consultations to match specific compliance and data residency needs with OCI’s global region availability. This managed service is a recommended path for enterprise teams that need to prioritize data sovereignty and flexibility without sacrificing the speed of a turnkey solution. Organizations currently using or planning to adopt OCI can leverage this service to standardize their DevSecOps workflows while achieving significant infrastructure savings.
gitlab Published on: February 27, 2026 4 min read AI can detect vulnerabilities, but who governs risk? AI-assisted vulnerability detection is developing fast, but the harder challenges of enforcement, governance, and supply chain security require a holistic platform. AI/ML security Ant…
gitlab GitLab has integrated Anthropic’s Claude Opus 4.6 into its Duo Agent Platform, providing developers with a high-intelligence frontier model designed for complex agentic workflows. By combining a 1-million-token context window with native access to DevSecOps data, the update enables more autonomous task execution and deeper reasoning within the software development lifecycle. This integration allows teams to delegate multi-step tasks to AI agents that can now process entire codebases and project histories in a single interaction. ## Advanced Agentic Capabilities and Reasoning * Claude Opus 4.6 features enhanced "agentic" behavior, meaning it can proactively take actions and drive tasks forward with minimal human intervention. * The model supports multi-agent orchestration, allowing it to spin up subagents and coordinate parallel workstreams to solve complex, multi-step problems. * Adaptive thinking capabilities allow the model to calibrate its reasoning depth based on the query, using extended thinking for difficult tasks while maintaining speed for simpler ones. * Deep reasoning via test-time compute helps the model navigate challenging development bottlenecks and architectural decisions. ## Full-Context DevSecOps Integration * The model boasts a 1-million-token context window—a fivefold increase over Opus 4.5—enabling the processing of massive codebases and extensive documentation. * Integration with the GitLab Duo Agent Platform provides the model with direct access to repositories, merge requests, pipelines, and security findings. * Enterprise-grade security features, including human-in-the-loop controls and group-based access, ensure that agentic actions remain transparent and governed. * Native integration ensures developers can utilize these frontier capabilities without leaving their established GitLab workflows. ## Availability and Resource Consumption * Opus 4.6 is currently available for GitLab.com users via the Duo Agent Platform and Agentic Chat, though it is not supported for GitLab Duo Classic features. * Support for the model within various Integrated Development Environments (IDEs) is expected to be released in the near future. * Usage is managed via GitLab credits, with multipliers determined by the size of the prompt. * Prompts containing 200k tokens or fewer are charged at 1.2 requests per credit, while larger prompts exceeding 200k tokens are charged at 0.7 requests per credit. Organizations aiming to automate complex development workstreams should migrate their specialized agents to Claude Opus 4.6 to take advantage of its superior orchestration and context handling. By leveraging the model's ability to coordinate parallel subagents, teams can significantly reduce the manual effort required for codebase-wide refactors and security remediation.
gitlab GitLab has updated its HackerOne Bug Bounty program policies to improve transparency and streamline the reporting process for security researchers. These changes emphasize a shift toward local testing environments and provide much-needed clarity on the scope of emerging threats like AI prompt injection and denial-of-service attacks. By refining these guidelines, GitLab aims to protect its production infrastructure while ensuring researchers have clear, objective criteria for submitting high-impact vulnerabilities. ### Enhanced Testing Guidance * GitLab now strongly recommends using the GitLab Development Kit (GDK) for local testing, allowing researchers to experiment with cutting-edge features without risking production stability. * Researchers investigating potential Denial-of-Service (DoS) impacts are advised to use self-managed GitLab instances that meet or exceed standard installation requirements. * Any testing performed on GitLab.com production architecture must utilize test accounts created specifically with the `@wearehackerone.com` email alias. ### Refined Vulnerability Scope * Denial-of-Service (DoS) is generally classified as out of scope, though exceptions exist for application-layer vulnerabilities—such as ReDoS or logic bombs—that cause persistent service disruption via unauthenticated endpoints. * Standalone prompt injection is no longer eligible for bounties unless it serves as a primary vector to achieve security breaches beyond the initial AI boundary. * The policy clarifies the distinction between metadata enumeration and privacy breaches, noting that general information gathering remains out of scope while exposure of confidential data is strictly in scope. ### Transition and Grace Period * To support researchers with ongoing investigations, GitLab is honoring a seven-day grace period for DoS reports submitted before January 22, 2026 (9:00 p.m. PT). * Reports submitted during this window will be evaluated under the previous policy to ensure fairness and maintain trust within the researcher community. Security researchers should immediately update their testing workflows by downloading the GitLab Development Kit and reviewing the updated CVSS calculator on the HackerOne program page to ensure their findings align with the new severity standards.
gitlab The GitLab Duo Agent Platform has reached general availability, marking a shift from basic AI code assistance to comprehensive agentic automation across the entire software development lifecycle. By orchestrating intelligent agents to handle complex tasks like security analysis and planning, the platform aims to resolve the "AI paradox" where faster code generation often creates downstream bottlenecks in review and deployment. ### Usage-Based Economy via GitLab Credits * GitLab is introducing "GitLab Credits," a virtual currency used to power the platform’s usage-based AI features. * Premium and Ultimate subscribers receive monthly credits ($12 and $24 respectively) at no additional cost to facilitate immediate adoption. * Organizations can manage a shared pool of credits or opt for on-demand monthly billing, with existing Duo Enterprise contracts eligible for conversion into credits. ### Agentic Chat and Contextual Orchestration * The Duo Agentic Chat provides a unified experience across the GitLab Web UI and various IDEs, including VS Code, JetBrains, Cursor, and Windsurf. * The chat utilizes multi-step reasoning to perform actions autonomously, drawing from the context of issues, merge requests, pipelines, and security findings. * Capabilities extend beyond code generation to include infrastructure-as-code (IaC) creation, pipeline troubleshooting, and explaining vulnerability reachability. ### Specialized Foundational and Custom Agents * **Foundational Agents:** Pre-built specialists designed for specific roles, such as the Planner Agent for breaking down work and the Security Analyst Agent for triaging vulnerabilities. * **Custom Agents:** Developed through a central AI Catalog, these allow teams to build and share agents that adhere to organization-specific engineering standards and guardrails. * **External Agents:** Native integration of third-party AI tools, such as Anthropic’s Claude Code and OpenAI’s Codex CLI, provides access to external LLM capabilities within the governed GitLab environment. ### Automated End-to-End Flows * The platform introduces "Flows," which are multi-step agentic sequences designed to automate repeatable transitions in the development cycle. * The "Issue to Merge Request" flow builds structured code changes directly from defined requirements to jumpstart development. * Specialized CI/CD flows help teams modernize pipeline configurations and automatically analyze and suggest fixes for failed pipeline runs. * The Code Review flow streamlines the feedback loop by providing AI-native analysis of merge request comments and code changes. To maximize the impact of agentic AI, organizations should move beyond basic chat interactions and begin integrating these specialized agents into their broader orchestration workflows to eliminate manual handoffs between planning, coding, and security.