gitlab·Mar 4, 2026·2 min readCurated summary

10 AI prompts to speed your team’s software delivery

AI-assisted coding can accelerate code production without accelerating delivery, because review, security, documentation, and planning often become the new bottlenecks. The post recommends applying AI across the full software lifecycle, using targeted prompts to reduce routine work and let teams focus on architecture, risk, and business decisions. ## Code Review as an Accelerator - AI can review merge requests (MRs) for: - Logical errors, edge cases, and potential bugs. - API changes, altered return types, schema modifications, and configuration changes that may break consumers. - Catching these issues before human review reduces repeated review cycles and helps prevent deployment-time rollbacks. ## Shifting Security Left - Security scan analysis can use AI to: - Distinguish real vulnerabilities from false positives. - Explain risks and recommend remediation. - Prioritize findings by severity and exploitability. - AI-assisted code reviews can identify injection flaws, authorization problems, data exposure, insecure dependencies, and cryptographic weaknesses before an MR is created. - This reduces security-team backlogs and limits late-stage developer/security rework. ## Keeping Documentation Current - AI can generate release notes from merged MRs, organizing changes into features, fixes, performance improvements, breaking changes, and deprecations. - It can also identify which README files, API references, architecture diagrams, and onboarding guides need updates after code changes. - Automating these checks helps prevent documentation drift without creating a separate manual task. ## Breaking Down Complex Planning - An AI planning prompt can decompose an epic into implementable issues by considering: - Technical dependencies. - Appropriate issue sizes. - Acceptance criteria. - Implementation order. - The goal is to replace lengthy planning meetings with an initial AI-generated breakdown followed by team review. The practical recommendation is to treat AI as a team workflow accelerator, not merely a code generator. Applying focused prompts to review, security, documentation, and planning can help prevent increased coding speed from creating larger downstream bottlenecks.

Read original(opens in new tab)

Database DesignMachine LearningPostgreSQLCode Review+4

gitlab·Mar 4, 2026·4 min readCurated summary

How GitLab built a security control framework from scratch

GitLab created its own security control framework after finding that existing frameworks were too broad, rigid, or insufficiently granular for its multi-product, cloud-native environment. The GitLab Control Framework (GCF) combines industry best practices with product-specific implementations and extensive operational metadata. This lets GitLab manage multiple certifications and internal risks through one scalable framework rather than maintaining separate frameworks for each product. ## Why Existing Frameworks Were Insufficient - GitLab initially used the Secure Controls Framework, then adopted NIST SP 800-53 in preparation for FedRAMP. - NIST’s more than 1,000 controls were comprehensive but included requirements that did not apply to GitLab. - Broad controls often combined several distinct activities: - NIST AC-2, “Account Management,” covers account creation, modification, disabling, termination, shared accounts, and monitoring. - GitLab treated these as separate controls because they have different owners, risks, testing methods, and evidence requirements. - Repeatedly customizing NIST controls effectively meant GitLab was building its own framework, leading to the decision to formalize one. ## Establishing the GitLab Control Framework GitLab developed the GCF through five major steps: ### Assessing Requirements - The team mapped requirements from existing and planned certifications, including: - SOC 2 Type II - ISO 27001, ISO 27017, ISO 27018, and ISO 42001 - PCI DSS - TISAX - Cyber Essentials - FedRAMP - Internal requirements covered mission-critical systems outside certification scopes and systems handling sensitive data. - This analysis established the minimum controls GitLab needed to meet compliance and risk-management obligations. ### Learning from Industry Frameworks - GitLab compared its requirements with: - NIST SP 800-53 - NIST Cybersecurity Framework - Secure Controls Framework - Adobe and Cisco Common Controls Framework - The goal was to reuse proven structures and ensure important security domains and practices were not omitted. ### Creating Custom Domains - The team organized the framework into 18 custom control domains. - Each domain groups related controls according to how GitLab’s security program is managed. - The structure supports adding, changing, or retiring controls as the business evolves. ## Separating Framework Requirements from Implementations GitLab operates several products with different infrastructure and compliance scopes: - GitLab.com is a multi-tenant SaaS platform hosted on GCP. - GitLab Dedicated is single-tenant SaaS hosted on AWS. - GitLab Dedicated for Government is a FedRAMP offering hosted on AWS. To avoid duplicating the framework, the GCF uses two control levels: - **Level 1:** Defines what must be implemented at the organizational framework level. - **Level 2:** Describes how each product fulfills the requirement. - Entity-level controls apply across the organization and are inherited by all product offerings. - This model supports product-specific audits while preserving a single source of control requirements. ## Adding Operational Metadata Rather than tracking only a control ID, description, and owner, the GCF records detailed context for each control: - Responsible owner and risk accountability - Applicable environment or product - Covered assets and systems - Performance or testing frequency - Manual, semi-automated, or automated nature - External certification or internal-risk classification - Testing procedures and required evidence This turns the framework into an operational control inventory. Teams can filter it to identify controls for a particular audit, determine ownership, or find manual controls that may be candidates for automation. ## Designing for Growth - The GCF is intended to evolve with GitLab’s products, risks, and certification goals. - Its structured metadata helps GitLab assess scope and identify gaps when pursuing additional certifications such as ISMAP, IRAP, or C5. - The framework’s modular design makes it easier to extend compliance coverage without creating entirely new control systems. GitLab’s experience suggests that organizations should consider a custom framework when standard frameworks require extensive modification. The most effective approach is to retain useful industry guidance while tailoring control granularity, product implementations, ownership, testing, and metadata to the organization’s actual operating environment.

