Gitlab

98 posts

gitlab2 min readCurated summary

AI can detect vulnerabilities, but who governs risk?

AI can increasingly detect vulnerabilities and suggest fixes, but detection alone does not make software secure. The post argues that enterprises also need governance, context, continuous assurance, and supply-chain oversight to determine which risks are acceptable and what can ship. GitLab presents its platform as the orchestration layer for enforcing these controls across AI-assisted development. ## Trust Requires Governance - AI analysis is not the same as accountability. - Humans must define acceptable risk, policies, guardrails, separation of duties, and audit requirements. - As autonomous agents gain more control over development, stronger governance becomes essential rather than optional. - Governance enables organizations to trust AI at scale without relying on unchecked autonomy. ## Context Matters Beyond Code Scanning - LLMs typically assess code in isolation, while enterprise platforms can evaluate its broader context. - Important factors include: - Who authored the change - The application’s business criticality - Its dependencies and infrastructure interactions - Whether vulnerable code is reachable in production - Whether the vulnerability is exploitable in the actual runtime environment - Context reduces noisy alerts and supports faster, more effective risk triage. ## Risk Changes Continuously - Dependencies, environments, and system interactions evolve after an initial scan. - A clean static scan does not guarantee that software remains safe at release time. - Organizations need continuous assurance embedded throughout development, testing, and deployment. - Detection identifies risk, while ongoing governance determines how that risk is managed. ## Governing AI-Generated Software - Modern software combines AI-generated code, open-source libraries, and third-party dependencies across many projects. - Governing this entire supply chain is more difficult than detecting flaws in individual code changes. - The post argues that developer-side AI tools alone are not designed to provide organization-wide enforcement and auditability. - GitLab Ultimate is positioned as a platform combining policy enforcement, security scanning, governance, and auditing within software delivery workflows. Organizations adopting AI most successfully will pair capable coding assistants with strong, continuous governance. The practical recommendation is to treat AI security as a platform and lifecycle-management problem—not merely a vulnerability-detection problem.

Read original(opens in new tab)
gitlab3 min readCurated summary

Introducing the GitLab Managed Service Provider (MSP) Partner Program

GitLab has launched a global Managed Service Provider (MSP) Partner Program for qualified providers to deliver GitLab as a fully managed DevSecOps service. The program combines financial incentives, technical enablement, marketing support, and a structured onboarding process. It aims to help customers adopt and operate GitLab while enabling MSPs to build recurring, services-led revenue. ## Why the Program Matters - Many organizations lack the resources to deploy, administer, migrate, and continuously optimize a DevSecOps platform. - MSP partners can manage GitLab’s operational needs while development teams focus on building and delivering software. - The program provides formal requirements, enablement, dedicated support, and financial benefits for MSPs worldwide. - It addresses common customer challenges such as complex migrations, fragmented toolchains, and expanding security requirements. ## Benefits for MSP Partners - Partners receive standard GitLab margins plus an additional MSP premium on transactions, new business, and renewals. - MSPs retain all service fees from deployment, migration, training, enablement, and consulting. - Quarterly technical bootcamps cover releases, new features, best practices, roadmap updates, and peer experiences. - Recommended certifications include AWS Solutions Architect Associate and GCP Associate Cloud Engineer. - Go-to-market resources include: - A GitLab Certified MSP Partner badge - Co-brandable marketing assets - Eligibility for joint customer case studies - Partner Locator placement - Marketing Development Funds for qualified campaigns ## Customer Experience Customers receive a structured and repeatable managed DevSecOps service, including: - Documented implementation and migration methodologies - Platform deployment, administration, and ongoing support - Regular business reviews - Defined response and escalation procedures - Continuous platform optimization handled by the MSP ## Supporting AI Adoption GitLab MSPs can help organizations introduce AI-assisted development through the GitLab Duo Agent Platform. - MSPs can provide governance and operational guidance for AI adoption. - Customers can test AI workflows in controlled environments. - Managed services can help address data residency, compliance, and scaling requirements. - This approach reduces the burden on internal teams while enabling broader adoption of agentic AI. ## Who Should Apply The program is designed for MSPs that: - Already manage cloud, infrastructure, or application operations - Want to expand into DevSecOps services - Have, or plan to develop, relevant technical expertise - Prefer long-term customer relationships and recurring services revenue - Are existing GitLab Select or Professional Services Partners seeking a repeatable managed offering ## How to Get Started - Confirm business and technical eligibility using the program handbook. - Apply through the GitLab Partner Portal with supporting documentation. - Complete a structured 90-day onboarding process covering contracts, technical training, sales enablement, and an initial customer engagement. - Package the managed service, define SLAs, and launch the offering. - Applications are reviewed in approximately three business days. For MSPs with the necessary operational capabilities, the program offers a formal path to build a recurring GitLab managed services practice while helping customers adopt DevSecOps and AI more effectively.

