SoftTech AI Registry
GitLab · GitLab Duo Agent Platform

Security Review Flow

A manually initiated GitLab Duo Agent Platform foundational flow, in beta, that reviews a merge-request diff and its surrounding context for business-logic and authorization vulnerabilities. GitLab documents that it posts findings into the merge request as threaded diff comments with a CWE classification, severity rating, tier and explanation, can provide an inline suggested fix, replies within finding discussions when mentioned, and sets its own reviewer state, never setting Approve. Reviews are requested by assigning a dedicated Duo Security Review service account as a reviewer.

Recorded characteristics

Function
GitLab documents Security Review Flow as a GitLab Duo Agent Platform foundational flow that detects business-logic vulnerabilities in merge requests. GitLab states that, unlike static analysis tools that scan for known patterns, the flow reasons about the intent of the code and identifies vulnerabilities that emerge from incorrect assumptions about authorization, data exposure and control flow. When a review is requested, the flow analyses the merge-request diff and its surrounding context. Five security-analysis categories are documented: access-control review, identifying missing or misconfigured authorization checks on state-changing operations; authorization-gap detection, surfacing broken object-level and function-level authorization issues; business-logic analysis, detecting flaws in application workflows that could be exploited, such as race conditions in financial or stateful operations; information disclosure, identifying code paths that can leak sensitive data to unauthorized callers; and mass-assignment risk, flagging endpoints or models that can expose unintended fields to user input. These five categories are the documented scope and are not treated here as exhaustive vulnerability coverage. Findings are posted as threaded diff comments, each carrying a CWE classification, a severity rating, an explanation and, where possible, an inline suggested fix that can be applied with one action. The documented CWE identifiers are CWE-639 (broken object-level authorization / IDOR), CWE-862 (missing authorization), CWE-284 (improper access control), CWE-200 (exposure of sensitive information), CWE-840 (business-logic errors), CWE-915 (mass assignment) and CWE-362 (race conditions / time-of-check to time-of-use). Findings also carry a tier classification: Tier 1 (Exploitable), Tier 2 (Logic Flaw) or Tier 3 (Design Issue). When a user mentions the flow in a thread, GitLab documents that it reads the thread context and replies directly, without performing a full re-review. When the flow is reassigned as a reviewer it performs another review: it confirms fixes and resolves the corresponding thread, identifies additional required changes where a fix is incorrect or incomplete, leaves unaddressed findings open without comment, and creates new threads for new findings. This record covers the Security Review Flow only. Software Development Flow, Code Review Flow, the non-agentic GitLab Duo Code Review, SAST, GitLab Advanced SAST, agentic SAST vulnerability resolution, SAST false-positive detection, GitLab Duo Agentic Chat and generic GitLab Duo Agent Platform functionality are separate documented mechanisms and their behaviours are not attributed to this record.
Data access
The documented data accessed is the merge-request diff and its surrounding code context within the project under review, together with the merge-request discussion threads the flow reads when replying to a mention or performing another review. GitLab documents a bounded search and read budget for the analysis, so very large files or diffs might not be fully reviewed. Access is exercised through the dedicated Duo Security Review service account associated with the top-level group rather than through the initiating user's own identity, and no broader data access beyond the merge request and its project context is established for this flow.
Actions
Can take actions
External actions
No
Human confirmation
Conditional
Permission basis
Dedicated agent identity
Administrative control
Documented controls. Enablement is layered: GitLab Duo must be turned on, with GitLab Duo Core where no Pro or Enterprise add-on is present; the GitLab Duo Agent Platform must be turned on for the top-level group in GitLab 18.8 and later, or beta and experimental features turned on in GitLab 18.7 and earlier; flow execution must be allowed; foundational flows must be allowed; and Security Review must be turned on individually for the top-level group. GitLab documents these settings under the group's GitLab Duo configuration, with equivalent instance, group and project configuration for GitLab Self-Managed. Role requirements are documented: the Owner role for the top-level group configuration, the Maintainer or Owner role for project-level configuration, and the Developer, Maintainer or Owner role to request a review. Turning the flow on provisions the dedicated Duo Security Review service account for the top-level group. Model selection is a documented control, restricted for this flow to a specific supported set. GitLab Credits consumption is a documented commercial control. Controls documented for unrelated GitLab AI features are not attributed to this flow.
Default state
Conditional
Availability
GitLab documents Security Review Flow as beta, introduced in GitLab 19.1, on the Ultimate tier, with the offerings GitLab.com, GitLab Self-Managed and GitLab Dedicated. General availability is not documented. Prerequisites include the Developer, Maintainer or Owner role; foundational flows and Security Review turned on for the top-level group; GitLab Duo turned on, with GitLab Duo Core where no Pro or Enterprise add-on applies; instance configuration for GitLab Self-Managed; and the Agent Platform turned on for the top-level group in GitLab 18.8 and later, or beta and experimental features in GitLab 18.7 and earlier. During beta, reviews are always started manually.
Licensing
GitLab documents that Security Review Flow uses GitLab Credits each time it performs a review, and that credit usage scales with diff complexity and the selected model. GitLab publishes approximate examples for small, standard and large reviews; those figures are illustrative estimates in GitLab's documentation and are not recorded here as guaranteed costs. The documented tier is Ultimate.
External model or provider
GitLab's Agent Platform model documentation records the current default model for Security Review Flow as Claude Sonnet 4.6, and documents that this flow supports selecting Claude Sonnet 4.5 or Claude Sonnet 4.6, with other listed Claude models shown as unsupported for this flow. GitLab states that every GitLab Duo feature uses a default model, that GitLab might update default models to optimise performance, and that model changes come from the GitLab AI Gateway and take effect regardless of the GitLab version unless otherwise noted. Claude Sonnet 4.6 is therefore recorded as the currently documented default and expressly not as a permanently fixed model or provider. Applicability of GitLab Duo Self-Hosted models to this specific flow is not established and is not inherited from other GitLab flows.
Limitations and uncertainty
Recorded limitations and uncertainties. 1. Advisory output. GitLab states that Security Review Flow results are AI-generated and are advisory input, not an authoritative or complete security assessment. 2. Findings can include false positives and should be treated as input that needs human judgement, not as a final verdict. 3. The analysis works within a bounded search and read budget, so very large files or diffs might not be fully reviewed. 4. A review that reports no findings is not proof that the merge request is secure. 5. The flow complements but does not replace human security review, or other GitLab security tools such as SAST and GitLab Advanced SAST. 6. Vulnerability-report boundary: GitLab documents that findings are not tracked in the Vulnerability Report and do not count toward merge-request approval policies; these findings are therefore not formal GitLab vulnerability objects. 7. Remediation boundary: the flow generates a suggested fix, but the human applies the suggestion, commits it to another branch, resolves or dismisses findings, and creates issues from findings. GitLab does not document this flow autonomously committing, pushing or merging remediation code, and no such behaviour is attributed to it. 8. The role or permission level granted to the Duo Security Review service account is not publicly established in current documentation, nor is any inheritance of the initiating user's permissions. 9. GitLab documents composite identity generally for foundational flows using service accounts, but its exact application to Security Review Flow is not established and is not recorded here as a specific capability fact. 10. Self-hosted model applicability to this flow is not established. 11. Beta status means documented behaviour, including the manual-only initiation, may change.

Evidence