gitlab·Apr 21, 2026·3 min readCurated summary

GitLab + Amazon: Platform orchestration on a trusted AI foundation

GitLab Duo Agent Platform and Amazon Bedrock combine GitLab’s software-lifecycle orchestration with AWS’s governed foundation-model infrastructure. Duo coordinates agents across planning, development, security, pipelines, and remediation, while Bedrock provides secure inference within AWS boundaries. The pairing aims to reduce shadow AI, fragmented tooling, unclear data flows, and unplanned cloud spending. ## The Enterprise AI Governance Problem - Teams often adopt unapproved AI tools, creating unknown prompt and code-data paths. - AI tooling and model choices become fragmented across developers and departments. - Security teams may lack control over logs, data residency, and access policies. - Existing AWS and Amazon Bedrock investments can be underused when teams rely on external point solutions. - The proposed division of responsibility is: - GitLab Duo Agent Platform: workflow and agent orchestration. - Amazon Bedrock: approved models and inference. - The organization: IAM, VPC, regional, security, and policy controls. ## GitLab Duo Agent Platform as the Control Plane - Duo provides specialized agents and flows that operate asynchronously across the software lifecycle. - Agents use shared GitLab context, including: - Issues - Merge requests - Pipelines - Security findings - It extends beyond a single conversational assistant by coordinating multiple agents across continuous workflows. - Potential tasks include planning, code development, merge-pipeline work, security scanning, and vulnerability remediation. ## Amazon Bedrock as the AI Foundation - Bedrock is a managed, serverless foundation-model layer operating within AWS. - Customer inputs and outputs are encrypted, not shared with model providers, and not used to train base models. - It supports compliance requirements including GDPR, HIPAA, and FedRAMP High. - Organizations can use native Bedrock models or import fine-tuned models through Custom Model Import. - Bedrock Guardrails can provide content filtering, hallucination detection, and sensitive-data protection. ## Deployment Options The core Duo capabilities remain consistent, but control and infrastructure ownership vary across three patterns: - **Self-hosted models with Amazon Bedrock** - Intended for GitLab Self-Managed deployments. - Uses a self-hosted AI Gateway. - Keeps inference traffic, prompts, logs, and lifecycle data within the organization’s AWS environment. - **GitLab-operated Bedrock models with GitLab-owned keys** - Intended for GitLab Self-Managed deployments. - Uses GitLab’s hosted AI Gateway. - GitLab operates the model layer while the deployment remains self-managed. - **GitLab.com with GitLab-operated Bedrock models** - Uses GitLab’s hosted AI Gateway and GitLab-owned keys. - Suits organizations that prefer the SaaS GitLab experience while using Bedrock-backed models. ## Practical Enterprise Uses - Platform teams can standardize models for code suggestions, security analysis, and pipeline remediation. - Centralized guardrails and logging reduce independent, unmanaged AI adoption. - Security agents can propose and validate fixes directly within GitLab. - Routing AI workloads through Bedrock helps organizations align usage with existing AWS agreements and spending commitments. The recommended approach is to treat GitLab Duo Agent Platform as the orchestration layer and Amazon Bedrock as the governed inference foundation, selecting the deployment model that matches the organization’s compliance, hosting, and control requirements.

Read original(opens in new tab)

Machine LearningGitlabDevSecOpsAmazon Bedrock+4

gitlab·Apr 20, 2026·3 min readCurated summary

Prepare your pipeline for AI-discovered zero-days

AI is accelerating both vulnerability discovery and insecure code production, shrinking the time defenders have to respond from months to hours. The post argues that security teams cannot remain the final defense layer; security controls, automated triage, and remediation must operate directly within development pipelines. AI-generated fixes can help close the gap, but they must follow the same policies, approvals, testing, and audit requirements as human-authored code. ## The Remediation Backlog Is Already Too Large - Most exploited vulnerabilities are already known and have patches available, but organizations cannot remediate them quickly enough. - Sixty percent of breaches in the 2025 Verizon DBIR involved known vulnerabilities. - Developers spend roughly 11 hours per month fixing vulnerabilities after release. - The median time to close half of internet-facing vulnerabilities is 361 days, while exploitation can begin within hours. - AI-assisted development is increasing the volume of insecure code: - Fortune 50 repositories reportedly gained more than 10,000 security findings per month by mid-2025. - AI coding tools may introduce outdated patterns, hallucinated packages, insecure examples, and excessive dependencies. - Security AI should therefore operate within existing development policies and audit trails rather than as a disconnected tool. ## Security Enforcement Must Move Into the Pipeline - Every change should pass security controls at the merge request, which becomes the central enforcement point. - Policies should be defined once and applied consistently across teams and projects. - Exceptions should be explicitly approved and logged. - IDE checks can catch straightforward problems—such as hardcoded secrets, vulnerable imports, and deprecated APIs—before code reaches review. - This allows human reviewers to focus on complex issues such as reachability, exploitability, and architectural risk. ## Automated Triage and Governed Remediation - AI should reduce the volume of findings developers must investigate by assessing: - False positives - Reachability - Exploitability - Severity - AI-generated fixes should not bypass normal governance. - Remediation proposals should be submitted as merge requests, with: - Required scans - Policy enforcement - Human approvals - Confidence scores - Complete audit records - Human and AI-authored changes should follow the same review and compliance process. ## Example: Responding to an Emerging Vulnerability - A proof-of-concept exploit may appear before a CVE, NVD entry, or scanner signature exists. - A security agent can inspect dependency graphs across projects, identify affected versions and call paths, and rank production exposure. - Teams can then launch a coordinated remediation campaign: - Upgrade dependencies where patches exist. - Apply targeted code changes where they do not. - Block merge requests that retain the vulnerable dependency. - Require security approval for fixes. - Pipeline tests can reject faulty AI-generated patches, allowing the agent to revise them before developers approve the corrected version. - Automatically collected scan results, policies, approvals, and merge timestamps provide audit evidence without manual reconstruction. ## Strengthen the Pipeline Before Attackers Catch Up - Organizations should verify that security scans run on every merge request, not only in selected projects. - Pipelines should detect compromised or vulnerable dependencies before build time. - Critical findings should move quickly from detection to the responsible developer without unnecessary tool boundaries. - The central recommendation is to make pipeline enforcement, AI-assisted triage, and governed remediation standard parts of the software supply chain before comparable offensive AI capabilities become widely available.

