DevSecOps

52 posts

gitlab3 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)
gitlab3 min readCurated summary

Streamline test management with SmartBear QMetry GitLab component

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

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

GitLab Duo CLI: Agentic AI now in the terminal

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

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

Manage vulnerability noise at scale with auto-dismiss policies

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

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

Code Review without the bottlenecks or the bill

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

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

Agentic code reviews for $0.25 each

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

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

Automating detection gap analysis with GitLab Duo Agent Platform

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

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

Navigate repositories faster with the file tree browser

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

Read original(opens in new tab)
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)
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.