gitlabJul 16, 2026

GitLab 19.2 release notes | GitLab Docs (opens in new tab)

GitLab 19.2, released July 16, 2026, focuses heavily on AI-assisted development, workflow automation, and centralized security controls. Major additions include the generally available GitLab Duo CLI and custom flows, scheduled pipeline execution policies, and Agentic Chat integrations. Several security features remain in beta, including automated dependency remediation and vulnerability tracking on non-default branches. ## AI-Assisted Development - **GitLab Duo CLI is generally available** for Premium and Ultimate users across GitLab.com, Self-Managed, and Dedicated. - Provides interactive chat and headless CI/CD modes. - Understands GitLab projects, pipelines, and agent configurations. - Supports model selection, shared sessions, tool approvals, MCP connections, slash commands, skills, and `AGENTS.md`. - Can be installed through `glab` or as a standalone tool. - **Custom flows are generally available** across all tiers. - Define reusable, YAML-based workflows for complex multi-step tasks. - Support multi-agent orchestration and human approval checkpoints. - Trigger from mentions, assignments, pipelines, and merge request events. - Offer project or AI Catalog management, visibility controls, secure service-account execution, and YAML validation. - **Foundational flows can now start from Agentic Chat.** - Developer Flow can implement changes or open merge requests. - Code Review Flow can review merge requests. - Fix CI/CD Pipeline Flow can diagnose and repair failed pipelines. - Users approve the handoff and monitor progress in chat or under AI sessions. ## Centralized Pipeline Automation - **Scheduled pipeline execution policies are generally available for Ultimate.** - Define schedules centrally in a security policy project. - Apply them across projects without modifying each project’s `.gitlab-ci.yml`. - Run compliance scripts, security scans, and other jobs independently of commit activity. - Support daily, weekly, or monthly schedules, time zones, time windows, and branch targeting. - Each policy creates a separate pipeline. ## Dependency and Vulnerability Management - **Dependency scanning auto-remediation is in beta.** - Automatically opens merge requests for vulnerable dependency upgrades. - Defaults to patch and minor version updates. - Agentic Breaking Change Resolution can address failed pipelines caused by complex or major upgrades. - GitLab Duo analyzes errors, changelogs, and code usage, commits fixes to the same merge request, and reruns the pipeline. - The feature creates an end-to-end remediation loop, from vulnerability detection through upgrade and repair. - **Non-default branch vulnerability tracking is in beta.** - Supports long-lived branches such as `project-qa`, `project-prod`, `project-iOS`, and `project-android`. - Allows branch-specific filtering in vulnerability reports and dashboards. - Tracks all vulnerability types, including CVEs. - Preserves vulnerability metadata when branches merge into the default branch. - Allows up to twice as many tracked branches as projects in the namespace. ## Governance and Administration - **Selective GitLab Duo availability is available for GitLab Dedicated and Dedicated for Government.** - Administrators can lock selected subgroups and descendants into an “Always off” state. - Other subgroups can retain the option to enable Duo according to their permissions. - The model provides a per-subgroup allowlist rather than disabling AI for the entire instance. - Owners receive clear messaging when a parent group has disabled the features. ## Contributor Recognition - GitLab recognized **vivekshukl007** as the month’s Notable Contributor. - Their contribution added Scala language support to GitLab Orbit, improving code graph capabilities for Scala projects. GitLab 19.2 is especially valuable for teams adopting AI-driven development and centralized security automation. Organizations should evaluate Duo CLI and custom flows for productivity gains, while testing the dependency remediation and non-default branch features carefully because they remain in beta.

yamlgitlabmodel-context-protocolvulnerability-management+4

gitlabJun 18, 2026

GitLab 19.1 release notes | GitLab Docs (opens in new tab)