Read original(opens in new tab)

Database DesignMachine LearningDevSecOpsVulnerability Management+4

gitlab·Apr 20, 2026·3 min readCurated summary

GitHub Copilot's policy for AI training: A governance wake-up call

GitHub’s April 2026 policy change will make Copilot Free, Pro, and Pro+ interaction data—including code, prompts, outputs, and context—available for AI training by default unless users opt out. The change highlights governance risks for regulated organizations, especially when protections vary by subscription tier or can be altered through policy updates. The post presents GitLab’s no-training commitment, contractual safeguards, and transparency documentation as a stronger model for enterprise AI governance. ## What the GitHub Policy Change Means - Beginning April 24, 2026, GitHub may use Copilot Free, Pro, and Pro+ data for model training by default. - Covered data includes: - User inputs and outputs - Code snippets - Associated context - Interaction data - Users must actively opt out. - Copilot Business and Enterprise customers remain exempt under existing contracts. - Data may also be shared with GitHub affiliates, including Microsoft, for AI development. - Organizations must review license tiers, settings, contracts, and internal AI governance controls. ## Why This Matters in Regulated Industries - Source code can expose: - Proprietary business logic - Internal system architecture - Sensitive data flows - Financial algorithms and risk models - Financial institutions may face intellectual-property and model-risk concerns involving trading strategies, underwriting rules, fraud detection, and credit models. - Frameworks such as Federal Reserve SR 11-7 and DORA require documented oversight of third-party technology and material changes in vendor practices. - Public-sector environments governed by NIST 800-53 and FISMA may require sensitive code to remain within controlled boundaries. - Healthcare organizations must consider HIPAA obligations when development tools interact with clinical or patient-adjacent systems. - Default opt-in training, individual opt-out requirements, and tier-dependent protections create compliance risks. ## Requirements for Enterprise AI Vendors - **Contractual certainty:** Vendors should clearly and unconditionally define how customer data is handled. - **Auditability:** Organizations need documentation about models, training data, subprocessors, retention, and compliance status. - **Independence from vendor incentives:** Customer code should not become training data for systems that may benefit competitors. - **Operational flexibility:** Regulated customers may require self-hosting, controlled processing boundaries, or clear procedures for vendor changes. ## GitLab’s AI Governance Position - GitLab states that it does not train AI models on customer code at any pricing tier. - Its AI vendors are contractually prohibited from using GitLab customer inputs or outputs for their own purposes. - The GitLab AI Transparency Center documents: - Models powering its features - Data handling practices - Subprocessors - Retention periods - Feature compliance status - GitLab emphasizes cloud and model neutrality, supports self-hosted deployments, and addresses vendor changes through its AI Continuity Plan. - The post argues that these policies reduce vendor-concentration, compliance, and intellectual-property risks. ## Closing the Governance Gap Organizations should ask every AI vendor: - Is customer data used for model training? - Who are the model subprocessors? - What happens if data practices change? - Can AI processing remain inside the organization’s infrastructure? - What indemnification applies to AI-generated output? The post’s recommendation is to favor vendors that provide durable, contractual, and auditable answers rather than relying on defaults, temporary opt-outs, or policies that can change with short notice.

Read original(opens in new tab)

Machine LearningGitlabGithub CopilotData Privacy+3

gitlab·Apr 20, 2026·2 min readCurated summary

What’s new in Git 2.54.0?

