Cloudflareは10月5日にCASBのカスタム検出タイプ（custom finding types）を発表した。CASBはSaaSやクラウドアプリの設定リスクをAPI経由で点検するツールだ。
カスタム検出タイプは、OPA（Open Policy Agent）のポリシー言語Regoで組織固有の条件をルールとして書く機能だ。標準の検出タイプでは表せない例外や基準を扱う。
運用で残る問いは、新しいルールが既存アセットについての根拠をいつから生むかだ。ルールを保存した時点と点検が実際に終わった時点は同じではない。
作成・更新イベントでのみ行われる評価
ドキュメントは、Regoルールをプロバイダー、アセットクラス、選択した連携（integration）範囲に適用すると説明する。
評価はアセットが作成または更新されたときに行われる。ルールを新しく作っても、その後変わっていない既存アセットは遡って評価されない。
ドキュメントの例では、日曜に外部メンバーを許可したboardグループは、月曜にルールを作っても検出されなかった。水曜にメンバーが追加されてグループが変更されたとき、初めて評価され検出結果が生まれた。
この機能は態勢（posture）検出用だ。カスタムのデータ損失防止（DLP）コンテンツ検出には対応しない。
空の検出リストが示す二つの状態
望ましくない共有設定を探すルールを追加しても古いアセットが変わらないままなら、検出リストにないことは二通りに読める。
アセットがポリシーを満たしているのかもしれないし、まだこのルールの評価経路に入っていないのかもしれない。二つの場合では対応が異なる。
そのため、点検対象のアセット一覧と、関連イベントを経て実際に評価されたアセットを分けて記録するやり方が役に立つ。
ルールの有効化は設定状態であり、既知の例の検出は一つの経路の観察結果だ。二つを一つの正常表示にまとめると、カスタムルールで埋めようとした隙間が再び隠れる。
注意点：検証の通過、隔離、複製
Validateは式をコンパイルしてアセットスキーマと照合するだけで、アセットデータでは実行しない。
そのため検証を通過したルールでも、後で隔離（quarantine）されることがある。隔離中は既存の検出結果だけが残り、新しい検出結果は生まれず、このルールを使うポリシーも作動しない。
作成後に変更できるフィールドは名前、説明、連携範囲だけだ。ロジックや重大度を変えるにはルールを複製して新しいルールを作る必要がある。
アカウント当たり250個、連携一つ当たり25個という上限もあり、隔離されたルールもこの数に含まれる。
評価経路を確かめる試験範囲
初めて導入するときは、許可された小さな試験範囲に、検出されるべき例と検出されるべきでない例をそろえる構成が有効だ。
ドキュメントが示す確認場所はPosture FindingsのInstances列だ。関連イベントの後に予想した結果が出るかに加え、ルールに隔離の表示が付いていないかも見る。
変化のない過去のアセットまで点検が必要なら、対応する評価経路ができるまでその空白を明記しておくのが正確だ。ダッシュボードを埋めるために本番アセットを変えることは点検ではない。
複製で作った代替ルールも新しいデプロイ判断だ。変えたロジック、適用範囲、動作の根拠を残さなければ、有効なルールを何度も作った事実が途切れのない点検のように見えてしまう。
静かな検出リストは、どのアセットが実際に評価の機会を経たかを説明できるときにだけ根拠になる。