GitLab 19.1, released June 18, 2026, focuses heavily on AI governance, security scanning, and compliance automation. The release adds AI-assisted false-positive detection for secrets, centralized controls for GitLab Duo, stronger approval guardrails for agents, and broader secret detection in feature branches. It also streamlines code review and compliance setup through automatic Code Owner assignment and framework templates. ## Security and Secret Detection - **GitLab Duo secret false-positive detection** is generally available for Ultimate users. - Automatically analyzes critical and high-severity secret detection findings after scans. - Provides reasoning and confidence scores directly in vulnerability reports. - Supports manual analysis from individual vulnerability pages. - Helps security teams prioritize real threats and reduce alert fatigue. - **Improved feature branch secret detection** scans every commit from the branch’s divergence point from the default branch through the latest commit. - Previously, new branches or existing branches could leave secrets in earlier commits undetected. - The broader scan helps identify leaked credentials before they reach shared branches or production. ## GitLab Duo Administration and AI Governance - **Always-on availability mode** lets instance and top-level group administrators require GitLab Duo to remain enabled. - Project, subgroup, and group owners cannot disable Duo when this policy is active. - This complements the existing “always off” setting and supports centralized governance. - **Tool approval guardrails for Duo agents** introduce three policy modes for individual tools: - **Allow:** execute without user interaction. - **Ask:** require inline human approval. - **Deny:** block the tool entirely. - Approval decisions generate audit events. - The beta applies to Agentic Chat, IDE integrations, and flows. - **Custom and external AI feature controls** allow administrators and top-level group Owners to: - Prevent users from creating or enabling custom agents and flows. - Block agents and flows owned outside the organization’s group hierarchy. - **Custom flow YAML validation** checks configurations when flows are saved or updated. - Errors such as missing inputs or invalid tool parameters are reported before runtime. - This avoids discovering configuration problems only after a CI job begins. - **Pattern-based tool approval for Agentic Chat** is also introduced in the Agentic Core updates, extending administrative control over how agent tools can be used. ## Code Review and Compliance - **Automatic Code Owner reviewer assignment** removes the need to manually select reviewers for merge requests. - GitLab assigns all Code Owners matching the changed files. - Assignment occurs when a merge request is created as ready or when a draft becomes ready. - Existing reviewer selections are preserved. - **Compliance framework templates** are available in beta for Ultimate users. - Teams can create frameworks from predefined requirements and controls. - Templates can be previewed and customized before being applied. - Nineteen templates are available, including ISO 27001:2022, SOC 2, FedRAMP, NIST, CIS, and TISAX. ## Contributor Recognition - GitLab recognizes **Pishel65** as the month’s Notable Contributor. - The Level 3 contributor had 19 merged merge requests and nine additional open merge requests since joining in October 2025. GitLab 19.1 is particularly valuable for organizations adopting AI at scale: enable centralized Duo policies, require approval for sensitive agent actions, validate flows before execution, and use the expanded security and compliance features to reduce operational risk.

yamlai-agentgitlabci-cd+4

githubJun 9, 2026

From one-off prompts to workflows: How to use custom agents in GitHub Copilot CLI (opens in new tab)