Git 2.54.0 introduces foundational changes to Git’s storage and history-editing capabilities. Its object database is now pluggable, making alternative storage formats more feasible, while the new `git history` command simplifies common commit-history edits that previously required interactive rebases. These changes are early milestones in longer-term efforts to improve repository performance and support stacked-diff workflows. ## Pluggable Object Databases - Git already supports interchangeable reference backends, including `files` and `reftable`. - Git 2.54 extends this abstraction to object databases, which store loose objects and packfiles under `.git/objects`. - The work began in Git 2.48 and involved nearly 400 upstream commits over almost two years. - Alternative object-storage implementations can now support meaningful local workflows, including: - Creating commits - Displaying commit graphs - Performing merges - Remote operations such as fetching and pushing are not yet supported through alternate backends. - Future storage formats could: - Handle large binary files more efficiently than packfiles - Be optimized for GitLab’s repository-serving infrastructure - The project was led by Patrick Steinhardt. ## Easier Commit-History Editing - Developers often rewrite history to produce small, atomic commits with clear messages, but interactive rebases can be difficult to learn. - Interactive rebases require users to choose a base commit, edit an instruction sheet, and understand Git’s stateful rebase process. - Git 2.54 introduces `git history`, inspired partly by Jujutsu’s simpler history-editing commands. - Initial subcommands include: - `git history reword`: change a commit message - `git history split`: divide one commit into two by selecting which changes belong in each - Planned commands include: - `git history fixup` - `git history drop` - `git history reorder` - `git history squash` - The command can automatically rebase local branches that contain the edited commit, including branches other than the current one. - This behavior supports Git’s broader effort to improve stacked-diff workflows, where dependent branches are reviewed independently. - The project was led by Patrick Steinhardt with support from Elijah Newren. The release points toward a more extensible Git: repository storage can eventually be optimized for different workloads, while history editing becomes more approachable than traditional interactive rebases. Since both features are still developing, users should expect broader backend support and additional history commands in future releases.

Read original(opens in new tab)

Open SourceGitGit HistoryPluggable Object Databases+3

gitlab·Apr 16, 2026·2 min readCurated summary

CI Expert and Data Analyst AI agents target development gaps

GitLab 18.11 introduces two Duo Agent Platform agents aimed at development gaps left by faster AI-generated coding. CI Expert Agent helps teams create working pipelines, while Data Analyst Agent answers software delivery questions using GitLab data. Both benefit from being embedded in GitLab, where they can use current repository, pipeline, issue, and merge request context. ## CI Expert Agent: Faster Pipeline Setup - Now available in beta. - Inspects a repository to identify its language, framework, and testing setup. - Generates runnable build and test configurations without requiring developers to write YAML manually. - Explains each pipeline step in plain language through Agentic Chat. - Uses native GitLab CI semantics. - Addresses the common problem of delaying CI because `.gitlab-ci.yml` is difficult to create or validate. - Helps reduce regressions, oversized changes, and dependence on undocumented team knowledge. - Available on GitLab.com, Self-Managed, and Dedicated across Free, Premium, and Ultimate editions with Duo Agent Platform enabled. ## Data Analyst Agent: Natural-Language SDLC Queries - Generally available in GitLab 18.11. - Lets users ask questions about development performance in plain language and receive visualizations in Agentic Chat. - Covers merge requests, issues, projects, pipelines, and jobs. - Supports questions about: - MR cycle time and review bottlenecks - Project throughput and contribution patterns - Flaky tests and pipeline performance - Runner utilization and deployment frequency - Cross-portfolio lead times and project health - Eliminates the need to learn GitLab Query Language, request custom dashboards, or rely on separate analytics tools. - Generated GLQL queries can be copied into GitLab Flavored Markdown. - Exporting results to work items and dashboards is planned. - Available across GitLab.com, Self-Managed, and Dedicated Free, Premium, and Ultimate editions with Duo Agent Platform enabled. ## The Advantage of Platform-Native Context - Both agents operate within GitLab and can access existing code, pipelines, issues, and merge requests. - Their recommendations and answers are based on current operational data rather than generic examples or disconnected tools. - The agents are designed to support the full lifecycle: understanding code, configuring CI, shipping changes, and evaluating delivery performance. Together, these agents make GitLab Duo more useful beyond code generation. Teams should consider trying CI Expert Agent for faster initial pipeline setup and Data Analyst Agent for immediate, self-service insight into delivery performance.

Read original(opens in new tab)

Machine LearningGitlabDevOpsYaml+4

gitlab·Apr 16, 2026·2 min readCurated summary

Automate remediation with ready-to-merge AI code fixes

