Over the last few months we have spent a lot of time on why we are staying independent. This is what we learned.
What we changed
We moved the decision from a single threshold to a continuous score, added an explanation to every decision and made every rule testable against historical traffic before it goes live.
The result is fewer late-night pages for our analysts and — more importantly — fewer real users challenged by mistake.
Testing in production, safely
Every rule starts in log mode. We replay the previous seven days of traffic through it and show exactly which requests it would have affected before anyone can promote it to challenge or block.
This one feature has prevented more incidents than any detection we have ever shipped.
Observability first
Every mitigation decision is logged with its reasons, and every log line can be traced to the rule and score components that produced it. When a customer asks why a request was challenged, the answer is a link, not a guess.
Logs stream to the customer’s SIEM within seconds, which also means their security team sees attacks in the same tools they use for everything else.
Latency budget
Our budget for the whole filtering pipeline is one millisecond at the 99th percentile. Anything that cannot be decided within that budget runs asynchronously and influences the next request from the same client, not the current one.
That constraint shapes everything: data structures, where state lives and which signals we are willing to compute inline.
{ "match": { "path": "/api/v1/checkout", "risk": ">= 57" }, "action": "challenge" }
The full incident data behind this post is available to customers in the dashboard under Reports.
Interesting that most attacks are under ten minutes. Our experience is similar.
We moved from a scrubbing provider to always-on last year; time to mitigation went from minutes to basically nothing.
We moved from a scrubbing provider to always-on last year; time to mitigation went from minutes to basically nothing.
Carpet bombing is nasty. Good to see a clear explanation of it.
Do you publish the edge IP ranges in a machine-readable format?
Any plans to support per-tenant limits keyed on a JWT claim?
Do you publish the edge IP ranges in a machine-readable format?
Carpet bombing is nasty. Good to see a clear explanation of it.
Our auditors asked for exactly this kind of incident evidence under DORA.