Custom agents in GitHub Copilot CLI turn repeated terminal tasks into reusable, consistent workflows. Defined as Markdown profiles in a repository, they encode team-specific expertise, tools, standards, and safety rules instead of relying on one-off prompts. This makes workflows easier to review, version, share, and reuse across the CLI, IDE, and GitHub. ## What Custom Agents Are - A custom agent is a specialized Copilot agent configured through a Markdown file. - Its profile specifies: - Role and area of expertise - Available tools - Required standards and procedures - Guardrails and expected output formats - Teams can tailor agents to requirements such as: - WCAG accessibility standards - Formatting and testing conventions - Security and privacy policies - Review and ownership requirements - Because profiles live in the repository, they can be versioned, reviewed, and shared like code. ## Creating and Using Agents in Copilot CLI - Invoke Copilot CLI from the terminal and use the `/agent` command to select an agent. - Store the profile in the repository’s `.github/agents` directory. - Agent files use YAML frontmatter and typically end in `.agent.md`, such as `accessibility.agent.md`. - The profile defines the agent’s name, description, model, tools, instructions, scope, and guardrails. - Copilot CLI is especially suitable for these agents because it can execute scripts, call APIs, inspect repositories, and work directly with command-line tooling. ## Automating Repeated Workflows Custom agents are most useful for recurring tasks that span the terminal, IDE, and pull requests. - A security audit agent can: - Run standard checks across repositories - Group findings by Critical, High, Medium, and Low severity - Produce a pull-request-ready checklist with owners and next steps - It can use tools such as `gitleaks`, `trivy`, `semgrep`, `gh`, `git`, and `jq`. - Agents should prefer existing repository configuration files, including `.semgrep.yml`, `.trivyignore`, and `.gitleaks.toml`. - Missing security tools should be reported as coverage gaps rather than replaced with invented results. - Instructions can require secrets to be redacted, inclusive terminology, and consistent date formats. - Ownership mappings can assign findings to teams based on affected paths, using `CODEOWNERS` when available or defined defaults otherwise. Custom agents provide a practical way to capture team expertise once and apply it consistently. Start by converting a repetitive, execution-heavy task into a narrowly scoped `.github/agents` profile with explicit tools, outputs, and safety rules.

yamlmarkdowngithub-copilot-clisast+4

tossJun 8, 2026

Rubric Design and System Implementation for Skill Quality Management (opens in new tab)

Toss’s AI DX Team created a 30-item rubric to improve the quality of internal Skills used by coding agents. The central conclusion is that deterministic defects should be checked with rules, while semantic questions—especially whether a Skill will be triggered—should be evaluated by an LLM. This separation improves accuracy, cost efficiency, and developer feedback. ## Why Skill Evaluation Is Difficult Skills are artifacts that are both invoked and read by LLMs, so they lack the compiler and test-based validation available for code. - Defects can accumulate silently: - A Skill may never be invoked. - It may be invoked but have little practical effect. - Two especially common problems are: - **Trigger failure:** Trigger conditions are placed in the Skill body instead of its description. Agents inspect the description when deciding whether to invoke a Skill; the body is read only afterward. - **Format failure:** Invalid naming conventions, mismatched folder names, or malformed metadata can prevent the agent from recognizing the Skill at all. ## Rules for Deterministic and Semantic Checks The rubric explicitly separates the 30 checks into: - **17 rule-based checks** - Use regular expressions, counts, and AST parsing. - Handle objective issues consistently and cheaply. - **13 model-based checks** - Use an LLM for meaning-dependent judgments. - Evaluate questions such as whether a description adequately communicates when the Skill should be used. Mixing the two approaches causes problems: - LLMs may overlook clear format violations. - Regular expressions produce false positives when trying to understand varied natural-language intent. - Rule checks can run on every pull request at nearly no cost. - Model checks run only after structural blockers have passed, reducing LLM expenses. ## Rubric Structure and Severity The rubric contains six sections and 30 evaluation items. - Each item is classified as: - **BLOCKER** - **MAJOR** - **MINOR** - Results are summarized using grades from **S to F**. - Any single BLOCKER automatically produces an **F**. - The grade is primarily a compact signal for authors; merge eligibility is simplified to whether the result is F or not-F. ## Validity: Does the Skill Need to Exist? The validity section contains three MAJOR checks. - It asks whether the Skill: - Has a legitimate reason to exist. - Provides recurring or reusable value. - Offers something more useful than simply asking the coding agent to perform the task directly. - This section is intended to identify Skills that should not have been created in the first place. ## Structure: Catching Format Errors The structure section has eight checks, including five BLOCKER-level checks. The rule-based implementation verifies items such as: - Presence and parseability of YAML frontmatter. - `name` following lowercase kebab-case. - Consistency between the Skill’s `name` and its folder name. - Description length between 1 and 1,024 characters. - Absence of XML tags in the body. The checks collect all failures and return them together so authors can fix multiple problems from a single pull-request comment. Only an unrecoverable frontmatter parsing failure causes an immediate return. ## Trigger Design: Making Skills Discoverable The trigger section contains six checks, including one BLOCKER. - A description must communicate both: - **WHAT** the Skill does. - **WHEN** it should be used. - A detailed “when to use” section in the body is insufficient because the agent cannot see the body during invocation selection. - The team initially tried regular expressions to detect trigger signals such as: - “when” - “use when” - Korean expressions meaning “when using” or “at the time of.” - This produced failures because trigger intent can be expressed through emojis, indirect wording, and many other forms that keyword lists cannot cover. - The final approach assigns the semantic question—whether the description covers the body’s trigger conditions—to an LLM. The resulting design favors simple, repeatable rule checks for formal correctness and model-based evaluation only where natural-language meaning is unavoidable.