Read original(opens in new tab)
gitlab2 min readCurated summary

Secure and fast deployments to Google Agent Engine with GitLab

Google Agent Engine provides a managed, scalable runtime for AI agents built with Google’s Agent Development Kit (ADK). The post shows how to deploy an ADK agent through GitLab using Workload Identity Federation, avoiding service-account keys while integrating security scanning into CI/CD. A GitLab pipeline can automatically test and deploy the agent to Agent Engine when changes reach the main branch. ## Agent Engine and GitLab - Agent Engine manages infrastructure, scaling, sessions, memory storage, logging, monitoring, and IAM. - GitLab simplifies deployment through: - Dependency scanning, SAST, and secret detection. - Native Google Cloud integration. - Keyless authentication with Workload Identity Federation. - CI/CD templates and the ADK deployment CLI. ## Prerequisites - A Google Cloud project with the Cloud Storage and Vertex AI APIs enabled. - A GitLab project containing the agent source code. - A Google Cloud Storage bucket for deployment staging. - GitLab’s Google Cloud IAM integration configured. ## Configure IAM with Workload Identity Federation - In GitLab, configure the Google Cloud IAM integration with: - Project ID - Project number - Workload Identity Pool ID - Provider ID - Run GitLab’s generated setup script in Google Cloud Shell. - Grant the federated service principal: - `roles/aiplatform.user` - `roles/storage.objectAdmin` - This setup lets GitLab authenticate to Google Cloud without storing long-lived service-account keys. ## Build the GitLab CI/CD Pipeline - Add a `.gitlab-ci.yml` file with `test` and `deploy` stages. - Use the `google/cloud-sdk:slim` image and define variables for: - Google Cloud project and region - Staging bucket - Agent name - Agent entry point - Include GitLab templates for: - Dependency scanning - Static application security testing - Secret detection - Enable keyless authentication with: ```yaml identity: google_cloud ``` - Install the ADK and required Google Cloud libraries during the job. - Deploy with: ```bash adk deploy agent_engine \ --project=$GCP_PROJECT_ID \ --region=$GCP_REGION \ --staging_bucket=gs://$STORAGE_BUCKET \ --display_name="$AGENT_NAME" \ $AGENT_ENTRY ``` - Restrict deployment to the `main` branch. - Cache Python dependencies to speed up later pipeline runs. ## Deploy and Verify - Commit the agent code and `.gitlab-ci.yml` to GitLab. - Monitor the pipeline under **Build > Pipelines**. - Confirm that security scans complete successfully before deployment. - The deployment stage packages the agent, places it in the staging bucket, and publishes it to Agent Engine. The recommended approach is to combine GitLab’s built-in security checks and Workload Identity Federation with the ADK CLI. This provides a secure, keyless, and repeatable deployment process for Google AI agents.

Read original(opens in new tab)
gitlab2 min readCurated summary

Passkeys now available for passwordless sign-in and 2FA on GitLab

