gitlab·May 26, 2026·3 min readCurated summary

Full security scanner coverage of your codebase in minutes

GitLab 19.0 introduces security configuration profiles, enabling teams to centrally apply SAST, dependency scanning, and secret detection across many projects without editing individual `.gitlab-ci.yml` files. Profiles address coverage gaps caused by organizational growth, inconsistent configuration, and rapidly increasing AI-driven development. By applying default profiles in bulk, teams can achieve broad scanner coverage within minutes. ## Why Manual Scanner Configuration Falls Short - Per-project YAML configuration becomes difficult to maintain as organizations add repositories and teams. - Scanner settings can drift between frontend, backend, and older projects. - Pipeline changes may accidentally remove security scanners. - New projects may receive scanning while existing projects remain unprotected. ## Security Configuration Profiles - Profiles are centralized group-level settings defining how and when scanners run. - Teams can apply one profile to many projects through the GitLab UI. - GitLab provides default profiles for: - Static application security testing (SAST) - Dependency scanning - Secret detection - Default profiles use recommended settings and require no manual YAML changes. ## Scan Triggers and Coverage - SAST and dependency scanning run on: - Merge request pipelines, identifying vulnerabilities introduced by the proposed changes. - Pipelines on the default branch, maintaining a complete view of its security posture. - Secret detection supports both pipeline triggers plus push protection. - Push protection detects and blocks secrets during `git push`, before they enter the repository. - Push protection is event-based and therefore does not have a scan date in the security inventory. ## Practical Security Use Cases - Security teams can select hundreds of projects from the security inventory and apply scanners in bulk. - SAST can catch insecure code patterns before a merge request is approved. - Dependency scanning can detect compromised packages before they reach production. - Secret detection can block accidentally committed API keys immediately, avoiding later remediation and credential rotation. ## Getting Started - Available on GitLab Ultimate for GitLab.com, Self-Managed, and Dedicated. - Navigate to **Secure > Security inventory** for a group. - Select projects, choose **Manage security scanners** from **Bulk Action**, and select **Apply default profile to all**. - Review scanner status in the **Tool Coverage** column: - Green indicates full activation. - Partial coverage indicates some triggers are enabled. - Gray indicates the scanner is not configured. - Existing `.gitlab-ci.yml` settings can coexist with profiles, but inventory status may be inaccurate during the transition. Check the project’s **Security Configuration** page for the most reliable profile status. Organizations using GitLab Ultimate should apply default security profiles broadly, then review coverage and project-specific configurations to ensure every relevant trigger is active.

Read original(opens in new tab)

CI/CDGitlabYamlSast+4

gitlab·May 26, 2026·3 min readCurated summary

Reduce supply chain risk with SBOM-based dependency scanning

SBOM-based dependency scanning in GitLab 19.0 addresses the limits of traditional scanners that focus only on declared packages and known CVEs. It inventories direct and transitive dependencies, traces how vulnerable packages entered a project, and identifies whether application code actually reaches them. The result is more targeted remediation and easier organization-wide enforcement of supply chain security. ## Why Traditional Dependency Scanning Falls Short - Modern applications rely heavily on third-party and deeply nested dependencies. - Supply chain compromises can affect every project that depends on a vulnerable package. - AI-generated code further increases risk, with research indicating that nearly half contains vulnerabilities. - Teams need to know not only which packages are vulnerable, but also: - How they entered the project - What dependencies they brought with them - Whether the application actually uses them ## How SBOM-Based Scanning Works - The analyzer inventories dependencies in a CycloneDX-format software bill of materials. - Components are matched against the GitLab Advisory Database to identify known vulnerabilities. - Findings appear in: - Merge requests, so developers can address issues before release - Vulnerability dashboards and reports, for centralized security oversight - GitLab produces both an SBOM and a dependency scanning report for compliance and supply chain tooling. ## Tracing and Prioritizing Vulnerabilities - The analyzer follows transitive dependency chains regardless of nesting depth. - Teams can see the path a vulnerable package took into the project—for example, `library-a` → `library-b` → `library-c`. - For Java, JavaScript/TypeScript, and Python, GitLab checks whether vulnerable packages are directly imported or required. - Findings include reachability status, helping teams prioritize vulnerabilities their code can plausibly execute. - Scans can run on merge requests, pipeline executions, and when new advisories are published, including for production systems with little ongoing development. ## Supported Ecosystems and Input Files - The release supports more than 24 package ecosystems, with additional support planned. - Lockfiles and dependency graphs are preferred because they provide complete transitive dependency information. - If those are unavailable, the analyzer can parse manifests such as: - `pom.xml` - `requirements.txt` - Gradle build files - Manifest scanning identifies direct dependencies but offers less complete coverage because transitive dependencies may be missing. ## Centralized Configuration and Enforcement - GitLab 19.0 provides a security configuration profile for applying dependency scanning across many projects. - Security and platform teams can configure scanning once instead of maintaining individual pipeline files. - Scan execution policies and pipeline execution policies can enforce requirements at the group or instance level without modifying `.gitlab-ci.yml` files. - Centralized policies reduce configuration drift, skipped projects, and audit gaps. ## Availability and Migration - SBOM-based dependency scanning is available to GitLab Ultimate customers on GitLab.com and is rolling out to Dedicated and self-managed installations. - Teams migrating from Gemnasium can run both analyzers in parallel and compare their results. - GitLab provides setup instructions, migration guidance, and documentation for supported languages and advanced configuration. Teams should prefer lockfile-based SBOM scanning, enable it centrally through security policies, and prioritize remediation based on dependency reachability rather than vulnerability presence alone.

