I keep a small mental tally of merge requests where the static scanner shrugged and a human caught the actual bug. Not the SQL string concatenation. Not the hardcoded token. The one where the code was clean, well-typed, and quietly doing the wrong thing for the business, like updating a record the current user was never allowed to touch. That tally is longer than I would like.
That family of bugs is what GitLab says its new Security Review Flow is aimed at. The company moved the feature into public beta this week and positions it as a "foundational flow" on the GitLab Duo Agent Platform.
What actually landed
Security Review Flow is an AI review you request on a merge request. GitLab's framing is that you add Duo Security Review "the same way you would from a person": drop it in as a reviewer when your MR is ready and let it walk the diff.
The split GitLab draws against static scanners is fairly precise. Pattern-based tools are strong on the vulnerabilities they already know how to spot: unsanitized query inputs, hardcoded secrets, unsafe deserialization. What those tools struggle with is your application's logic, where perfectly valid code does the wrong thing for a given domain. GitLab says the new flow "traces intent rather than matching signatures," which is the usual AI-review pitch but tied here to a concrete list of targets.
That target list, per the announcement, includes broken object level authorization, function level authorization, missing authorization on state-changing operations, information disclosure through overly broad serialization, mass assignment, business logic errors, and race conditions. Anyone who has read the OWASP API Top 10 will recognise several of those as the "no scanner will ever find this for you" tier.
How it shows up in review
The shape of the interaction matters as much as the detection. Each finding comes with a vulnerability type plus a CWE reference, a severity level, a tier classification, a plain-language explanation, and, when the tool is confident enough, a suggested fix.
That is a friendlier surface than the usual "here is a JSON blob, please triage" security-tool experience. If it works, you get an authorization comment sitting in the same review thread, in the same UX, as the "did you mean to shadow this variable" note from a colleague. For a developer waiting on the pipeline, that is the difference between "I will look at findings when I have time" and "I fix this before I merge, because it is right there."
Where SAST still earns its keep
Nothing about this removes the case for pattern-based scanning. The SAST comfort zone (string handling, secrets, unsafe deserialization) is exactly where a fast, deterministic tool wins. You want that gate on every push, cheap and quiet, with a false-positive rate you can reason about.
What an intent-tracing review adds is a second pass that can catch a permission check missing from a state-changing endpoint. That is a different question and a different cost model. GitLab is asking for it in Duo Agent Platform credits per review, not per file per push, and the sensible read is that most teams will run both rather than pick one.
Open questions before I trust it on a merge button
A public beta review agent should earn its way in. A few honest things I want to know before I let it near a protected branch:
- Noise floor. Every LLM reviewer I have tried goes through a phase where every third comment is a plausible-sounding false positive on a code path that is fine. How does this one behave on a real, messy codebase?
- Repeatability. Ask the same review twice, do you get the same findings? A reviewer that drifts run to run is a bad gate.
- Scope of context. Does it read only the diff, or the surrounding files the diff depends on? Broken authorization checks live in call graphs, not single hunks.
The blog post does not close any of those, and public beta is where the answers will show up.
How to try it
Security Review Flow is in public beta for GitLab Ultimate customers on GitLab.com, Self-Managed and Dedicated. You reach it through a free trial of the Duo Agent Platform, or by enabling it on an existing Ultimate subscription that already has credits.
What I am watching next
Whether real teams start requesting Duo Security Review by default on merge requests, or whether it becomes another optional gate that quietly gets skipped when the pipeline is red and the standup is in ten minutes. That is the honest test of any review agent. I want to keep this one on for a sprint on a spare repo, count the findings that led to a fix, and report back. If you try it first, tell me what your false-positive rate looked like on day one, because that is the number that decides whether this stays on the reviewer list.
