# Cloudflare CASB adds custom finding types written in Rego

Cloudflare One administrators can now define their own CASB detection logic in Rego, scope it to a provider and asset class, validate it before saving, and route matches into existing remediation policies.

Canonical URL: https://freelancenews.online/news/cloudflare-casb-adds-custom-finding-types-written-in-rego-cdb82344
Published: 2026-10-07T20:17:29.263Z
Updated: 2026-10-07T20:17:29.263Z
Source published: 2026-10-05T00:00:00.000Z
Event date: Not established
Review status: source-reviewed
Review method: Automated comparison against retrieved source text; not independent fact-checking.

## Report

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.

## Key points

- Custom finding types let Cloudflare One administrators define CASB detection logic in Rego, the policy language from Open Policy Agent.
- Each custom finding type is scoped to a provider and an asset class, and can target all integrations for that provider or a selected subset.
- A built-in Validate step checks expressions for syntax errors and schema issues before the finding type is created.
- Standard finding types can be opened to inspect their detection logic and duplicated as a starting point for a custom type.
- Custom finding types integrate with CASB remediation policies, so matches can be routed to Slack, ServiceNow or other webhook destinations.

## Practical implications — editorial interpretation

Editorial interpretation: freelancers and consultants who administer Cloudflare One tenants for clients can encode client-specific security rules as reusable, scoped policies instead of checking configurations by hand, and can start from Cloudflare's own standard finding logic rather than authoring Rego from nothing. The cost is that detection accuracy becomes the author's responsibility, and the source documents no way to test an expression against historical data before enabling it.

## Limitations and unknowns

The evidence is a single vendor changelog. It gives no pricing, plan tier, regional availability or rollout stage, and does not state whether the feature is generally available. It names only two providers and three asset classes as examples, without listing the full supported set. No benchmarks, false-positive rates or independent testing are provided, and the higher-confidence framing is Cloudflare's stated intent. The exact date the feature became available is not specified, so no event date is asserted.

## Sources

- [1] developers.cloudflare.com: Changelog
  https://developers.cloudflare.com/changelog/post/2026-10-05-casb-custom-findings/
  Retrieved: 2026-10-07T20:17:02.466Z

## Claim references

- Cloudflare CASB now supports custom finding types that let security teams define their own detection conditions. [source 1]
- Custom detection logic is written in Rego, the open-source policy language from Open Policy Agent. [source 1]
- A custom finding type is scoped to a provider and an asset class, and can be applied to all integrations for that provider or a selected subset. [source 1]
- A built-in Validate option checks the expression for syntax errors and schema issues before the finding type is created. [source 1]
- Standard finding types can be opened to view their detection logic and duplicated as a starting point for a custom finding type. [source 1]
- Custom finding types can be used in CASB remediation policies to send matching findings to Slack, ServiceNow or other webhook destinations. [source 1]
- CASB evaluates a custom finding type against assets as they are created or updated within the selected scope, with matches appearing as posture finding instances. [source 1]