GitLab now supports passkeys for passwordless sign-in and phishing-resistant two-factor authentication. Built on WebAuthn and public-key cryptography, passkeys let users authenticate with a fingerprint, face recognition, or device PIN while keeping the private key on their device. Users can register multiple passkeys across browsers, mobile devices, and FIDO2 security keys, improving both security and convenience. ## Passkeys for Sign-In and 2FA - Passkeys can be used: - As a passwordless login method. - As a phishing-resistant 2FA method. - For accounts with 2FA enabled, passkeys automatically become the default 2FA option. - Authentication uses a device fingerprint, facial recognition, or PIN. ## Registration and Compatibility - Users can register passkeys under **Profile settings > Account > Manage authentication**. - Supported platforms include: - Chrome, Firefox, Safari, and Edge. - iOS 16 and later. - Android 9 and later. - FIDO2 hardware security keys. - Multiple passkeys can be registered for access across different devices. ## WebAuthn Security Model - Passkeys rely on WebAuthn and public-key cryptography. - The private key remains securely stored on the user’s device and is never sent to GitLab. - GitLab stores only the public key. - A breach of GitLab’s stored credentials would not give attackers usable private keys for account access. ## GitLab’s Security Goals - Passkeys support GitLab’s commitment under the CISA Secure by Design Pledge. - They help increase MFA adoption while providing a smoother, phishing-resistant authentication experience. - GitLab invites users to provide feedback through its community and feedback channels. Users should register passkeys in their GitLab authentication settings, ideally across multiple trusted devices or security keys for both stronger protection and account recovery.

Read original(opens in new tab)
gitlab2 min readCurated summary

GitLab metrics and registry features help reduce CI/CD bottlenecks

GitLab’s two new beta features target common CI/CD bottlenecks without requiring additional third-party tools. CI/CD Job Performance Metrics provides job-level visibility into duration and failures, while Container Virtual Registry centralizes pulls from multiple registries through a cached GitLab endpoint. Together, they help platform teams identify pipeline problems faster and simplify container management. ## CI/CD Job Performance Metrics - Available in GitLab Premium and Ultimate. - Limited beta on GitLab.com; available on Self-Managed and Dedicated with ClickHouse configured. - Adds a job-focused panel to **Analyze > CI/CD analytics**. - Shows, for the previous 30 days by default: - Median (P50) and worst-case (P95) job duration - Failure rate - Job name and pipeline stage - Supports sorting, searching, and pagination to identify slow or unreliable jobs. - GitLab plans to add stage-level aggregation for build, test, and deploy bottlenecks. ## Container Virtual Registry - Available in GitLab Premium and Ultimate; API-ready in GitLab 18.9. - Provides one GitLab endpoint for pulling images from multiple upstream registries. - Supports registries such as Docker Hub, Harbor, Quay, and other sources using long-lived token authentication. - Uses pull-through caching to: - Reduce repeated downloads and bandwidth costs - Improve availability and reliability - Centralize authentication and registry configuration - Currently configured through the API, with UI management in development. - Cloud registries requiring IAM authentication, including Amazon ECR, Google Artifact Registry, and Azure Container Registry, may be supported later. ## Beta Access and Feedback - GitLab.com users can request access through their customer success manager or the feature’s feedback issue. - Self-managed users can enable the feature flag and configure the virtual registry through the API. - GitLab is seeking feedback to guide future improvements to both features. These betas are worth evaluating if your team needs better visibility into pipeline performance or manages images across several registries. The metrics feature can replace custom dashboards, while the virtual registry can reduce registry-related configuration and operational overhead.

Read original(opens in new tab)
gitlab3 min readCurated summary

Agentic SDLC: GitLab and TCS deliver Intelligent Orchestration across the enterprise