yamlllmpythoncoding-agents+3

gitlabMay 26, 2026

Full security scanner coverage of your codebase in minutes (opens in new tab)

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.

yamlgitlabci-cdsast+4

gitlabMay 21, 2026

Track CI component usage across your organization (opens in new tab)

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.

yamlgitlabci-cddevsecops+3

gitlabMay 13, 2026

5 ways to fix misleading vulnerability severities with policy (opens in new tab)

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.

yamlgitlabvulnerability-managementsast+4

githubMay 7, 2026

Improving token efficiency in GitHub Agentic Workflows (opens in new tab)

GitHub’s Agentic Workflows can quietly accumulate substantial token costs because they run automatically in CI. GitHub improved efficiency by instrumenting token usage, auditing workflows, pruning unused MCP tools, and replacing many MCP data-fetching calls with deterministic GitHub CLI commands. Early results show that reducing context and removing unnecessary LLM reasoning can save thousands of tokens per run, though measuring true efficiency requires accounting for model choice and workload quality. ## Logging Token Usage - GitHub runs hundreds of agentic workflows against real GitHub Actions limits. - Different agent frameworks produced incompatible usage logs, so GitHub used its API proxy to normalize data across Claude CLI, Copilot CLI, and Codex CLI. - Each workflow now emits a `token-usage.jsonl` artifact containing: - Input, output, cache-read, and cache-write tokens - Model and provider - Timestamps - One record per API call - These records make it possible to compare historical runs and identify recurring sources of waste. ## Automated Auditing and Optimization - A daily **Token Usage Auditor** aggregates recent usage by workflow and reports: - Significant increases in token consumption - The most expensive workflows - Anomalous runs, such as a workflow taking 18 LLM turns instead of its usual four - A daily **Token Optimizer** examines flagged workflows, their source YAML, and recent logs. - It creates GitHub Issues with concrete inefficiencies and recommended fixes. - The auditing workflows also consume tokens, creating a feedback loop in which their own costs are monitored. ## Removing Unused MCP Tools - MCP tool names and JSON schemas are typically included in every stateless LLM request. - A GitHub MCP server with roughly 40 tools can add 10–15 KB of schema to every turn. - If a workflow uses only two tools, the other 38 create repeated overhead without adding value. - GitHub compares configured tools with actual tool calls and recommends removing unused registrations. - In smoke tests, pruning tools reduced each call’s context by 8–12 KB and saved several thousand tokens per run without changing behavior. ## Replacing MCP Calls with GitHub CLI - GitHub found larger savings by replacing MCP calls for predictable data retrieval—such as pull request diffs, file contents, and review comments—with `gh` commands. - MCP calls require an additional reasoning cycle: the model chooses a tool, constructs arguments, and processes the response. - Commands such as `gh pr diff` make deterministic API requests without involving the LLM in the retrieval step. Two migration patterns were used: - **Pre-agentic downloads** - Workflow setup steps run `gh` commands before the agent starts. - Results such as diffs and changed-file lists are saved to workspace files. - The agent reads the files directly, eliminating MCP round trips. - **In-agent CLI proxy substitution** - When data must be selected dynamically, the agent runs commands such as `gh pr view --json`. - A transparent proxy routes CLI requests to GitHub’s API without exposing credentials. - This preserves the zero-secrets security model while avoiding MCP overhead. ## Measuring Efficiency - Lower token counts do not necessarily mean better workflows; a workflow may simply be doing less work. - Model selection also affects cost. Claude Haiku and Sonnet may use similar numbers of tokens, but Haiku is substantially cheaper. - GitHub therefore uses an **Effective Tokens (ET)** metric that weights usage by token type and model cost: ```text ET = m × (1.0 × I + 0.1 × C + 4.0 × O) ``` - `m` represents the model multiplier: Haiku `0.25×`, Sonnet `1.0×`, and Opus `5.0×`. - `I` is newly processed input, `C` is cache-read tokens, and `O` is output tokens. - Output tokens receive greater weight because they are typically the most expensive component. GitHub’s experience suggests that agentic workflow authors should measure usage continuously, remove tools that workflows do not actually use, and move routine API retrieval outside the LLM reasoning loop wherever possible.