GitLab 18.11 makes Agentic SAST Vulnerability Resolution generally available, using AI to analyze vulnerabilities, generate code fixes, test them, and open ready-to-merge merge requests. The release aims to reduce developer context switching and AppSec triage while addressing vulnerabilities before production. It also adds faster scanning, risk-based prioritization, and stronger security governance. ## Automated Remediation in the Developer Workflow - Confirmed SAST true positives automatically enter GitLab Duo Agent Platform’s remediation flow. - The agent: - Analyzes the vulnerability in context. - Generates a root-cause fix. - Validates the change with automated tests. - Developers receive a ready-to-merge MR with a confidence score. - Incremental scanning for Advanced SAST provides results before a complete scan finishes. - The approach addresses the growing remediation burden as AI-generated code increases vulnerability volume. ## Prioritizing Vulnerabilities by Business Risk - Vulnerability scoring now uses CVSS 4.0 for more detailed exploitability assessment. - Policy-based severity overrides can use: - CVE information. - CWE classifications. - File paths and directories. - Approval policies can block or warn on merges based on: - Known Exploited Vulnerabilities (KEV). - EPSS score thresholds. - The Top CWEs dashboard chart helps teams identify recurring vulnerability classes and address systemic causes. ## Security Controls and Scanner Coverage - The new Security Manager role gives security teams permissions to: - Enforce scanners. - Configure security policies. - Manage triage and remediation. - Maintain compliance frameworks and audit streams. - The role excludes code modification and deployment permissions, keeping access appropriately scoped. - SAST configuration profiles allow teams to define scanning centrally and apply it across group projects without maintaining project-level YAML or relying on developers for configuration. GitLab 18.11 combines agentic remediation, faster and more risk-aware scanning, and centralized governance. Organizations seeking to reduce vulnerability backlogs can use these capabilities to automate routine fixes while preserving developer oversight through merge requests and confidence scores.

Read original(opens in new tab)

Machine LearningDevSecOpsSastSecurity+3

gitlab·Apr 16, 2026·2 min readCurated summary

Claude Opus 4.7 is now available in GitLab Duo Agent Platform

GitLab Duo Agent Platform now supports Anthropic’s Claude Opus 4.7 across Agentic Chat and agent-powered software delivery workflows. The model is designed to improve long-running, multistep tasks through stronger reasoning, instruction following, and self-verification. GitLab says this should make agents more reliable across development, security, CI/CD, and deployment. ## Improved Reasoning and Instruction Following - Internal evaluations reportedly show Opus 4.7 outperforming Sonnet 4.6 and Opus 4.6. - It handles complex, conditional instructions more precisely. - Agents can complete multistep tasks with fewer errors and more predictable, auditable results. - Self-verification helps agents check generated code and tests before presenting them. ## Support Across the Software Lifecycle - **Development:** Faster code generation and test creation with less developer back-and-forth. - **Security:** More reliable vulnerability remediation through complete, correctly scoped sequences. - **CI/CD:** Better continuity when investigating pipeline failures, analyzing logs, and proposing fixes. - **Cross-stage workflows:** The model supports coordination across planning, coding, security, and deployment. ## Availability and Pricing - Claude Opus 4.7 is available now through model selection in GitLab Duo Agent Platform. - Model credit consumption details are provided in GitLab’s documentation. - New users can start a free trial. - GitLab Premium and Ultimate subscribers can enable Duo Agent Platform and use included GitLab Credits. Teams using GitLab’s agent workflows can adopt Opus 4.7 to improve reliability on complex, multi-tool tasks spanning the full software delivery lifecycle.

Read original(opens in new tab)

Machine LearningCI/CDGitlabCode Review+3

gitlab·Apr 16, 2026·3 min readCurated summary

GitLab 18.11: Budget guardrails for GitLab Credits

GitLab 18.11 introduces spending controls for GitLab Credits used by the Duo Agent Platform. Organizations can set subscription-wide monthly caps, limit individual users, and monitor enforcement, making AI costs more predictable as adoption grows. The goal is to combine usage-based pricing with the budget certainty traditionally associated with seat-based licensing. ## Subscription-Level Spending Caps - Billing account managers can set a hard monthly ceiling in the Customers Portal. - When usage reaches the cap, Duo Agent Platform access pauses for all users until the next billing period. - Managers can raise or disable the cap mid-month to restore access. - Caps reset monthly and remain in effect until changed. - Because usage data is synchronized periodically, limited usage may occur after the cap is technically reached. ## Per-User Credit Limits - A flat per-user limit can be applied uniformly through the GitLab GraphQL API. - Custom overrides allow organizations to give higher allocations to selected users, such as staff engineers. - Limits apply to a user’s total consumption across all credit sources. - Reaching an individual limit pauses only that user’s Duo Agent Platform usage; their GitLab access remains intact. - Other users continue working until they reach their own limits or the subscription cap. ## Visibility and Notifications - Billing account managers receive email notifications when the subscription cap is reached. - Group owners on GitLab.com and instance administrators on Self-Managed installations can see users blocked by per-user caps. - Administrators can restore access by changing limits through the GraphQL API. - Per-user usage data supports monitoring, chargeback, and future budget planning. ## Benefits for Scaling AI Adoption - Hard caps make AI spending easier to forecast, approve, and include in quarterly budgets. - Per-user limits help distribute credits fairly across teams and cost centers. - Organizations can expand from small pilots to hundreds or thousands of developers without risking uncontrolled invoices. - Usage data helps platform teams understand consumption patterns and adjust allocations. ## Usage-Based Pricing with Guardrails GitLab contrasts its approach with seat-based AI tools, where organizations pay a fixed amount per user regardless of usage. GitLab Credits instead charge based on actual consumption while adding enforced spending limits, combining flexibility with predictable budgeting. ## Example Deployments - A 200-person engineering organization can set a subscription cap matching its approved monthly budget. - If usage approaches the limit, finance or billing managers can either increase the cap or wait for the next period. - A 2,000-person enterprise can apply standard limits to most developers while allocating higher caps to engineers handling complex work. ## Availability and Setup - The controls are available for GitLab.com and Self-Managed customers running GitLab 18.11. - Subscription-level caps are configured by billing account managers in the Customers Portal. - Flat and custom per-user caps are configured through the GitLab GraphQL API by namespace owners or instance administrators. Organizations adopting GitLab Duo Agent Platform should establish a subscription cap, define fair per-user allocations, and monitor usage regularly. These controls provide a safer foundation for expanding AI usage without sacrificing financial oversight.

