Cloudflare announced CASB custom finding types on October 5. CASB is a tool that checks SaaS and cloud apps for configuration risk through their APIs.

Custom finding types let teams write organization-specific conditions as rules in Rego, the policy language of OPA (Open Policy Agent). They carry exceptions and thresholds that the standard finding types cannot express.

The operational question is when a new rule starts producing evidence about existing assets. The moment a rule is saved and the moment checking is complete are not the same.

Evaluation only on create and update events

The documentation says a Rego rule applies to a provider, an asset class and a selected integration scope.

Evaluation happens when an asset is created or updated. A new rule does not retroactively evaluate existing assets that have not changed since.

In the documentation’s example, a board group that allowed external members on Sunday was not flagged when the rule was created on Monday. Only when a member was added on Wednesday, changing the group, was it evaluated and a finding created.

The feature is for posture detection. It does not support custom data loss prevention (DLP) content detection.

Two states behind an empty findings list

If a rule for unwanted sharing settings is added while old assets stay unchanged, their absence from the findings list can be read two ways.

The asset may satisfy the policy, or it may not yet have entered this rule’s evaluation path. The two cases call for different responses.

That is why recording the assets in scope separately from the assets actually evaluated after a relevant event is useful.

Rule activation is a configuration state, and detecting a known example is an observation of one path. Merging them into one healthy indicator hides the gap the custom rule was meant to close.

Caveats: passing validation, quarantine and duplication

Validate compiles the expression and checks it against the asset schema, but does not run it against asset data.

So a rule that passed validation can later be quarantined. While quarantined, only existing findings remain, no new findings are created, and policies using the rule do not trigger.

After creation, only the name, description and integration scope can be edited. Changing logic or severity requires duplicating the rule into a new one.

There are limits of 250 per account and 25 per integration, and quarantined rules still count toward them.

A test scope that confirms the evaluation path

For a first rollout, a small authorized test scope holding examples that should and should not be flagged is a workable setup.

The documentation points to the Instances column in Posture Findings. Alongside whether expected results appear after relevant events, the check includes whether the rule carries a quarantine marker.

If unchanged historical assets also need checking, stating that gap until a supported evaluation path exists is the accurate position. Changing production assets to fill a dashboard is not checking.

A replacement rule made by duplication is also a new deployment decision. Without a record of the changed logic, scope and supporting evidence, creating valid rules several times looks like uninterrupted checking.

A quiet findings list counts as evidence only when it can explain which assets actually had a chance to be evaluated.