Read original(opens in new tab)

GitlabDevSecOpsVulnerability ManagementDependency Scanning+4

gitlab·May 21, 2026·2 min readCurated summary

Transform MRs from manual tasks to an automated workflow

GitLab 19.0 expands Developer Flow from generating merge requests to managing much of their entire lifecycle. Its AI agent can respond to reviews, investigate codebases, resolve conflicts, and split oversized MRs, while automation handles rebasing and merging. The result is less manual effort between opening and merging an MR, with developers supervising rather than executing every step. ## Developer Flow Across the MR Lifecycle - Can be triggered from: - An issue via **Generate MR** - An issue or MR assigned to the **Duo Developer** service account - Any issue or MR discussion using the new **@mention** trigger - Continues working on the same MR instead of creating separate changes to reconcile. - Handles: - Multiple rounds of reviewer feedback - Merge conflicts on long-running branches - Codebase research and technical evaluations - Oversized MR splitting - New feature implementation - Uses a single agentic loop with tools such as `read`, `grep`, file editing, and command execution. - Reads `AGENTS.md` for project conventions and operational guidance. - Uses `agent-config.yml` to configure dependencies, tooling, tests, and pre-commit hooks. These capabilities are available through GitLab Duo Agent Platform on Premium and Ultimate plans. ## Autonomous Merge Conflict Resolution - The beta **Resolve with Duo** button is available on the MR conflict page and merge checks widget. - The agent: - Reviews the MR’s intent and both branches - Selects a resolution strategy - Edits conflicting files - Commits and pushes the resolution - It leaves a summary comment explaining the conflict and resolution path. - If it cannot resolve the conflict safely, it reports that rather than guessing. ## One-Click Rebase and Merge - The beta feature combines rebasing and merging into one action. - It is designed for teams using semi-linear or fast-forward merge methods. - It is available on Free, Premium, and Ultimate tiers. ## Reducing Manual MR Work GitLab distinguishes between AI-driven judgment and mechanical automation: - AI handles code changes, reviewer feedback, and conflict resolution. - Automation handles tasks such as rebasing before merge. - Together, these features reduce the time developers spend on repetitive MR maintenance while preserving human oversight for steering, reviewing, and final decisions. Developers can try Developer Flow through a GitLab Duo Agent Platform trial. Existing Premium and Ultimate users with the platform can use it on merge requests, while older GitLab versions may require manually configuring the mention trigger.

Read original(opens in new tab)

AI AgentsCI/CDGitlabDevSecOps+4

gitlab·May 21, 2026·2 min readCurated summary

More AI models for GitLab Duo Agent Platform Self-Hosted

GitLab 19.0 expands open source model support for Duo Agent Platform Self-Hosted, giving regulated and air-gapped teams more capable AI options without sending source code to external APIs. The update supports selecting different models for different workflows and enables both fully on-premises and hybrid deployments. GitLab’s goal is to reduce the capability gap between isolated environments and cloud-based AI services. ## Challenges for Regulated and Air-Gapped Teams - Data residency, compliance rules, and network isolation often prohibit third-party AI APIs. - Air-gapped environments must run inference locally because they have no internet or external connectivity. - Teams have traditionally faced a trade-off between using an underpowered model and deploying an unnecessarily large model for routine tasks. - These constraints have limited AI productivity gains in highly regulated environments. ## Expanded Open Source Model Support GitLab evaluated models for: - Multi-step tool use - Instruction adherence - Code generation - Reasoning across large diffs and multi-file codebases Newly supported models include: - Mistral Devstral 2 123B - GLM-5.1 - Kimi-K2.6 - MiniMax-M2.7 ## Deployment Options - The recommended setup uses on-premises hardware with vLLM for model serving. - Organizations can also deploy models on GPU-enabled virtual machines in private clouds. - Both approaches keep data within the organization’s controlled environment. - Fully air-gapped teams should use locally hosted models and consult hardware requirements for each model. - Hybrid deployments can combine self-hosted and GitLab-managed models on a per-feature basis. ## Availability and Licensing - Offline-license customers need the GitLab Duo Agent Platform Self-Hosted add-on. - Online-license customers can use usage-based models and combine self-hosted and GitLab-managed models. GitLab recommends choosing models and infrastructure based on network isolation, compliance requirements, hardware availability, and workflow needs. The expanded support makes self-hosted AI a more practical option for organizations that require strict control over their code and data.

Read original(opens in new tab)

Gitlab Duo Agent PlatformVllmGpu InferenceSelf Hosted Ai+3

gitlab·May 21, 2026·3 min readCurated summary

Manage CI/CD credentials with GitLab Secrets Manager