Read original(opens in new tab)

Machine LearningGitlabSoftware DevelopmentSaas+4

gitlab·Apr 16, 2026·1 min readCurated summary

GitLab 18.11 release notes | GitLab Docs

Agentic SAST Vulnerability Resolution is now generally available in GitLab 18.11 through the GitLab Duo Agent Platform. It autonomously analyzes critical and high-severity SAST findings, proposes code fixes, and creates ready-to-review merge requests. The feature is designed to accelerate remediation while giving reviewers confidence assessments and the option to apply fixes directly from vulnerability details. ## Availability and Integration - Available with GitLab Ultimate. - Supported on GitLab.com, GitLab Self-Managed, and GitLab Dedicated. - Runs: - As part of a SAST scan - After SAST false-positive detection - Manually for individual SAST vulnerabilities ## Automated Vulnerability Analysis - Examines each finding and reasons through the surrounding code context. - Generates proposed fixes for critical and high-severity SAST vulnerabilities. - Automatically opens a merge request containing the remediation for review. ## Review and Remediation Workflow - Provides quality assessments to help reviewers evaluate the likely reliability of each proposed fix. - Lets users apply resolutions directly from vulnerability details pages. - Feedback is welcomed through GitLab issue 585626. ## Practical Recommendation Teams using GitLab Ultimate can enable the feature to streamline SAST remediation, while still reviewing agent-generated merge requests before merging changes.

Read original(opens in new tab)

GitlabCode QualityDevOpsSast+3

gitlab·Apr 15, 2026·3 min readCurated summary

A guide to the breaking changes in GitLab 19.0

GitLab 19.0 is expected to introduce 15 breaking changes, primarily by removing deprecated components and outdated platform support. The most significant effects involve Helm chart networking and bundled services, OAuth authentication, PostgreSQL, Redis, and supported operating systems. Administrators should audit their deployments and complete migrations before upgrading. ## Release and Deployment Windows - **GitLab.com:** Primary breaking-change window is May 4–6, 2026, with a fallback window on May 11–13. - **GitLab Self-Managed:** GitLab 19.0 becomes available May 21, 2026. - **GitLab Dedicated:** Upgrades occur during assigned maintenance windows, with GitLab 19.0 scheduled for the week of June 22, 2026. - Additional changes may roll out outside these windows in exceptional circumstances. ## High-Impact Changes ### NGINX Ingress Replaced by Gateway API - The GitLab Helm chart will use **Gateway API with Envoy Gateway** as its default networking configuration. - Bundled NGINX Ingress reached end-of-life in March 2026. - Existing deployments can explicitly continue using bundled NGINX Ingress until its planned removal in GitLab 20.0. - The change does not affect: - NGINX used by the Linux package. - Deployments using externally managed Ingress or Gateway API controllers. - Administrators should plan migration to Envoy Gateway or another externally managed controller. ### Bundled PostgreSQL, Redis, and MinIO Removed - The GitLab Helm chart and GitLab Operator will no longer bundle Bitnami PostgreSQL, Bitnami Redis, or the forked MinIO chart. - These components were intended for proof-of-concept and test environments, not production. - Deployments using them must migrate to external services before upgrading. - PostgreSQL and Redis bundled with the Linux package are unaffected. ### OAuth ROPC Grant Removed - The Resource Owner Password Credentials OAuth flow will be removed across GitLab.com, Self-Managed, and Dedicated. - ROPC is being eliminated because of security limitations and its removal from OAuth 2.1. - Applications using ROPC must migrate to a supported flow, such as Authorization Code. - After upgrading, ROPC will not work even when client credentials are provided. ### PostgreSQL 17 Becomes Required - PostgreSQL 16 will no longer be supported; PostgreSQL 17 becomes the minimum version. - Single PostgreSQL instances installed through the Linux package may be upgraded automatically during GitLab 18.11. - Cluster deployments and installations that opt out of automatic upgrades require a manual migration. - Administrators should verify sufficient disk space and complete the upgrade before GitLab 19.0. ## Medium-Impact Changes ### Ubuntu 20.04 Packages Discontinued - GitLab will stop publishing Linux packages for Ubuntu 20.04. - GitLab 18.11 is the final release supporting that distribution. - Affected installations must upgrade to Ubuntu 22.04 or another supported operating system first. ### Redis 6 Support Removed - External Redis 6 deployments must migrate to Redis 7.2 or Valkey 7.2. - The Linux package’s bundled Redis is unaffected because it has used Redis 7 since GitLab 16.2. - Migration options vary by provider: - AWS ElastiCache and GCP Memorystore: Redis 7.2 or Valkey 7.2. - Azure: self-host Redis or Valkey on VMs or AKS until managed support is available. - Self-hosted installations: upgrade directly to Redis 7.2 or Valkey 7.2. ### Auto DevOps Builder Image Updated - The CNB builder image used by Auto DevOps changes from `heroku/builder:22` to `heroku/builder:24`. - Pipelines relying on the older image may need testing or configuration updates. GitLab administrators should review the deprecations and upgrade documentation, identify whether their deployment uses any affected components, and complete required migrations before GitLab 19.0.

