Today, we’re making Cloudflare CASB more powerful than ever by introducing automatic remediation policies. This means security teams can now design event-driven logic to revoke risky file shares and dispatch custom webhooks, without manual intervention. When we launched Cloudflare CASB , a cloud access security broker, we wanted to provide security teams complete visibility into the posture of their SaaS applications before misconfigurations became incidents.
With a quick, clientless integration, CASB surfaces risks like overshared files, dormant admin keys and tokens, OAuth apps with excessive permissions — continuously, across users in the organization. For years, SaaS Security Posture Management (SSPM) tools such as Cloudflare CASB have functioned as a passive alarm system. Most SSPM tools tell you what’s wrong but do not help you fix the issue, placing the burden on administrators to manage an ever-growing to-do list.
A single misconfigured file-sharing policy across a Google Workspace tenant can generate thousands of findings in seconds, and even a disciplined team faces a window between detection and remediation measured in hours or days — more than enough time for a sensitive file to be downloaded, forwarded, or indexed. With automatic remediation policies, CASB customers can now configure the actions that should be invoked immediately after a new finding is identified.
Shifting from reactive to proactive When we launched manual remediation actions earlier this year, we gave security teams the ability to resolve misconfigurations directly from the Cloudflare dashboard. This removed the need for customers to log in to multiple SaaS portals to take action on the security and content findings detected by Cloudflare CASB. Still, this required a human to confirm and initiate each individual remediation — even if they’d seen this exact finding type before.
CASB policies are a native automation engine built directly into Cloudflare One that takes action the moment a finding is detected. Security teams define their response logic once, whether that is revoking access to a file share, dispatching a webhook to your security operations center (SOC), or forwarding the event to a security orchestration, automation and response platform (SOAR).
The engine handles matches automatically by executing the customer-configured action. As an example, many organizations implement controls that prohibit files from being shared publicly. However, they may apply an exception to users and groups in their marketing department who are frequently required to collaborate with external parties.
SSPMs allow their customers to be alerted of any files that are shared publicly in violation of their policy. With many solutions, this permitted behavior lands in a queue with hundreds of possible violations, forcing administrators to take action on each individual instance. CASB policies are designed for exactly this scenario.
Rather than waiting for a human to see and act on a finding, automation fires the moment detection happens. The public share is revoked within minutes, keeping the backlog of findings clean and clear. How CASB policies work At their core, CASB policies are automated workflows that tell our scanning service what action to take when a new finding is detected.
From there, the configured policy will tell CASB to either trigger a remediation action, send a webhook, or both. This gives organizations the flexibility to rely on native CASB remediation capabilities or their own internal automation services and communication channels — without having to take action in disparate platforms or create their own event processing system.
How we built it The architecture behind CASB policies is built entirely on the Cloudflare developer platform — the same platform available to every Cloudflare customer. When a finding is detected, the findings engine enqueues an orchestration message to a Cloudflare Queue . A Worker consumer then checks whether a policy configuration matches the incoming finding.
If a match exists, it creates the corresponding job and hands it to the remediations pipeline, which runs on Cloudflare Workflows for durable, fault-tolerant execution. That means jobs survive process restarts and retries are handled automatically. Cloudflare Workflows also handle third-party API rate limits gracefully.
If a vendor returns a rate limit error, the Workflow pauses for the appropriate backoff window and retries without dropping the job. Our target from detection to completed remediation is five minutes or less. How to create policies To get started, navigate to the Cloudflare dashboard and create your first policy.
Policies can include both a remediation and a webhook action, but at a minimum: Select the vendor. Select the vendor and integration or tenant this policy should apply to. Select the integration.
You can hand-select specific integrations or set it to apply to all integrations for the selected vendor. Choose a finding type. Select the CASB finding type that should fire the policy.
Choose an action. Once a trigger is selected, the available actions for that finding type are shown. There are two categories: Run remediations.
First-party actions Cloudflare performs directly against the SaaS integration API. CASB currently supports remediation actions for Microsoft and Google Workspace file/folder finding types. Note that this may require upgrading permissions on integrations to read/write.
Send webhooks. Send finding details to configured webhook destinations such as Slack, Microsoft Teams, Jira, ServiceNow, Tines, or any custom HTTP endpoint your team uses. Example webhook format Maintaining visibility and compliance Each policy action produces two categories of logs, visible under Insights in Cloudflare One.
Admin Activity logs. These capture changes to a policy definition: who created it, who edited it, who disabled it, and when.
Originally published at blog.cloudflare.com