GitLab Secrets Manager, entering public beta with GitLab 19.0, provides a native way to manage CI/CD credentials without storing them in broadly scoped variables or configuration files. Built on OpenBao and integrated with GitLab’s existing permissions, environments, branches, and audit trails, it aims to reduce credential exposure and simplify incident response. The post recommends trying it in existing GitLab projects and pipelines, especially where least-privilege access is difficult to enforce. ## Where CI/CD Secrets Commonly Go Wrong - Developers often store credentials in: - Project- or group-level CI/CD variables - Configuration files - Accidentally committed `.env` files - Masked CI/CD variables may still be exposed to every job and anyone with pipeline access. - Standalone vaults improve separation but introduce: - A second authentication system - Separate permission models - Additional audit logs and operational overhead ## Using GitLab Secrets Manager - Secrets are stored within GitLab’s existing project and group structure. - Pipelines reference secrets with the `secrets:` keyword in `.gitlab-ci.yml`. - By default, GitLab writes the secret to a temporary file and exposes its path to the job. - Passing a file path instead of the raw value can reduce exposure in: - Subprocesses - Crash dumps - Telemetry systems ## GitLab-Based Access Controls - Secrets use GitLab’s existing users, groups, projects, and roles. - Permissions can be assigned for reading, creating, updating, and deleting secrets. - Group-level secrets are inherited by nested projects, allowing common credentials to be defined once. - Removing someone from a project or group immediately removes their access to its secrets. - This avoids maintaining a separate access hierarchy that could drift from GitLab’s permissions. ## Job-Level Secret Scoping - Each secret can be restricted based on: - Target environment - Branch - Whether the branch is protected - Wildcards such as `production/*` simplify environment and branch rules. - Multiple conditions can be combined, such as requiring both a protected branch and a production environment. - At runtime, the backend verifies the job’s identity and scope before returning the secret. - Secrets are discarded when the job ends, and job logs are masked. - Narrow scopes reduce the systems affected if a dependency or pipeline is compromised. ## Auditing Secret Usage - Secret creation, updates, and deletions appear in GitLab’s existing audit trail. - Pipeline secret reads include the originating pipeline and job IDs. - Responders can trace where a credential was used without correlating separate systems manually. - Audit logging is available for self-managed deployments; GitLab.com support is expected during the beta. ## Public Beta Availability - The beta is available to Premium and Ultimate users on GitLab.com and self-managed deployments. - GitLab Dedicated support is planned. - The feature is free during beta and will later become a paid GitLab Credits feature. - Existing integrations with HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and Google Cloud Secret Manager remain available. GitLab Secrets Manager is best suited for teams that want least-privilege CI/CD credentials while keeping access control and auditing within GitLab. Teams can adopt it incrementally alongside existing external secrets platforms.

Read original(opens in new tab)

CI/CDAccess ControlSecrets ManagementAudit Logging+3

gitlab·May 21, 2026·4 min readCurated summary

GitLab 19.0 | GitLab Docs

GitLab 19.0, released May 21, 2026, expands AI-assisted development, work-item customization, secrets management, and dependency security. Major changes include group-level Duo review instructions, configurable work-item types, open beta access to GitLab Secrets Manager, and generally available SBOM-based dependency scanning. GitLab also introduces usage-based billing for Duo Core and adds new agent, search, model, and workflow capabilities. ## Customization and Project Management ### Group-level custom review instructions for GitLab Duo - Premium and Ultimate feature for GitLab.com, Self-Managed, and Dedicated. - Groups and subgroups can share review guidance through: ```text .gitlab/duo/mr-review-instructions.yaml ``` - A project in the group serves as the template. - Group instructions are combined with project-specific instructions. - Supported by both Code Review Flow and GitLab Duo Code Review. ### Configurable work item types - Projects can define custom types such as User Story, Bug, or Maintenance instead of using only Issues and Tasks. - Each type has its own name and icon. - Types support custom fields, status lifecycles, saved views, and issue boards. - Configuration at the top-level group or organization cascades to projects. - Administrators can enable or disable types globally or allow project-level control. - Disabling a type does not affect existing work items. ## Security and Dependency Management ### GitLab Secrets Manager enters open beta - Available to Premium and Ultimate customers on GitLab.com and GitLab Self-Managed. - Project and group Owners can store and reference CI/CD secrets in GitLab. - Secrets are scoped to projects or groups and available only to jobs that explicitly request them. - The feature remains subject to beta support policies and may not be production-ready. ### SBOM-based dependency scanning becomes generally available - Available for Ultimate customers across GitLab offerings. - Maven, Gradle, and Python projects receive visibility into transitive dependencies and their vulnerabilities. - Automatic dependency resolution runs when no lockfile or dependency graph is available. - If resolution is unavailable, manifest scanning examines direct dependencies in files such as: - `pom.xml` - `requirements.txt` - `build.gradle` - `build.gradle.kts` - Manifest scanning is enabled by default, while full transitive coverage requires dependency resolution, a lockfile, or a manually supplied dependency graph. ## GitLab Duo and Agentic Development ### Duo Developer enhancements - GitLab Duo Developer can be triggered by: - Assigning it to an issue - Selecting **Generate MR** - Mentioning it with `@mention` in an issue or merge request discussion - It can turn feedback, to-do items, and design questions into code changes, follow-up merge requests, or research summaries. - With `AGENTS.md` and `agent-config.yml`, it can run tests and checks before committing. - Administrators can enable mention and assignment triggers for eligible projects. ### Duo Core adopts usage-based billing - Code Suggestions in the Web IDE and desktop IDEs now consume GitLab Credits. - Duo Chat becomes agentic for Duo Core users and runs on the GitLab Duo Agent Platform. - Administrators must enable the Agent Platform for the instance or top-level group to use Chat in GitLab or desktop IDEs. ### New agent and search capabilities - Exact code search supports repository filtering with the `repo:` syntax: ```text def authenticate repo:my-group/my-project ``` - Flows and external agents can trigger when a draft merge request is marked ready for review. - The merge request ready trigger is controlled by the `merge_request_ready_flow_trigger` feature flag and is disabled by default. - Claude Opus 4.7 is available in the Duo Agent Platform for complex, multistep tasks involving code review, CI/CD, and vulnerability resolution. - GitLab Duo Agent Platform Self-Hosted adds compatibility with Gemini models and supports multiple flows, including Code Review Flow and SAST vulnerability workflows. GitLab 19.0 is particularly significant for teams adopting AI agents and centralized development governance. Organizations should review Duo’s new billing model, test Secrets Manager carefully during its beta period, and enable dependency resolution to obtain comprehensive vulnerability coverage.