Read original(opens in new tab)

Database DesignGitlabPostgreSQLDevOps+4

gitlab·Apr 14, 2026·2 min readCurated summary

GitLab and Vertex AI on Google Cloud: Advancing agentic development

GitLab is partnering with Google Cloud to combine the GitLab Duo Agent Platform’s lifecycle-wide orchestration with Vertex AI’s managed foundation models and enterprise controls. The integration gives development teams context-aware agents for planning, coding, security, and delivery while keeping workflows within GitLab’s governed system of record. Customers gain model flexibility, stronger governance, and reduced complexity compared with managing disconnected AI tools. ## Agents Across the Software Development Lifecycle - GitLab Duo Agent Platform coordinates specialized agents across planning, development, code review, security, and delivery. - Unlike standalone coding assistants, GitLab agents can access issues, merge requests, pipelines, vulnerabilities, and codebases. - GitLab Duo Planner Agent can analyze backlogs, divide epics into tasks, and support prioritization. - Security Analyst Agent can triage vulnerabilities, explain risks, and recommend remediation priorities. - Built-in flows connect agents into end-to-end processes, reducing manual handoffs. - Agentic Chat provides natural-language access to project context and multi-step reasoning within GitLab. ## Vertex AI as the Model and Infrastructure Layer - Vertex AI supplies the foundation models and related services used by GitLab agents. - Newer models improve reasoning, tool use, and long-context understanding, supporting workloads such as backlog analysis and monorepo security reviews. - Vertex AI Model Garden offers Gemini, third-party, and open-source models, allowing customers to balance performance, cost, and regulatory requirements. - GitLab supports Bring Your Own Model configurations, enabling organizations to use approved providers and gateways. - Vertex AI abstracts LLM hosting, including infrastructure management, security, governance, and model-version delivery. ## Enterprise Governance and Operational Benefits - GitLab’s AI Gateway mediates model access, helping administrators track connections and maintain governance. - Developers remain in GitLab while inference follows existing Google Cloud security and policy controls. - Platform teams can standardize which models support recommendations, analysis, and remediation. - Security teams can manage findings and proposed fixes in the same environment, reducing context switching and unmanaged workflows. - Using Vertex AI through GitLab can align AI usage with existing Google Cloud contracts, controls, and procurement policies. - The approach helps reduce duplicate spending and fragmented “shadow AI” toolchains. ## Practical Outcome for Google Cloud Customers The integration is intended to increase developer productivity without requiring teams to evaluate, host, or manage individual language models. GitLab provides the governed DevSecOps control plane, while Vertex AI supplies scalable, flexible model infrastructure, enabling organizations to adopt more capable agentic workflows while maintaining enterprise security and control.

Read original(opens in new tab)

Database DesignGitlabDevSecOpsSoftware Development Lifecycle+4

gitlab·Apr 13, 2026·3 min readCurated summary

GitLab named a 2026 Omdia Universe Leader

