Cloudflare has added custom finding types to the CASB capability inside Cloudflare One, according to a changelog entry on the company's developer documentation site. The change means security teams are no longer limited to the vendor's built-in library of finding types when deciding what CASB should flag across connected SaaS and cloud integrations.
The detection language is Rego, described in the source as the open-source policy language from Open Policy Agent (OPA). Cloudflare states that Rego expressions are evaluated against asset data drawn from a customer's connected integrations, so the conditions that produce a finding are authored by the customer rather than shipped by Cloudflare.
Scope is set along two axes. A custom finding type is tied to a provider — the changelog names Google Workspace and Microsoft 365 as examples — and to an asset class such as users, files or groups. From there it can be applied to every integration for that provider or to a selected subset.
Cloudflare frames the purpose as matching an organization's own thresholds and exceptions. The single concrete example in the source is flagging admin accounts that lack two-factor authentication. The company also describes the result as higher-confidence findings to act on; that is Cloudflare's stated intent, not a measured outcome, and the changelog supplies no benchmark or false-positive data behind it.
The authoring workflow runs through Cloudflare One. Administrators go to Cloud & SaaS findings, then the Findings library, and select Create finding. They enter a name, description and severity, choose a provider and asset class, set the integration scope, and write the Rego expression.
A validation step is built into that flow. Selecting Validate checks the expression for syntax errors and schema issues before the finding type is created. The source does not describe any further testing capability, so what validation confirms is that an expression is well-formed and schema-consistent, not that it detects what its author intended.
Cloudflare also exposes the logic behind its standard finding types. An administrator can open any standard finding type, view its detection logic, and duplicate it as the starting point for a custom one. The changelog presents this as a way to begin from existing logic rather than authoring Rego from nothing.
Rather than a one-off scan, evaluation happens continuously. The changelog states that, within the selected scope, assets are checked by CASB against a custom finding type whenever those assets are created or updated; assets that match then show up under Posture Findings as posture finding instances.
Custom finding types are not isolated from the rest of the product's response machinery. Cloudflare says they work with CASB remediation policies, so a matching finding can be sent to Slack, ServiceNow or any other webhook destination through the same policy path used for standard findings.
For developers and technical freelancers who administer client tenants, the practical value is the ability to encode a client's specific rule — for instance, a particular admin configuration the client cares about — as a repeatable, scoped policy rather than a manual review. Because scope is set per provider and per asset class, the same approach can be reused across tenants that share a baseline, while tenants with different baselines get their own expressions.
The tradeoff is that detection quality now rests with the author. Rego is a general-purpose policy language, and the source describes no library of pre-written custom expressions, no simulation against historical asset data, and no testing harness beyond the syntax and schema check. Teams without Rego experience are left depending on the standard finding types Cloudflare exposes for duplication and adaptation.
There is also an operational dimension the changelog does not address. Because custom finding types are evaluated as assets change, an expression scoped across all integrations for a provider could produce a continuing stream of posture findings. The source offers no guidance on tuning, suppression or volume management specific to custom types.
Availability is stated plainly: CASB custom finding types are now available in Cloudflare One. The changelog does not mention pricing, plan tier requirements, regional restrictions or a phased rollout, and it does not say whether the feature is generally available or in a preview stage.
The changelog's publication date should not be read as a confirmed release date. The source describes the capability as available but does not specify the exact day it became usable in accounts, so the precise event date cannot be established from the supplied material.
Several questions remain open. The source does not say how many providers or asset classes are supported beyond the two providers and three asset classes it names as examples, whether Rego policies can reference external data, how expression size or evaluation time is bounded, or what happens to existing finding instances if a custom finding type is later edited or deleted.
For this audience, the reasonable reading is that Cloudflare has moved CASB from a fixed rule set to an extensible one, and the extension point is a language many infrastructure and platform engineers already meet through OPA. That lowers the barrier for teams already using OPA elsewhere, while leaving teams without Rego experience reliant on duplicating and adapting the standard finding types Cloudflare exposes.
The change is worth tracking for anyone who manages Cloudflare One for clients, but it should be treated as a capability announcement rather than a demonstrated improvement in detection quality. The source provides no benchmarks, no false-positive data and no independent evaluation, and the higher-confidence framing is Cloudflare's own description of intent.