Read original(opens in new tab)

CI/CDGitlabPythonGitlab Duo+4

gitlab·May 21, 2026·2 min readCurated summary

Track CI component usage across your organization

GitLab 19.0 adds Components Analytics to the CI/CD Catalog, giving organizations visibility into how shared CI/CD components are adopted and which versions projects use. All tiers provide high-level usage counts, while GitLab Ultimate offers project-level version tracking and outdated-version identification. The feature helps platform teams respond to security issues, manage upgrades, and govern increasingly AI-generated pipelines. ## The Visibility Gap in Shared CI - The CI/CD Catalog centralizes versioned, reusable pipeline components. - Previously, maintainers could not easily determine: - Whether components were being used - Which projects depended on them - Which versions were still active - Security fixes did not automatically reach projects using older component versions, making organizational exposure difficult to measure. ## High-Level Adoption Analytics - Available across all GitLab tiers, including Free; introduced in GitLab 18.9. - Found under **Explore > CI/CD Catalog > Analytics**. - Shows, for each maintained catalog resource: - The latest released version - The number of unique projects using it in the past 30 days - Components available in that version - Helps teams prioritize maintenance, plan deprecations, and assess investment in shared CI infrastructure. ## Component Usage Detail in Ultimate - GitLab Ultimate provides per-component drill-down analytics. - Maintainers can see: - Which projects used each component in the past 30 days - The version used by each project - Whether each project is up to date or outdated - This makes it easier to respond to vulnerabilities, notify project owners, open merge requests, and assess the impact of refactors or deprecations. ## Native Governance Compared with Other Platforms - GitHub Actions lacks native organization-wide catalog analytics for reusable workflows. - CircleCI Insights focuses on pipeline performance rather than orb adoption and versions. - Jenkins Shared Libraries require custom tooling to track usage. - GitLab combines a governed component catalog with built-in adoption and version visibility. ## Supporting AI-Generated Pipelines - The catalog establishes standardized CI practices, while analytics verifies whether those standards are actually used. - This is increasingly important as AI tools generate more production pipelines. - Self-Managed and Dedicated customers can mirror GitLab components and combine them with internally built components for regulated or air-gapped environments. Organizations maintaining CI/CD Catalog components can use adoption metrics immediately. Teams needing project-level version and remediation details require GitLab Ultimate.

Read original(opens in new tab)

CI/CDGitlabDevSecOpsYaml+3

gitlab·May 18, 2026·2 min readCurated summary

Beyond BYOK: Why governance matters for AI agents

BYOK and local models give developers more control over which AI systems they use, but they do not provide enterprise governance by themselves. The post argues that AI agents operating in CI/CD need platform-level controls for authorization, security, and auditing, especially when no human is present. It presents GitLab Duo CLI and its Agent Platform as a governance-oriented alternative for controlled, auditable automation. ## Terminal AI: Individual Tool vs. Platform - Copilot’s BYOK and local-model support primarily extend AI capabilities at an individual developer’s workstation. - The post argues these features do not enforce organization-wide model policies or provide a complete audit trail of agent actions. - GitLab Duo CLI is positioned for both interactive development and automated workflows across multiple projects and release cycles. - Its headless mode allows it to run non-interactively and scriptably inside CI/CD pipelines. ## Why Model Choice Is Not Governance - Interactive coding tools generally assume a human reviews every action. - Automated agents can run tests, modify configuration, and perform multi-step delivery tasks without continuous oversight. - Enterprise governance therefore requires answers to questions such as: - What resources can the agent access? - Which actions is it authorized to perform? - Can the organization prove what the agent did? - GitLab’s platform-level controls include: - Human approval for actions in interactive mode. - Prompt-injection detection. - Composite identity scopes limiting agent access. - `AGENTS.md` and `SKILL.md` files for defining permitted tasks and actions. ## CI/CD Automation Requires Consistent Controls - Potential use cases include debugging failed pipelines and completing multi-step development work. - Pipeline-based agents cannot rely on a developer to detect prompt injection or unexpected behavior. - Security controls must therefore be built into the platform and applied consistently across workflows and environments. ## Model Flexibility and Data Sovereignty - The post recommends evaluating whether AI tooling maintains its security model when no human is watching. - GitLab Duo CLI supports both self-hosted and GitLab-hosted models. - Organizations can keep sensitive workloads on infrastructure they control while using hosted models for other tasks. ## Practical Recommendation Model flexibility is useful, but production adoption depends on governance. Teams considering AI agents for CI/CD should prioritize authorization, auditing, prompt-injection protection, and consistent platform controls—not just BYOK or offline execution.