GitLab was named a Leader in Omdia’s 2026 Universe for AI-assisted Software Development, IDE-based Tools, ranking among 19 vendors. Its strongest results came from covering the entire software lifecycle—not just code generation—including planning, security, testing, deployment, and operations. The report suggests that AI delivers the greatest productivity gains when automation extends beyond coding into coordinated, governed delivery. ## Omdia’s Broader Evaluation - Omdia expanded its criteria to assess full software lifecycle capabilities. - The report emphasized that faster coding alone can create downstream bottlenecks in: - Code review - Security remediation - Testing - Deployment coordination - Agentic AI was evaluated as a current capability, including: - Autonomous task coordination - Handoffs between specialized agents - Support for teams at different stages of AI adoption - Omdia categorizes vendors as Leaders, Challengers, or Prospects based on capability and strategy/execution. ## GitLab’s Top Scores - **Solution Breadth: 100%** - Covers planning, requirements, development, security, deployment, and issue management in one platform. - Planner Agent and Security Analyst Agent extend AI into sprint planning, vulnerability triage, and remediation guidance. - **Strategy and Innovation: 88%** - Uses end-to-end orchestration and a privacy-first architecture that does not train on private customer data. - Supports multiple models through partnerships with Anthropic, Google, and AWS. - Provides shared context across issues, merge requests, pipelines, and security findings. - **Core Features: 82%** - Offers context-aware code generation, unit and integration testing, security testing, and review prioritization. - Automates CI/CD, GitOps, and pipeline-failure root cause analysis. - The AI Impact Dashboard tracks cycle time, deployment frequency, and productivity effects. - GitLab also received top-tier scores for Extended Features (80%) and Vendor Execution (88%). ## Developers and AI Agents - Teams are increasingly structured around engineers supervising AI agents. - Human responsibilities are shifting toward: - Defining requirements and guardrails - Supervising quality and security - Designing autonomous production pipelines - Connecting business objectives with agentic systems - Automating only code generation provides limited benefit if review, testing, and deployment remain manual. ## Enterprise Readiness - Omdia treated compliance, privacy, and deployment flexibility as baseline requirements for Leader-tier platforms. - GitLab highlights: - SOC 2 and ISO 27001 certification - No training on private customer data for agentic AI - Self-managed, cloud, on-premises, and air-gapped deployment - Support for self-hosted AI models - GitLab Dedicated, including FedRAMP Moderate authorization for government - These capabilities target regulated industries requiring strong data residency, auditability, and governance. GitLab’s central argument is that AI coding speed matters only when the rest of the software delivery lifecycle can keep pace. Engineering teams should evaluate AI platforms by their ability to deliver secure, governed, production-ready software—not merely by how much code they can generate.

Read original(opens in new tab)

Database DesignAI AgentsCI/CDGitlab+4

gitlab·Apr 9, 2026·2 min readCurated summary

5 ways GitLab pipeline logic solves engineering problems

GitLab’s pipeline model addresses complex CI/CD needs by combining composable features rather than relying on a single linear workflow. Parent-child pipelines, DAG execution, and multi-project triggers help teams scale monorepos and coordinate services across repositories while preserving clear ownership and failure visibility. The article argues that these patterns make pipelines both faster and easier to maintain. ## Monorepos: Parent-child pipelines and DAG execution - A monorepo containing frontend, backend, and documentation projects should not rebuild everything for every change. - Parent pipelines can trigger child pipelines for individual services using `trigger: include`. - Multiple included files are merged into one child pipeline, allowing jobs across files to share context and reference one another with `needs:`. - `strategy: depend` makes the parent wait for child pipelines and report one overall success or failure while retaining detailed drill-down. - Each service can own its pipeline configuration, reducing the risk that changes in one service break another. - DAG execution with `needs:` allows dependent jobs to start as soon as their prerequisites finish instead of waiting for an entire stage. - For example, API tests can begin immediately after the API build completes, without waiting for unrelated jobs. ## Microservices: Cross-repository pipelines - When frontend and backend services live in separate repositories, independent pipelines may miss integration failures. - GitLab multi-project pipelines allow one repository to trigger and await a pipeline in another project. - The frontend can generate an API contract artifact, publish it, and trigger the backend pipeline with `strategy: depend`. - The backend downloads the artifact through the GitLab Jobs API using `CI_JOB_TOKEN`. - An integration test can reject breaking API changes and propagate the failure back to the frontend pipeline. - The backend job uses `CI_PIPELINE_SOURCE == "pipeline"` so the contract validation runs only when initiated by the frontend, not during ordinary backend pushes. - The frontend project identifier is supplied through a CI/CD variable such as `FRONTEND_PROJECT_ID`. These patterns let teams reduce unnecessary work, preserve service-level ownership, and make cross-service compatibility checks part of the delivery process.

Read original(opens in new tab)

CI/CDMicroservicesDevOpsMonorepo+4

gitlab·Apr 8, 2026·2 min readCurated summary

GitLab Patch Release: 18.10.3, 18.9.5, 18.8.9 | GitLab Docs