yamlllmmodel-context-protocolgithub-actions+3

gitlabApr 16, 2026

CI Expert and Data Analyst AI agents target development gaps (opens in new tab)

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

yamlgitlabai-mldevops+4

gitlabMar 25, 2026

Manage vulnerability noise at scale with auto-dismiss policies (opens in new tab)

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.

yamlgitlabdevsecopsvulnerability-management+3

githubMar 16, 2026

GitHub for Beginners: Getting started with GitHub Actions (opens in new tab)

GitHub Actions is GitHub’s built-in platform for automating CI/CD and repetitive repository tasks. Workflows are YAML files triggered by events such as pushes, pull requests, schedules, or newly opened issues, then executed as jobs on hosted or self-hosted runners. The post guides beginners through creating a workflow that automatically labels new issues. ## What GitHub Actions Provides - GitHub Actions supports: - Continuous integration and delivery - Automated tests and vulnerability scans - Release creation - Team reminders and other repetitive tasks - Workflows are stored in the repository and run automatically when configured events occur. - Jobs execute in virtual machines called runners, provided by GitHub or managed by the user. ## How Workflows Operate - **Events** trigger workflows, such as: - Pushing code - Opening or merging pull requests - Creating issues - Scheduled times - **Runners** are virtual machines that execute workflow jobs. GitHub offers Ubuntu, Windows, and macOS hosted runners, while teams can also use self-hosted runners. - **Jobs** contain groups of steps executed on the same runner. - **Steps** can either run shell commands or invoke reusable Marketplace actions. ## Workflow Structure Workflow files use YAML and live in `.github/workflows`. The three main sections are: - **`name`**: Describes the workflow. - **`on`**: Specifies the event or events that trigger it. - **`jobs`**: Defines the work performed after triggering. The post recommends descriptive filenames such as `build-and-test.yml`, `security-scanner.yml`, or `label-new-issue.yml`. ## Creating an Issue-Labeling Workflow The example workflow automatically adds a `triage` label whenever a new issue is opened. - It is named `Label New Issues`. - Its trigger is configured as: ```yaml on: issues: types: [opened] ``` - The `label-issues` job runs on `ubuntu-latest`. - Permissions are explicitly granted: - `issues: write` allows the workflow to add labels. - `contents: read` allows it to access repository content. ## Using Actions and Shell Commands The workflow contains two steps: - `actions/checkout@v6` uses a prebuilt Marketplace action to check out the repository code. - A shell command uses the GitHub CLI to add the label: ```bash gh issue edit "$ISSUE_NUMBER" --add-label "$LABEL" ``` Environment variables provide the command with: - `GITHUB_TOKEN` for authentication - The issue number from `github.event.issue.number` - The label name, `triage` The `uses` keyword invokes reusable actions, while `run` executes a shell command directly. Start with a small workflow in `.github/workflows`, define its trigger and required permissions carefully, and build from reusable actions plus simple commands. The post also recommends practicing with GitHub’s “Hello GitHub Actions” exercise to become familiar with workflow creation.