Read original(opens in new tab)

AI AgentsCI/CDDevSecOpsGovernance+3

gitlab·May 18, 2026·3 min readCurated summary

GitLab Dedicated for Government now GovRAMP-authorized

GitLab Dedicated for Government has received GovRAMP Authorization, giving state and local agencies a compliant path to adopt SaaS-based DevSecOps. Its single-tenant, U.S.-based architecture combines data residency, private networking, physical isolation, and managed infrastructure with GitLab’s development, security, and compliance capabilities. The authorization is especially timely as more states move toward mandatory GovRAMP requirements. ## Modernization Meets Security - Government agencies are increasing investments in hybrid- and multi-cloud modernization. - NASCIO’s 2025 survey ranked modernization as a top priority for state CIOs. - Agencies must modernize while addressing: - Aging IT systems and security gaps - Third-party software supply-chain risks - Ransomware and nation-state threats - Limited budgets and staffing - GitLab Dedicated for Government is designed to provide infrastructure control and compliance without requiring agencies to build and operate the underlying platform. ## GovRAMP Authorization - GovRAMP provides a standardized security and compliance assessment for state and local government cloud services. - Thirty-two states have adopted GovRAMP, with several moving toward mandatory requirements. - Authorization reduces a major procurement barrier for agencies seeking secure DevSecOps platforms. - GitLab Duo is available within the authorized environment, while GitLab Duo Agent Platform is planned for later in 2026. ## Toolchain Consolidation - Public-sector teams often use more than five development tools and more than five security tools, increasing cost, complexity, and attack surface. - Tool sprawl also creates collaboration barriers; surveyed teams reported losing roughly six hours per week to inefficient processes. - GitLab Dedicated for Government consolidates development, security, and compliance workflows on one platform. - Centralized access controls support zero-trust implementation and consistent security policies. - Open APIs and integrations allow agencies to consolidate tools gradually rather than requiring an immediate replacement of existing systems. ## Data Residency and Protection - The platform runs on GovRAMP-authorized infrastructure with data access restricted to U.S. citizens. - Private connections can link an agency’s virtual private cloud to its isolated GitLab instance without exposing services directly to the public internet. - Data is encrypted in transit and at rest. - Customers may use their own AWS Key Management Service key to control encryption for stored data. - GitLab continuously patches vulnerabilities and CVEs, reducing the infrastructure and compliance workload for agency teams. ## Managed, Single-Tenant Hosting - Each customer receives a physically isolated, single-tenant environment. - The service is U.S.-based, privately connected, and fully managed by GitLab. - Agencies can focus staff on mission priorities instead of infrastructure operations. - GitLab argues that managed hosting can provide faster time-to-value and lower total cost of ownership than self-hosting, while improving developer productivity, delivery speed, security, and compliance. ## Native Security and Compliance - Security and compliance capabilities are integrated throughout the software development lifecycle. - Built-in scanners include: - Static application security testing - Secret detection - Container scanning - Dynamic application security testing - Dependency scanning covers both direct and transitive dependencies without depth limits. - Results are available at the project and group levels, helping teams identify supply-chain risks across applications. - Findings appear directly in merge requests and pipeline security views for contextual, one-click triage. - Custom rulesets and automated security policies help reduce false positives and standardize enforcement. GitLab Dedicated for Government offers agencies a managed alternative to self-hosted DevSecOps while preserving stronger control over residency, isolation, networking, encryption, and compliance. For state and local governments preparing for stricter GovRAMP requirements, it provides a practical foundation for modernization without sacrificing security or operational control.

Read original(opens in new tab)

GitlabDevSecOpsCloud SecuritySoftware Supply Chain Security+4

gitlab·May 18, 2026·3 min readCurated summary

Fix bugs with Codex and GitLab

