GitLab opens early access to agent that hunts business logic flaws

Why pattern scanners miss authorization flaws

GitLab starts from a point made by OWASP: broken object-level authorization ranks first on the OWASP API Security Top 10, and traditional static application security testing (SAST) tools struggle to find access control flaws. GitLab's explanation is that a missing authorization check is an absence of code, so a scanner that matches patterns has nothing to match.

The company gives three examples that most application security teams will recognize. An endpoint returns an order by ID without checking who owns it. A role field on a user profile accepts whatever JSON the client sends. A user ID is a sequential integer. Each is valid code that slips past most taint and pattern rules, because no untrusted data reaches a dangerous sink and no known-bad signature appears. Chained together, GitLab says, they give an attacker every customer's order and an administrator role.

GitLab also points to growing pressure. Across its customer base, codebase size has grown as much as 500% as agents write code, and CVE disclosures through April ran 46% above the February forecast from the Forum of Incident Response and Security Teams. Omer Azaria, vice president of Product Management at GitLab, said at GitLab Transcend: "We're caught in the middle: more code, faster attacks, same teams."

How the analyzer works

Business Logic Security Analyzer is a foundational flow on GitLab Duo Agent Platform. It targets business logic flaws, starting with broken object-level authorization, missing or improper authorization, and mass assignment. Practitioners can run a whole-repository scan, and each merge request can be scanned automatically after its pipeline passes.

GitLab says it scans the whole repository because many such flaws are not visible in a diff. Whether an endpoint should check ownership depends on the data model, the roles the application defines, and how other endpoints treat the same records. GitLab Duo Security Review already looks for authorization flaws in merge requests.

The analyzer first enumerates the application's entry points and maps who should be allowed to do what, such as which records belong to which user and which actions are administrative. It then reads each handler in scope and checks whether the rule is enforced before the record is touched.

Findings appear in the Vulnerability Report and the merge request security widget as first-class SAST results. In GitLab's demo application, the function refund_order takes an order_id from the request and sets refunded=1 without checking ownership or administrator status. Taint rules stay silent because the query is parameterized. The analyzer reports it as CWE-639, Critical, at app/orders.py:17, and explains that the ownership check is missing.

Models and the GitLab Security Standard

According to GitLab, the analyzer is the first GitLab capability to support Anthropic's Claude Mythos 5.1, available in early access to customers in approved environments. It also supports Claude Opus 5.5, Sonnet 5.5, Sonnet 5 and Sonnet 4.6, with more models planned. All run as GitLab-managed models through GitLab's AI gateway, under the same data handling terms as the rest of GitLab Duo Agent Platform. GitLab says the model sees only GitLab's prompts and the customer's repository.

The tool ties into the GitLab Security Standard introduced at Transcend: five stages each agent must clear to earn more autonomy. Its Verify stage requires every change, whether written by a person or an agent, to pass controls the author cannot touch. GitLab says the analyzer runs outside the author's hands and its findings persist in the same report and dashboards as the rest of the codebase.

What early access involves

Participants run the analyzer on their own codebases to find true positives their security teams did not already know about. GitLab says it will work with each team to learn where the analyzer is correct, wrong or silent.

Each scan consumes GitLab Credits, and cost scales with the size of the application's attack surface. Interested customers should contact their account team; those who are not yet customers can contact GitLab sales. Once a group is enabled, a whole-repository scan can be started from GitLab Duo Chat or through the API. Attaching the Business Logic scan profile to a project scans its merge requests. Prerequisites and setup are covered in the product documentation.