yamlci-cdgithubgithub-actions+2

githubMar 6, 2026

How to scan for vulnerabilities with GitHub Security Lab’s open source AI-powered framework (opens in new tab)

GitHub Security Lab’s open-source Taskflow Agent uses AI-driven, multi-step auditing workflows to find high-impact vulnerabilities in web applications and open-source projects. The authors report more than 80 vulnerabilities, including authorization bypasses and private-data disclosures, with about 20 already disclosed. They argue that carefully designed taskflows and prompts can give LLMs enough freedom to discover vulnerabilities while reducing hallucinations and false positives. ## Running the Audits - The taskflows are available in the [`seclab-taskflows`](https://github.com/GitHubSecurityLab/seclab-taskflows) repository. - To run an audit: 1. Start a Codespace for the repository. 2. Wait for initialization. 3. Run `./scripts/audit/run_audit.sh myorg/myrepo`. - Audits may take one or two hours on a medium-sized repository. - Results are stored in SQLite and can be inspected in the `audit_results` table. - Rows marked with a check in `has_vulnerability` indicate potential findings. - A GitHub Copilot license and premium model requests are required. - The same repository should be audited multiple times because LLM results are nondeterministic; using different models may reveal different vulnerabilities. - Private repositories require changes to the Codespace configuration to grant access. ## How Taskflows Work - Taskflows are YAML files defining ordered tasks and dependencies for an LLM. - The `seclab-taskflow-agent` runs tasks sequentially and passes their results between stages. - Repository audits begin by dividing the codebase into functional components. - For each component, context is gathered, including: - Untrusted-input entry points - Intended privilege levels - Component purposes and behavior - This context is stored in a database for later auditing tasks. - Separate tasks can: - Suggest generic security issues - Carefully verify each suggested issue - Focus on specific vulnerability classes - Tasks can be reused across many components asynchronously through templated prompts and component-specific substitutions. ## Why Use Multiple Tasks - A single large prompt is less reliable because LLMs may omit steps in complex, multi-stage investigations. - Taskflows help control, debug, and structure the process even when models provide large context windows. - Breaking work into stages allows each result to be reviewed and reused as context for subsequent analysis. - Repeated task execution across components makes the approach scalable for large repositories. ## General Security Auditing - The team initially used the framework to triage CodeQL alerts, where strict instructions and predefined criteria helped limit false positives. - General auditing is more difficult because the LLM must search broadly for vulnerabilities rather than evaluate known alerts. - Greater freedom increases the risk of hallucinations and unexploitable findings. - The authors’ approach uses taskflow design and prompt engineering to preserve a high true-positive rate while allowing the model to investigate diverse security issues. ## Reported Vulnerabilities - The taskflows have found more than 80 vulnerabilities in open-source projects. - Many reported issues are high-impact, including: - Authorization bypasses - Information disclosure - Logging in as another user - Accessing private user data - Examples include exposing personally identifiable information in ecommerce shopping carts and authenticating to a chat application with arbitrary passwords. - The authors manually verify findings before reporting them and maintain an advisories page as disclosures become public. The practical recommendation is to run the open-source taskflows on your own projects, repeat audits with different models, and manually validate every result. The framework is intended to improve through shared taskflows, prompts, and findings across the security community.

yamlllmopen-sourcegithub-copilot+4

datadogMar 4, 2026

Designing MCP tools for agents: Lessons from building Datadog's MCP server (opens in new tab)