Codex accelerates coding in the terminal, but producing a fix is only one part of shipping software. GitLab supplies the surrounding lifecycle: issues, merge requests, CI/CD, security scanning, code review, and human approval. The tutorial demonstrates this progression through a Rust WebSocket bug, first with local Codex, then with GitLab MCP for issue context, and finally with Codex as an external agent in GitLab Duo Agent Platform. ## Prerequisites and Project Setup - Configure Codex in the terminal, Rust/Cargo, and access to a GitLab project. - Import and clone the Tanuki IoT Platform project, then launch Codex from its repository root. - The tutorial focuses on `backend/`, where: - Sensors submit readings through a REST API. - Dashboards receive live readings through WebSocket streams. - `AGENTS.md` provides Codex with repository structure, toolchain instructions, build commands, and quality expectations. ## Reproducing the WebSocket Filtering Bug - Start the Rust metrics backend on port `9090`: ```bash PORT=9090 cargo run --manifest-path backend/rust-metrics-store/Cargo.toml ``` - Connect to a filtered WebSocket stream: ```bash websocat 'ws://localhost:9090/ws?sensor=arduino-iot-collector&metric=temperature_celsius' ``` - Submit both temperature and humidity readings for the same sensor through the REST API. - The stream incorrectly returns both metrics instead of only `temperature_celsius`, proving that the WebSocket handler does not apply the metric filter. ## Fixing the Bug with Codex - Give Codex a focused request to add metric filtering to `/ws`. - Codex examines the Rust source and identifies that the endpoint already supports `sensor` filtering but lacks an optional `metric` condition. - It updates the handler, adds tests, and keeps documentation aligned with the implementation. - Codex runs formatting, tests, and builds before creating a branch, committing, and pushing the change. - Once the merge request is created, GitLab handles: - CI/CD pipelines - Security scanning - GitLab Duo Code Review - A follow-up WebSocket test confirms that supplying both sensor and metric now returns only the requested metric. ## Adding GitLab Context with MCP - Local Codex can inspect repository files, but it cannot automatically see GitLab issues, requirements, implementation notes, merge-request discussions, or pipeline status. - The GitLab MCP server connects Codex to that development lifecycle context. - Codex can retrieve the existing issue directly instead of requiring the developer to copy its contents into the prompt. - The issue acts as the shared source of truth and includes: - The bug description - Functional behavior requirements - Non-functional requirements - Required tests - Updates to `README.md` and `AGENTS.md` - Implementation notes - This helps Codex produce a fix that satisfies the agreed requirements rather than merely addressing the symptom visible in the local code. ## Using Codex as an External GitLab Agent - The tutorial’s third workflow uses Codex inside GitLab Duo Agent Platform as an external agent. - This allows the agent to participate after the merge request is open, particularly when addressing review feedback. - GitLab remains the system coordinating issues, merge requests, pipelines, reviews, and deployment, while Codex contributes its terminal-oriented coding capabilities. - The overall workflow moves from bug report to implementation, automated validation, review feedback, revisions, and an informed human decision to ship. ## Practical Conclusion Use Codex for fast, repository-local implementation, but connect it to GitLab through MCP or Duo Agent Platform when requirements and review context matter. The strongest workflow combines Codex’s coding speed with GitLab’s issue-aware, automated, and human-governed delivery lifecycle.

Read original(opens in new tab)

AI AgentsCI/CDGitlabRust+3

gitlab·May 13, 2026·2 min readCurated summary

5 ways to fix misleading vulnerability severities with policy

CVSS scores describe a vulnerability’s general characteristics, not its actual risk in a specific environment. GitLab severity override policies let teams automatically adjust findings based on CVE, CWE, file path, or directory, reducing manual triage. The result is a vulnerability report that better reflects deployment context, exploitability, and organizational priorities. ## How Severity Override Policies Work - Policies run automatically on every default-branch pipeline. - Rules match findings by: - CVE identifier - CWE identifier - File path - Directory - Available actions: - **Set Severity** to informational, low, medium, high, or critical - **Increase Severity** by one level - **Decrease Severity** by one level - Manual overrides by authorized users take precedence. - GitLab records automated changes in vulnerability history and audit events. ## Downgrading Low-Risk CVEs in Internal Services - Internal tools and services may have substantially lower exposure than public-facing applications. - A policy can reduce the severity of selected CVEs found under paths such as `internal/**/*`. - The `decrease` operation lowers severity by one level—for example, Critical to High or High to Medium. - Teams should replace the example CVEs with vulnerabilities they have assessed as less risky in internal deployments. ## Upgrading Injection Vulnerabilities in Production Code - XSS (`CWE-79`) and SQL injection (`CWE-89`) are frequently exploited vulnerability classes. - Findings involving these CWEs under `src/**/*` can be forced to **Critical**. - Combining this override with a merge request approval policy can require security-team review before affected code reaches production. ## Normalizing Severity Across Scanners - SAST, dependency, and container scanners may assign different severities to the same CVE. - A policy can set specific vulnerabilities—such as Log4Shell-related CVEs—to a consistent baseline, such as High. - This produces more predictable triage and approval thresholds across scanning tools. ## Incorporating Exploitation Intelligence - CVSS is largely static and does not reflect changes in real-world exploitation. - EPSS and CISA’s Known Exploited Vulnerabilities catalog provide signals about exploitation likelihood and active attacks. - Teams can explicitly upgrade CVEs identified as actively exploited or highly likely to be exploited, treating them as Critical regardless of their original scanner rating. GitLab severity overrides are most useful when they encode a documented risk model: deployment exposure, vulnerability type, scanner consistency, and current threat intelligence. They should complement—not replace—manual review, auditability, and merge request approval controls.

Read original(opens in new tab)

GitlabVulnerability ManagementYamlSast+4

gitlab·May 13, 2026·2 min readCurated summary

GitLab Patch Release: 18.11.3, 18.10.6, 18.9.7 | GitLab Docs