GitLab and TCS are partnering to help enterprises scale DevSecOps through AI-agent orchestration. Their combined approach addresses fragmented toolchains, inconsistent security, manual compliance, and the risks of AI-generated code by combining GitLab’s unified platform and guardrails with TCS’s migration, architecture, and industry expertise. The goal is to evolve DevSecOps into auditable “Intelligent Orchestration,” where humans and AI agents collaborate across the software lifecycle. ## Supporting the Future-Ready Enterprise - GitLab’s unified data model connects planning, coding, testing, security, and deployment in one source of context. - Enterprises can standardize pipelines, controls, and metrics without repeatedly re-engineering their development platforms. - GitLab and TCS combine: - Multi-agent orchestration - Dynamic planning - Confidence-scored decisions - Continuous learning cycles - GitLab Duo agents, including Planner, Security Analyst, and Code Review agents, can be invoked through MCP-driven integrations and TCS’s structured agent hierarchy. - These agents operate with project context while remaining subject to GitLab’s AI-native DevSecOps controls. ## Scaling DevSecOps Through Platform Engineering - Platform engineering replaces individually managed pipelines with an Internal Developer Platform (IDP). - Self-service “golden paths” standardize how applications are built, tested, secured, and deployed. - Policy-as-code embeds governance, compliance, and security into development by default. - GitLab serves as the IDP control plane. - TCS designs and industrializes self-service workflows around that control plane. - GitLab Duo adds AI-driven automation to development and operational tasks. ## From DevSecOps to Intelligent Orchestration - Traditional DevSecOps platforms manage code, pipelines, and controls; intelligent orchestration also coordinates human and AI work. - GitLab Duo agents can work in parallel on: - Code generation - Testing - Code review - Security analysis - CI/CD troubleshooting - Pipeline repair - Developers remain in control through rules and guidance while agents handle repetitive or multi-step work. - Agent actions are contextual, auditable, and policy-aligned. - This allows organizations to extend AI across thousands of engineers while preserving security and regulatory compliance. ## The GitLab–TCS Reference Architecture - GitLab contributes: - Intelligent Orchestration across the DevSecOps lifecycle - Unified project context - Specialized AI agents - Integrated security and compliance controls - TCS contributes: - Reference architectures - Migration factories - Enterprise security baselines - AI capabilities and risk-management frameworks - Platform engineering and adoption programs - TCS’s industry and regulatory experience helps adapt GitLab to legacy systems, organizational models, compliance obligations, and multi-cloud environments. - The partnership emphasizes enterprise-scale adoption rather than isolated tooling deployments. Together, GitLab and TCS recommend building an Internal Developer Platform with embedded policy-as-code, self-service workflows, and governed AI agents. This approach can reduce delivery friction and manual toil while allowing enterprises to scale automation without sacrificing oversight, security, or compliance.

Read original(opens in new tab)
gitlab2 min readCurated summary

GPG key used to sign GitLab package repositories' metadata has been extended

GitLab has extended the expiration date of the GPG key used to sign metadata for its APT and YUM repositories. The key, fingerprint `F640 3F65 44A3 8863 DAA0 B6E0 3F01 618A 5131 2F3F`, now expires on February 6, 2028, rather than February 27, 2026. Existing users may need to refresh the key, while new users can follow the standard GitLab installation instructions. ## Purpose of the Signing Key - GitLab uses GPG signatures to protect repository metadata for: - `omnibus-gitlab` packages - `gitlab-runner` packages - Repository metadata signing is separate from package signing. - The key’s expiration is periodically extended to follow security policies and reduce exposure if it is compromised. ## Required Actions - Users who configured GitLab repositories before February 17, 2026, should follow GitLab’s documentation to fetch and install the updated key. - New users do not need special steps beyond following the GitLab or GitLab Runner installation guides. - The public key can be retrieved: - From GPG keyservers using the fingerprint or associated email address - Directly at `https://packages.gitlab.com/gpg.key` ## Getting Help - Documentation explains how to verify repository metadata signatures. - Additional issues should be reported in the `omnibus-gitlab` issue tracker. Users with existing GitLab package repositories should refresh their trusted GPG key to avoid future signature-validation problems.