Datadog’s initial MCP server simply exposed existing APIs, but real-world agent use revealed major problems with context limits, inaccurate trend analysis, and tool overload. The team redesigned its tools around token efficiency, query-based analysis, and a smaller, more deliberate tool surface. These changes improved both answer quality and cost, though emerging agent features may eventually reduce the need for some optimizations. ## Context Efficiency Matters - Observability results can be extremely large: a log record may range from roughly 100 characters to 1 MB. - CSV or TSV is more token-efficient than JSON for tabular data, often using about half as many tokens per record. - YAML can reduce token usage for nested data by around 20% compared with JSON. - Removing rarely used fields from default responses, while allowing agents to request them when needed, further reduces output size. - Combined formatting and field-trimming improvements allowed some tools to return approximately five times more records within the same token budget. - Pagination by record count is unreliable when records vary greatly in size. Datadog instead paginates by token budget and returns a cursor when the limit is reached. - Tools such as Cursor and Claude Code increasingly write long results to disk, which could make response-format efficiency less important in the future. ## Let Agents Query Data - Retrieval-only tools forced agents to infer trends from incomplete samples, such as guessing which services generated the most errors. - Agents sometimes repeatedly fetched logs to compensate, wasting tokens and producing unreliable answers. - SQL lets agents aggregate and filter data directly: ```sql SELECT service, COUNT(*) AS error_count FROM logs WHERE status = 'error' GROUP BY service ORDER BY error_count DESC LIMIT 10 ``` - Agents can select only necessary fields, limit row counts, and calculate aggregates without loading raw data. - SQL improved correctness and reduced costs; some evaluation scenarios became about 40% cheaper. - Supporting SQL at Datadog’s scale required significant infrastructure work because traditional relational databases were insufficient. ## Tools Are Not Free - Exposing every API endpoint as a separate tool increases tool-selection errors and consumes context through tool descriptions. - Flexible tools can support multiple related workflows through carefully designed schemas, reducing the total tool count. - Toolsets provide a core collection by default while allowing users to opt into specialized capabilities, though users must anticipate their needs. - Layered tools can first explain how to accomplish a task and then execute it, keeping specialized functionality out of the initial context. - Layering introduces additional tool calls and therefore increases latency. - Improving agent context management, including tool search and dynamically loaded skills, may reduce the need for aggressive tool minimization over time. The practical recommendation is to design MCP tools for how agents actually reason: minimize and control output size, provide query and aggregation capabilities instead of raw retrieval alone, and expose a focused set of flexible tools rather than mirroring every API endpoint.

yamldatabase-designdatadogobservability+4

githubFeb 5, 2026

Continuous AI in practice: What developers can automate today with agentic CI (opens in new tab)

Continuous AI extends CI into software-engineering tasks that require judgment, context, and interpretation rather than deterministic rules. It uses continuously running agents guided by natural-language instructions to review repositories, identify issues, and produce reviewable artifacts such as patches, issues, or reports. GitHub’s central argument is that AI should complement—not replace—traditional CI, while operating within explicit permissions and developer oversight. ## Why CI Isn’t Enough - CI is effective for binary, rule-based checks: - Tests pass or fail. - Builds succeed or fail. - Linters detect defined violations. - Many important engineering tasks depend on intent and context, including: - Finding discrepancies between documentation and implementation. - Detecting confusing accessibility text that passes linting. - Identifying behavioral changes caused by dependency updates. - Spotting subtle performance regressions, such as compiling a regular expression inside a loop. - Recognizing UI regressions that only appear during interaction. - GitHub describes this as a shift from AI-generated code toward AI handling cognitively demanding maintenance work. ## What Continuous AI Means - Continuous AI is a pattern, not a replacement for CI: - **Natural-language rules + agentic reasoning, executed continuously inside a repository.** - Developers describe expectations in natural language, especially when those expectations are difficult to encode with schemas, heuristics, or YAML. - Example workflows include: - Comparing documented behavior with implementation and proposing fixes. - Producing weekly reports on project activity, bug trends, and code churn. - Detecting performance regressions in critical paths. - Finding semantic regressions in user flows. - Workflows are refined collaboratively with agents by adding intent, constraints, and acceptable outputs rather than being authored as a perfect single instruction. ## Guardrails and Safe Outputs - Agents operate with read-only repository access by default. - They cannot modify content, create issues, or open pull requests unless explicitly authorized. - “Safe Outputs” defines the exact artifacts an agent may produce and the constraints governing them. - Agent activity is sanitized, logged, and auditable. - The goal is to keep the potential impact predictable even when agents make mistakes or behave unexpectedly. ## Natural Language Complements YAML - Deterministic problems should remain in CI, using YAML, schemas, tests, and heuristics. - Some expectations—such as determining whether documentation and code still express the same behavior—require semantic understanding. - Natural-language instructions let agents reason about intent without forcing that intent into brittle rules. - Continuous AI therefore expands automation into judgment-heavy tasks while preserving CI as the foundation for deterministic validation. ## Developers Remain in the Loop - Agents do not make unrestricted autonomous commits. - Depending on permissions, they can produce pull requests, issues, comments, discussions, or other reviewable artifacts. - Pull requests are especially useful because they fit existing developer review and collaboration practices. - The broader vision is to delegate recurring maintenance work while allowing developers to retain judgment, taste, and final control. Continuous AI is best adopted alongside traditional CI: use conventional automation wherever rules are sufficient, and use guarded, continuously running agents for tasks involving interpretation, synthesis, and evolving intent.