On May 13, 2026, GitLab released patch versions 18.11.3, 18.10.6, and 18.9.7 for CE and EE. The releases address multiple high-severity security vulnerabilities, including cross-site scripting, denial of service, authorization, and access-control issues. GitLab strongly recommends that all affected self-managed installations upgrade immediately. ## Release Scope and Upgrade Guidance - Applies to GitLab Community Edition and Enterprise Edition. - GitLab.com is already patched; GitLab Dedicated customers do not need to act. - Patch releases may be scheduled or issued urgently for critical vulnerabilities. - Security vulnerability details are published publicly 30 days after the fixing release. - Unless otherwise specified, all deployment types—including Omnibus, source installations, and Helm charts—are affected. ## Cross-Site Scripting Vulnerabilities Several authenticated-user XSS vulnerabilities could allow arbitrary JavaScript to execute in other users’ browsers: - **CVE-2026-7481**: Affects EE Analytics dashboard chart rendering; exploitable by users with Developer permissions. - **CVE-2026-5297**: Affects global search in CE and EE. - **CVE-2026-6073**: Affects EE Duo Agent output rendering. - **CVE-2026-7377**: Affects customizable EE Analytics dashboards. - Each issue received a **CVSS score of 8.7** and resulted from improper input sanitization. ## Denial-of-Service Vulnerabilities The release fixes multiple unauthenticated denial-of-service issues involving malformed requests or files: - **CVE-2026-1659**: Specially crafted requests to the CI/CD job update API could disrupt service. - **CVE-2025-14870**: Malformed JSON payloads targeting the Duo Workflows API could cause a denial of service. - **CVE-2025-14869**: Certain internal API endpoints were vulnerable to specially crafted payloads. - **CVE-2026-1184**: A specially crafted file uploaded through Insights Configuration could cause service disruption. - The API-related issues were rated **CVSS 7.5**; the Insights issue was rated **6.5**. ## Authorization and Access-Control Issues - **CVE-2026-1322**: An authenticated user with a `read_api`-scoped OAuth application could create issues and comment on private projects through GraphQL, due to improper token-scope enforcement. It received a **CVSS score of 6.8**. - **CVE-2026-4524**: Authenticated users could access confidential issue content in public projects through the Issues API without proper authorization checks. It received a **CVSS score of 6.5**. ## Recommended Action Self-managed GitLab administrators should upgrade to the latest supported patch release—18.11.3, 18.10.6, or 18.9.7—as soon as possible, particularly because several vulnerabilities are remotely exploitable and require little or no authentication.

Read original(opens in new tab)

GitlabJavaScriptGraphQLOauth+3

gitlab·May 13, 2026·2 min readCurated summary

Harden your pipeline perimeter for the era of AI-assisted coding

AI-assisted coding brings humans, agents, and third-party code together in the software pipeline, increasing the speed at which vulnerabilities can be introduced. The post argues that security tools must become part of the development workflow rather than separate portals. GitLab Ultimate presents this as a three-part control plane: see every risk, automatically enforce policy, and help developers fix vulnerabilities in context. ## See Every Project, Risk, and Action - The Group Security Dashboard consolidates SAST, SCA, secret detection, container, IaC, DAST, and fuzz-testing results across projects. - Security Inventory identifies projects that have never been scanned, exposing governance gaps hidden by project-level dashboards. - Credentials Inventory tracks tokens, owners, scopes, expiration, and revocation status, enabling rapid response to compromised credentials. - Token Lifetime Enforcement applies mandatory maximum lifetimes to tokens. - Audit Event Streaming sends events such as token creation, permission changes, MR approvals, and role updates to SIEM systems in real time. - Group-wide SBOM search helps identify open-source dependency exposure across the project portfolio. ## Enforce Policies Automatically - Scan Execution Policies inject mandatory SAST, SCA, and secret-detection jobs into production pipelines and prevent removal or bypass through configuration such as `[skip ci]`. - Pipeline Execution Policies enforce platform-owned CI templates, closing gaps created by ungoverned or “shadow” pipelines. - MR Approval Policies automate requirements for protected branches, approvers, and code owners. - The Compliance Center maps controls to SOC 2, ISO 27001, NIST, and PCI DSS while providing live dashboards and audit trails. - Secret Push Protection rejects credentials before they enter Git history and records bypass attempts. ## Fix Vulnerabilities in the Development Workflow - The MR security widget displays SAST, SCA, container, IaC, and secret findings directly alongside code changes before they reach the default branch. - Advanced SAST uses cross-file taint analysis to trace untrusted input from source to sink. - GitLab Duo helps identify likely false positives and explain the reasoning behind its assessment. - The Duo Security Analyst Agent prioritizes issues using exploitability, exposure, and business context in addition to CVSS. - Agentic Vulnerability Resolution can create fix merge requests for high-impact SAST findings, allowing developers to review and merge changes through the normal approval process. The practical recommendation is to make security controls native to the pipeline. For organizations adopting AI-assisted development, GitLab Ultimate’s integrated visibility, automated enforcement, and AI-supported remediation are presented as a way to maintain security without sacrificing delivery speed.

Read original(opens in new tab)

CI/CDGitlabDevSecOpsSast+4

gitlab·May 11, 2026·4 min readCurated summary

GitLab Act 2

