## Background The Business Logic Security Analyzer (BLSA) is an AI-based CI/CD security analyzer for vulnerability classes that pattern-based and taint-based SAST structurally cannot express. A missing authorization check is not a pattern. It is the absence of something the code was supposed to do, which you can only detect if you already know what that endpoint was meant to enforce. BLSA scans whole repositories and merge requests, and writes findings into the Vulnerability Report as a first-class analyzer. That is what unlocks security policies, merge request approval policies, dashboards, and the compliance story. It is the delivery difference from the Security Review Flow, which comments on a merge request and cannot gate a merge. Prototype work is tracked in gitlab-org&22436. ### In scope Missing and incorrect authorization (CWE-862, 863, 639, 284, 285), TOCTOU and race conditions (CWE-362, 367), business logic flaws (CWE-840), improper authentication (CWE-287), the semantic residual of mass assignment (CWE-915), and logic-driven data exposure (CWE-200). --- ## Requirements ### 1. Coverage disclosure wherever partial scans are possible BLSA cost is bounded by allocation limits rather than by repository size, which means a scan can complete without having reviewed every file. On the repository we have studied most deeply, all 39 known vulnerabilities were in files that discovery reached, but only 10 were in files actually reviewed. The review budget discarded the rest. We are not going to hide that. Customers need to know what was and was not looked at, in every place they would reasonably ask. Every competitor in this category truncates too, and almost none of them say so. Our own comparison study found that several published business-logic detection numbers in this market are artifacts of capped or truncated runs, including two of ours that we found and corrected. #### BLSA introduces a scan state that does not exist yet The scan status model in gitlab-org&20944 defines consistent states across AST scanners: in-progress, complete, failed, not-applicable, and stale. It also defines a degraded state for a scan that "runs but produces incomplete output due to a configuration error, a version mismatch, or an analyzer issue." BLSA partial coverage is neither of those. It is not a fault, a misconfiguration, or a version mismatch. It is the intended behavior of a budgeted engine operating correctly. Reporting it as "complete" is misleading, and reporting it as "degraded" implies something went wrong. - [ ] Define a scan state for "completed, coverage intentionally partial" as an extension of the model in gitlab-org&20944, or confirm that the degraded state is extended to cover budget-bounded coverage with distinct labeling - [ ] The state must be distinguishable from a clean full-coverage scan, from a failure, and from a fault-driven degradation #### Disclosure surfaces - [ ] **Configuration profile.** Before a scan runs, the profile states what BLSA will and will not cover, including the budget limits that apply. - [ ] **Documentation.** Coverage limits are documented explicitly rather than implied, no language that implies completeness. - [ ] **Scan status surface (gitlab-org&20944).** Per scan, surface whether the run completed within budget or exhausted it, how many files discovery reached versus how many were actually reviewed, and which paths were skipped. Consistent with the status vocabulary and visual treatment being designed for all AST scanners rather than a BLSA-specific pattern. - [ ] **Scan Coverage visibility widget (gitlab-org&20944).** BLSA coverage data feeds the group and project level widget, so an AppSec engineer managing many projects sees BLSA coverage gaps without having to open individual scans. - [ ] **New analyzer announcement (gitlab-org&20944).** BLSA is a new analyzer, so its availability should surface through the in-product announcement pattern being designed there rather than only in release notes. This directly serves the success measure stated in gitlab-org&20944: security teams should never discover a scan failure, rollout error, or coverage gap by accident. BLSA is the first analyzer where a coverage gap is a routine outcome rather than an exception, so it is the hardest test of that model. ### 2. Platform integration as a first-class analyzer BLSA should behave exactly like SAST or SCA from the user's point of view, not like a bolted-on AI feature. Findings ride the existing scan completion path so the whole surface comes with it. - [ ] GitLab Security Report schema, with the business_logic analyzer type in the SAST family and its own scanner identity - [ ] Vulnerability Report, finding detail, dashboards and trends, CSV export, GraphQL, manual lifecycle - [ ] Scan execution policies and merge request approval policies - [ ] Security Inventory and Configuration Profiles recognition - [ ] Merge request security widget - [ ] Enabled and disabled state legible in Security Inventory and the project security configuration view, consistent with other scanners - [ ] Works in all deployment modes, or we document precisely which are supported and why ### 3. Cost prediction before a scan runs Consumption is driven by how wide the scanned application's attack surface is, not by repository size, and that is difficult to predict from metadata. Enterprises have told us repeatedly that predictability matters more than price (Mercedes-Benz, Hella, and E.ON). #### Predictability comes from projection With one effort setting at launch there is one expected cost distribution, so the projection function is doing all of the work. There is no tier for the customer to select as a cost control, which raises rather than lowers the bar on getting the projection right. - [ ] The shipped effort setting has a documented expected cost range, measured rather than estimated - [ ] A cost projection function: given repository or diff scope, return expected consumption * [ ] **On-demand scans:** show projected cost and require confirmation before the run starts * [ ] **Pipeline and scheduled scans:** show projected per-scan and projected monthly cost at configuration time, since there is no way to surface a confirmation inside a CI job - [ ] **Graceful degradation at the ceiling.** BLSA gates merges through approval policies, so suspending the analyzer at a consumption limit must not silently disable a security control or block every merge request in the group. ### 4. Pricing BLSA is likely the worst-affected flow in the portfolio under per-request billing. A whole-repo scan reuses the same system prompt and repository context across many sequential calls, which is a very high cache-hit profile, and cached savings are not currently passed through to customers. - [ ] Consumption unit and rate resolved, dependent on the move to token-based pricing - [ ] Expected pricing published internally with its cost basis and margin assumption stated - [ ] Credit consumption figures split by scan type, MR-scoped versus whole-repo **Expected pricing based on current measured cost.** Measured cost per scan is 9 to 26 USD on the External Agent lane and 53 to 67 USD on the Duo Agent Platform lane. These two figures use different accounting, different price constants, and carry different degrees of confidence. The External figure is a measurement reproduced from its own records and the Duo figure is an estimate, so the gap should be read as a direction rather than a ratio. All figures are at the lowest effort setting, which is the one that ships. On the External Agent lane at a 60% margin, that implies roughly 25 to 65 USD per whole-repository scan to the customer, varying with attack surface. The target to argue for is a rate that puts a median scan at 25 to 40 USD, with the top of the distribution disclosed rather than only the median. For external reference: Anthropic's Claude Code Review runs 15 to 25 USD per pull request, and Arnica's vendor cost calculator uses 250 USD as its whole-repo planning anchor. MR-scoped scanning has never been cost-measured, and the frequency math says that is the wrong half to know. A median SaaS Ultimate customer runs roughly 66 merge requests a month against perhaps four default-branch scans, so MR scanning would be the majority of what they actually pay. --- ## Target Metrics Structured as Pass and Fail criteria, consistent with the AI SAST experiment plan. If we meet Pass, we are affirmatively happy. If we meet Fail, we reconsider the approach. If the results are neither, we decide whether it looks promising enough to adjust and continue. ### Pass - [ ] Precision \>= 60% and recall \>= 40% - [ ] Findings contain useful context, explaining the specific instance rather than a static description per class - [ ] Findings are generally consistent across runs. Repeat scans of identical code produce substantially the same findings, measured as finding overlap \>= 80% across three identical runs - [ ] Merge request scan runtime \<= 10 minutes - [ ] Whole-repository scan runtime \<= 30 minutes - [ ] Cost is accounted for, and we have a cost model that leads to commercially reasonable customer pricing - [ ] We have a path to usage in all deployment types ### Fail - [ ] Precision \< 40% or recall \< 25% - [ ] Findings are too vague to act on - [ ] Findings vary materially between identical runs, with overlap \< 50% across three identical runs - [ ] Merge request scan runtime \>= 20 minutes - [ ] Whole-repository scan runtime \>= 60 minutes - [ ] There are no approaches that would lead to commercially reasonable costs - [ ] There are no approaches that would allow for usage in all deployment types --- ## Closed Beta Exit Criteria Adapted from the Security Review Flow beta (gitlab-org/gitlab#600301). BLSA runs on a schedule, so repeat scans are automatic and do not show that a customer values the results. Engagement is measured on what customers do with findings. 1. Requires at least 10 active beta customers. Active means the customer has a Business Logic scan profile attached to at least one project, a scheduled scan execution policy running against it, and at least one completed scan in the month. 2. Of those, at least 50% demonstrate engagement in two consecutive months, measured as any of the following in a given month: - A BLSA finding triaged in the Vulnerability Report (status set to confirmed, dismissed, or resolved) - A BLSA finding linked to an issue or closed by a merge request - A merge request approval policy that includes BLSA findings kept enabled, with at least one merge request evaluated against it 3. Requires a named customer quote. Telemetry needed to measure this: customers with a profile attached, completed scans per customer per month, findings triaged per customer per month, and credits consumed per customer per month. --- ## Dependencies - [ ] **Token-based pricing for the Duo Agent Platform: https://gitlab.com/gitlab-org/fulfillment/meta/-/work_items/3171.** BLSA release is gated on this. Today all flows are charged per LLM request rather than per token, so high cache-hit sessions pass none of the caching discount to customers. If this resolves in favor of passing savings through inside the current per-request model rather than moving to tokens, the pricing question re-opens entirely. - [ ] **Scan status and coverage UX: https://gitlab.com/groups/gitlab-org/-/work_items/20944.** BLSA needs the partial-coverage state, the scan status surface, the Scan Coverage widget, and the new analyzer announcement pattern. BLSA is the first analyzer for which partial coverage is a routine rather than exceptional outcome, so it should be represented in that design work rather than retrofitted afterwards. - [ ] **BLSA configuration profile.**