yamlai-agentgithubcode-review+3

gitlabJan 14, 2026

Understanding flows: Multi-agent workflows (opens in new tab)

The GitLab Duo Agent Platform introduces flows as a sophisticated orchestration layer that allows multiple specialized AI agents to collaborate on complex, multi-step developer workflows. Unlike standard interactive agents, flows are designed to work autonomously and asynchronously on GitLab’s platform compute, executing tasks ranging from initial requirement analysis to final merge request creation. This architecture enables teams to offload repetitive or high-compliance tasks to a background process that integrates directly with the existing GitLab ecosystem. ## Core Mechanics of Multi-Agent Flows * Flows function as event-driven systems triggered by specific actions such as @mentions, issue assignments, or being designated as a reviewer on a merge request. * Execution occurs on GitLab's platform compute, removing the need for users to maintain separate infrastructure for their automation logic. * While standard agents are interactive and synchronous, flows are designed to be autonomous, gathering context and making decisions across various project files and APIs without constant human intervention. * The system supports background processing, allowing developers to continue working on other tasks while the flow handles complex implementations or security audits. ## Foundational and Custom Flow Categories * Foundational flows are production-ready, general-purpose workflows maintained by GitLab and accessible through standard UI controls and IDE interfaces. * Custom flows are specialized workflows defined via YAML that allow teams to tailor AI behavior to unique organizational requirements, such as specific coding standards or regulatory compliance like PCI-DSS. * Custom flows utilize a YAML schema to define specific components, including "Routers" for logic steering and "Toolsets" that grant agents access to GitLab API functions. * Real-world applications for custom flows include automated security scanning, documentation generation, and complex dependency management across a project. ## Technical Configuration and Triggers * Flows are triggered through simple Git commands and UI actions, such as `/assign @flow-name` or `/assign_reviewer @flow-name`. * The configuration for a custom flow includes an "ambient" environment setting and defines specific `AgentComponents` that map to unique prompts and toolsets. * Toolsets provide agents with capabilities such as `get_repository_file`, `create_commit`, `create_merge_request`, and `blob_search`, enabling them to interact with the codebase programmatically. * YAML definitions also manage UI log events, allowing users to track agent progress through specific hooks like `on_tool_execution_success` or `on_agent_final_answer`. To maximize the value of the GitLab Duo Agent Platform, teams should identify repetitive compliance or boilerplate implementation tasks and codify them into custom flows. By defining precise prompts and toolsets within the YAML schema, organizations can ensure that AI-driven automation adheres to internal domain expertise and coding standards while maintaining a high level of transparency through integrated UI logging.

yamlai-agentgitlabreact+4