GitLab is restructuring its organization and strategy to prepare for an agent-driven software industry. It expects AI agents to dramatically increase software production, making scalable infrastructure, orchestration, context, and governance more important than traditional developer tooling. The company is reducing geographic footprint and management layers while reorganizing R&D around smaller, autonomous teams, reaffirming its FY27 guidance pending final restructuring costs. ## Organizational Restructuring - GitLab is conducting the process openly, including a voluntary separation window. - The new organizational shape is expected to be finalized by June 1 where possible; local legal processes may extend timelines. - Planned operational changes include: - Reducing the number of countries with small GitLab teams by up to 30%, while relying on partners in affected markets. - Removing up to three management layers in some functions. - Reorganizing R&D into approximately 60 smaller teams with end-to-end ownership. - Automating internal reviews, approvals, and handoffs with AI agents, then adjusting roles accordingly. - The restructuring and strategic shift are related but independently justified. - GitLab will disclose the restructuring’s final scope and financial impact during its June 2 earnings call. ## Software Development in the Agentic Era - Software will increasingly be produced by machines under human direction. - Agents will plan, code, review, deploy, and repair software. - Engineers will remain responsible for architecture, customer understanding, judgment, and difficult tradeoffs. - Lower software-production costs are expected to expand demand for software and increase the value of developer platforms. - Deep engineering skills—such as system design, distributed systems, failure analysis, and integrating new capabilities safely—will become more important and scarce. - GitLab points to its Duo Agent Platform, released in January, as an initial investment in this future. ## Infrastructure for Machine-Scale Development - Agents can create merge requests, trigger pipelines, and push commits at volumes far beyond human teams. - Git and existing development platforms were not designed for this level of activity. - GitLab plans to: - Reengineer Git for machine-scale workloads. - Replace parts of its monolithic architecture with API-first, composable services. - Provide agent-specific APIs so agents can interact as first-class platform users. - The company argues that reliability, performance, and scalability at this level will become a major source of platform value. ## Orchestration Across the Software Lifecycle - Enterprises need more than individual agents that generate code or open merge requests; they need software that reaches production and delivers business value. - GitLab’s orchestration layer is intended to coordinate agents across the lifecycle by: - Assigning work and managing state. - Passing context between tasks. - Resolving conflicts. - Enforcing policies and guardrails. - Keeping humans involved where judgment is required. - CI/CD is being reconsidered as part of this shift, with orchestration serving as the runtime for validating and safely deploying machine-rate changes. ## Context as a Competitive Advantage - Code generation capabilities are increasingly similar across developer-tool vendors. - GitLab believes its advantage lies in the connected context accumulated across planning, code, review, security, deployment, and operations. - It plans to make this data model a first-class, API-accessible service. - More contextual information should allow agents to use fewer tokens and produce better results. ## Governance Built Into the Platform - As agents perform more work, enterprises need strong control over identity, permissions, policies, auditing, and data location. - GitLab intends to make governance core infrastructure rather than an add-on product. - Every agent, pipeline, and merge request should operate through platform services that can: - Control who or what may perform an action. - Record what happened and why. - Protect sensitive code and data. - Support flexible deployment models. ## One Platform, Three Modes - GitLab notes that most business software cannot realistically be rewritten for the agentic era. - Its platform strategy is therefore intended to support existing codebases alongside newer development models. - The provided text ends before explaining the three modes in detail. GitLab’s overall recommendation to itself is to reshape both its organization and platform around machine-scale software development, while preserving human control over architecture, judgment, and governance.

Read original(opens in new tab)

AI AgentsCI/CDGitlabDistributed Systems+4

gitlab·May 7, 2026·3 min readCurated summary

Consolidate your GitLab stack with Gitaly on Kubernetes

Gitaly on Kubernetes is now generally available with GitLab 18.11, allowing teams to run their entire GitLab stack in Kubernetes instead of maintaining Gitaly on separate virtual machines. GitLab addressed Kubernetes-specific challenges involving cgroup isolation, pod restarts, and request reliability. The result is a more unified deployment model, though full high availability still depends on Gitaly Cluster support for Kubernetes. ### Challenges of Running Gitaly on Kubernetes - Git operations can consume unpredictable amounts of memory. - Gitaly isolates individual Git processes in dedicated cgroups so an out-of-memory failure does not bring down the main Gitaly process. - Kubernetes deployments required special handling because containerd traditionally restricted cgroupfs writes to privileged containers. - GitLab solved this by using an init container to mount `/sys/fs/cgroup` and make it writable. ### Handling Pod Restarts - Virtual-machine deployments can upgrade Gitaly in place and reload gracefully while preserving the socket. - Kubernetes StatefulSet replacements cause pods to stop and restart abruptly during upgrades, node drains, or configuration changes. - This could cause downtime, particularly for Gitaly Sharded deployments without built-in high availability. - GitLab made Gitaly client retries configurable, allowing clients such as Rails to retry requests until Gitaly becomes available again. - Users may experience slightly higher latency during restarts, but requests generally succeed without visible downtime. ### Benchmark Results and High Availability - GitLab tested common Git operations against VM-based and Kubernetes-based Gitaly installations during upgrades. - Success rates were nearly identical in both environments despite Kubernetes abruptly terminating pods and closing sockets. - Achieving complete success across every operation still requires Gitaly Cluster with Praefect. - Praefect does not yet support Kubernetes, but Kubernetes support is being developed. ### Benefits for GitLab Deployments - Teams with hybrid infrastructure can move Gitaly from virtual machines into their existing Kubernetes cluster. - This removes the need to maintain and monitor a separate VM fleet. - Organizations adopting GitLab on Kubernetes can use a fully Kubernetes-native deployment through the official Helm chart. - Gitaly can run as part of a complete GitLab installation or as an external component. ### Installation - The recommended deployment method is the GitLab Helm chart. - Users should review the Gitaly on Kubernetes documentation before installation. - The documentation covers configuration guidance, common pitfalls, full installations, and external Gitaly deployments. Gitaly on Kubernetes is a practical option for consolidating GitLab infrastructure and simplifying operations. Teams should use the Helm chart and configure client retries carefully, while recognizing that Kubernetes-based high availability through Praefect is still forthcoming.

Read original(opens in new tab)

KubernetesGitlabGitGitops+4