GitLab released patch versions 18.10.3, 18.9.5, and 18.8.9 on April 8, 2026, addressing important security and bug fixes. Self-managed CE and EE installations should upgrade immediately, while GitLab.com is already patched and GitLab Dedicated customers need no action. The fixes cover unauthorized access, denial-of-service vulnerabilities, code injection, XSS, and information disclosure. ## Release Scope and Upgrade Guidance - The patches apply to GitLab Community Edition and Enterprise Edition. - Administrators should upgrade installations affected by the listed vulnerabilities to the latest supported patch release. - GitLab issues describing security vulnerabilities will become public 30 days after the release in which they were fixed. - Patch releases are generally issued on the second and fourth Wednesdays, with urgent ad-hoc releases for critical vulnerabilities. ## Authentication and Authorization Fixes - **CVE-2026-5173 (CVSS 8.5):** Authenticated users could invoke unintended server-side methods through WebSocket connections. - **CVE-2026-2619 (CVSS 4.3):** Auditor users could modify vulnerability flag data in private projects through the AI detection API. - **CVE-2026-1752 (CVSS 4.3):** Developers could modify protected environment settings through authorization flaws in the Environments API. - **CVE-2026-2104:** CSV exports could expose confidential issues assigned to other users because of insufficient authorization checks. ## Denial-of-Service Vulnerabilities - **CVE-2026-1092 (CVSS 7.5):** Unauthenticated attackers could crash or disrupt services through malformed JSON sent to the Terraform state lock API. - **CVE-2025-12664 (CVSS 7.5):** Repeated unauthenticated GraphQL queries could cause denial of service. - **CVE-2026-1403 (CVSS 6.5):** Authenticated users could disrupt Sidekiq workers by importing malformed CSV files. - **CVE-2026-1101 (CVSS 6.5):** Authenticated users could overload GitLab through improperly validated GraphQL SBOM queries. ## Code Execution and Cross-Site Scripting - **CVE-2026-1516 (CVSS 5.7):** Crafted Code Quality report content could leak the IP addresses of users viewing the report. - **CVE-2026-4332 (CVSS 5.4):** Authenticated users could execute arbitrary JavaScript in other users’ browsers through customizable analytics dashboards. ## Information Disclosure - **CVE-2025-9484 (CVSS 4.3):** Certain GraphQL queries could reveal other users’ email addresses to authenticated users. - The release also fixes CSV export authorization issues that could expose confidential issue data. Administrators of self-managed GitLab CE or EE instances should apply 18.10.3, 18.9.5, or 18.8.9 as soon as possible, depending on their supported release branch.

Read original(opens in new tab)

GitlabAPIGraphQLCve+4

gitlab·Apr 7, 2026·3 min readCurated summary

Pipeline security lessons from March supply chain incidents

Between March 19 and 31, 2026, attacks on Trivy, KICS, LiteLLM, and axios demonstrated that CI/CD pipelines are valuable supply-chain targets. The incidents exploited trusted tools, stolen credentials, packaging mistakes, and malicious dependencies to steal secrets or leak proprietary code. The article argues that centralized, mandatory pipeline policies can detect and block these patterns before they reach production. ## Recent Supply-Chain Incidents - **Trivy:** Attackers compromised GitHub Action tags and distributed a trojanized binary that harvested environment variables, cloud tokens, SSH keys, and CI/CD secrets. - **Checkmarx KICS:** Malicious versions of KICS GitHub Actions exfiltrated API keys, database passwords, cloud credentials, and service-account secrets. - **LiteLLM:** Backdoored PyPI releases executed payloads during installation or Python startup, stealing sensitive files and credentials. - **AI coding assistant package:** A 59.8 MB source map unintentionally exposed more than 1,900 TypeScript files, internal feature flags, model codenames, and a system prompt. - **axios:** Compromised maintainer credentials enabled malicious releases containing a cross-platform Remote Access Trojan through a poisoned dependency. ## Three Attack Patterns ### Poisoned Tools and Actions - Pipelines often implicitly trust security scanners, GitHub Actions, package versions, and container images. - Mutable tags can be changed after approval, causing future pipeline runs to execute malicious code. - Recommended controls: - Pin actions and tools to commit SHAs or image digests. - Verify checksums or signatures. - Block execution when integrity checks fail. ### Packaging Errors That Expose Intellectual Property - Incorrect `.npmignore` files or `files` settings can include source maps, internal configuration, and other debugging artifacts in published packages. - Pre-publish validation should compare package contents against an allowlist. - Builds should flag unexpected source maps, `.env` files, and internal files, then block publication when violations occur. ### Malicious Transitive Dependencies - A compromised dependency can affect users who never directly selected it. - Unexpected lockfile changes or newly introduced packages can spread attacks across an organization. - Recommended controls: - Compare dependency checksums with known-good lockfile state. - Detect unexpected dependency or version changes. - Reject unverified packages during builds. ## GitLab Pipeline Execution Policies - GitLab Pipeline Execution Policies inject mandatory CI/CD jobs into pipelines across an organization. - Policy-defined jobs cannot be bypassed through `[skip ci]` or `[no_pipeline]`. - Jobs can run in reserved pre- and post-pipeline stages, surrounding developer-defined jobs. - GitLab’s open-source Supply Chain Policies project provides independently deployable policies and sample violations for testing the three attack patterns. The practical recommendation is to make supply-chain validation mandatory and centralized: pin trusted inputs, inspect published artifacts, verify dependency changes, and block builds or releases when policy checks fail.

Read original(opens in new tab)

Database DesignCI/CDOpen SourceTrivy+4