Read original(opens in new tab)

Database DesignGitlabCloud NativeSecurity Compliance+4

gitlab·Feb 27, 2026·2 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)

Machine LearningGitlabDevOpsApplication Security+3

gitlab·Feb 26, 2026·3 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)

GitlabDevSecOpsManaged ServicesAi Workflows+2

gitlab·Feb 26, 2026·2 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)

Machine LearningCI/CDGitlabDevSecOps+4

gitlab·Feb 26, 2026·2 min readCurated summary

GitLab Duo Agent Platform with Claude accelerates development

GitLab Duo Agent Platform integrates external AI models such as Anthropic’s Claude and OpenAI’s Codex directly into GitLab workflows. Instead of operating as isolated coding assistants, these agents use project context and organizational standards to handle multi-step development tasks. The result is faster delivery, more consistent quality, and less manual work across the software development lifecycle. ## From an Idea to a Working Application - An agent can use an issue’s title and detailed requirements as the foundation for a complete application. - It analyzes project context and related assets, then generates: - Backend Java classes - Frontend HTML, CSS, and JavaScript - Business logic and UI components - Build configuration - The agent creates a merge request containing the implementation for developers to test and refine through natural-language interaction. ## Automated Code Review - Developers can mention the external agent in a merge request to request a review. - The review can cover: - Code strengths and critical issues - Medium- and low-priority improvements - Security risks - Testing gaps and code metrics - Recommendations and an approval status - This provides consistent review coverage while allowing senior developers to focus on architecture and complex decisions. ## Pipeline and Container Image Creation - When a project lacks CI/CD configuration, the agent can generate the required pipeline. - It creates a Dockerfile with a suitable base image for the project’s Java version. - The pipeline can: - Build the application - Build a Docker image - Push the image to GitLab’s container registry - The resulting workflow runs automatically through build, image creation, and deployment stages. ## Broader Impact on Development - External agents remain within GitLab, reducing context switching between development tools. - They can follow project-specific coding standards and understand broader repository context. - Teams can automate work from initial requirements through implementation, review, and deployment. - Developers spend less time on repetitive tasks while maintaining stronger consistency and quality. GitLab presents Duo Agent Platform as a way to turn external AI models into integrated development collaborators. Teams can use it to accelerate coding, automate reviews, and create deployment pipelines while keeping humans focused on validation, architecture, and innovation.

Read original(opens in new tab)

Machine LearningCI/CDCode ReviewDocker & Containers+4

gitlab·Feb 25, 2026·2 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)

GitlabDevSecOpsSecurityMulti Factor Authentication+4

gitlab·Feb 25, 2026·2 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)

CI/CDGitlabDocker & ContainersDevOps+4

gitlab·Feb 24, 2026·3 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)

Machine LearningCI/CDGitlabDevSecOps+4

gitlab·Feb 24, 2026·2 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)

GitlabDevSecOpsGpgSecurity Policies+2

gitlab·Feb 20, 2026Original 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.

GitlabDevSecOpsGpgApt+3

gitlab·Feb 19, 2026Original 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.

GitlabDevSecOpsVulnerability ManagementData Visualization+3

gitlab·Feb 19, 2026Original 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.

Database DesignGitlabJavaScriptNpm+3

gitlab·Feb 19, 2026Original 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.

AI AgentsMachine LearningGitlabDevSecOps+3

gitlab·Feb 18, 2026Original 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.

GitlabDevSecOpsContainer RegistryService Level Agreement+2