Read original(opens in new tab)
gitlabOriginal article

GitLab extends Omnibus package signing key expiration to 2028 (opens in new tab)

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.

gitlabOriginal article

Track vulnerability remediation with the updated GitLab Security Dashboard (opens in new tab)

The updated GitLab Security Dashboard addresses the challenge of vulnerability overload by shifting the focus from simple detection to contextual remediation and risk management. By providing integrated trend tracking and sophisticated risk scoring, the platform enables security and development teams to prioritize high-risk projects and measure the actual progress of their security programs. This update transforms raw security data into actionable insights that are tracked directly within the existing DevSecOps workflow. ## Transitioning from Detection to Remediation Context * Consolidates vulnerability data into a single view that spans across projects, groups, and entire business units to eliminate data silos. * Introduced initial time-based tracking in version 18.6, with version 18.9 adding expanded filters for severity, status, scanner type, and project. * Provides visualizations for remediation velocity and vulnerability age distribution, moving beyond static raw counts to show how quickly threats are being addressed. ## Data-Driven Prioritization with Risk Scoring * Utilizes a dynamic risk score calculated from multiple factors, including vulnerability age and repository security postures. * Integrates external threat intelligence such as the Exploit Prediction Scoring System (EPSS) and Known Exploited Vulnerability (KEV) scores to identify the most critical threats. * Allows teams to monitor risk scores over time to pinpoint specific areas of the infrastructure that require additional resources or immediate intervention. ## Strategic Impact for Security and Development Teams * Enables security leaders to prove program effectiveness to executives by showing downward trends in Common Weakness Enumeration (CWE) types and shrinking backlogs. * Streamlines the developer experience by highlighting critical vulnerabilities within active projects, removing the need for external spreadsheets or manual reporting tools. * Identifies specific teams or departments that may require additional remediation training based on their ability to meet company security policies. Organizations should leverage these updated dashboard features to transition from manual, reactive security tracking to an automated, risk-based posture. By integrating EPSS and KEV data into daily workflows, teams can ensure they are solving the most dangerous vulnerabilities first while maintaining a clear, measurable record of their security improvements.

gitlabOriginal article

GitLab Threat Intelligence Team reveals North Korean tradecraft (opens in new tab)

The GitLab Threat Intelligence Team has detailed its efforts to disrupt North Korean (DPRK) cyber campaigns, specifically focusing on "Contagious Interview" malware distribution and fraudulent IT worker schemes. By analyzing internal platform data, GitLab identified that these state-sponsored actors leverage legitimate tools and fake recruitment scenarios to compromise software developers and generate illicit revenue for the regime. The report concludes that while these operations are sophisticated and persistent, proactive monitoring and cross-industry intelligence sharing are essential to mitigating these evolving threats. ### Contagious Interview Mechanics * Threat actors pose as recruiters to trick software developers into executing malicious JavaScript projects under the guise of technical interviews. * The primary goal is to deploy malware families such as BeaverTail and Ottercookie, which facilitate credential theft and provide remote control of the victim's device. * A notable evolution in tradecraft includes the use of "ClickFix," a compiled BeaverTail variant identified in late 2025. * Malicious repositories often use a specific execution pattern where base64-encoded URLs and secret headers are hidden within `.env` files, masquerading as benign configuration variables. * To execute the payload, actors utilize `Function.constructor` to load strings as executable code, often triggered by custom error handlers designed to source remote content. ### 2025 Campaign Trends and Infrastructure * GitLab banned 131 unique accounts linked to these campaigns in 2025, with activity peaking in September and averaging 11 bans per month. * Nearly 90% of malicious accounts were created using Gmail addresses, and actors typically accessed the platform through consumer VPNs or dedicated VPS infrastructure. * In more than 80% of cases, malware payloads were not stored on GitLab. Instead, actors used concealed loaders to fetch content from legitimate hosting services, most commonly Vercel. * Recent tactics include the creation of malicious NPM dependencies immediately before use and the exploitation of VS Code tasks to pipe remote content into native shells. ### IT Worker Campaigns and Sanctions Evasion * Beyond malware distribution, DPRK actors use GitLab to support "IT worker" cells that generate revenue and evade international sanctions. * One identified pipeline involved the creation of at least 135 synthetic identities, automated to generate professional connections and contact leads at scale. * Threat actors have been observed adding their own images to stolen U.S. identity documents to bypass employment verification processes. * Forensic analysis revealed financial records from cell managers detailing revenue proceeds from 2022 through 2025, often earned while operating from locations like Moscow, Russia. Organizations should remain vigilant against recruitment-themed social engineering and scrutinize unexpected requests to run external code. GitLab recommends that the security community use the provided indicators of compromise to update defensive posture, as these actors continue to refine their ability to hide malicious intent within legitimate development workflows.

gitlabOriginal article

Agentic AI, enterprise control: Self-hosted Duo Agent Platform and BYOM (opens in new tab)

GitLab 18.9 introduces critical updates designed to provide regulated enterprises with governed, agentic AI capabilities through self-hosted infrastructure and model flexibility. By combining the Duo Agent Platform with Bring Your Own Model (BYOM) support, organizations in sectors like finance and government can now automate complex DevSecOps workflows while maintaining total control over data residency. This release transforms GitLab into a high-security AI control plane that balances the need for advanced automation with the rigid sovereignty requirements of high-compliance environments. ## Self-Hosted Duo Agent Platform for Online Cloud Licenses The Duo Agent Platform allows engineering teams to automate sequences of tasks, such as hardening CI/CD pipelines and triaging vulnerabilities, but was previously difficult to deploy for customers under strict online cloud licensing. This update makes the platform generally available for these environments, bridging the gap between cloud-based licensing and self-hosted security needs. * **Usage-Based Billing:** The platform now utilizes GitLab Credits to provide transparent, per-request metering, which is essential for internal chargeback and regulatory reporting. * **Infrastructure Control:** Enterprises can host models on their own internal infrastructure or within approved cloud environments, ensuring that inference traffic is routed according to internal security policies. * **Deployment Readiness:** By removing the requirement to route data through external AI vendors, the platform is now a viable option for critical infrastructure and government agencies. ## Bring Your Own Model (BYOM) Integration Recognizing that many enterprises have already invested in domain-tuned LLMs or air-gapped deployments, GitLab now allows customers to integrate their existing models directly into the Duo Agent Platform. This ensures that organizations are not locked into a specific vendor and can leverage models that have already passed internal risk assessments. * **AI Gateway Connectivity:** Administrators can connect third-party or internal models via the GitLab AI Gateway, allowing these models to function as enterprise-ready options within the GitLab ecosystem. * **Granular Model Mapping:** The system provides the ability to map specific models to individual Duo Agent Platform flows or features, giving admins fine-grained control over which agent uses which model. * **Administrative Ownership:** While GitLab provides the orchestration layer, administrators retain full responsibility for model validation, performance tuning, and risk evaluation for the models they choose to bring. For organizations operating in high-compliance sectors, these updates offer a path to consolidate fragmented AI tools into a single, governed platform. Engineering leaders should evaluate their current model investments and leverage the GitLab AI Gateway to unify their automation workflows under one secure DevSecOps umbrella.

gitlabOriginal article

GitLab backs 99.9% availability SLA with service credits (opens in new tab)

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.

gitlabOriginal article

Claude Opus 4.6 now available in GitLab Duo Agent Platform (opens in new tab)

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.

gitlabOriginal article

DevSecOps-as-a-Service on Oracle Cloud Infrastructure by Data Intensity (opens in new tab)

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.

gitlabOriginal article

How to set up GitLab SAML SSO with Google Workspace (opens in new tab)

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.