Buying a shared web service also means buying its incident-response structure. Cloudflare said its global teams handed work between offices during the February 2017 memory incident, with initial mitigation in 47 minutes. That is an operator-reported response interval, not an independent benchmark or a guarantee for the next fault. It nevertheless identifies a capability a buyer can ask a provider to explain. [cf]

The same shared infrastructure carried a different implication. Cloudflare said a request to one vulnerable site could reveal information belonging to another, unrelated site using its service. A customer therefore could not assess the potential boundary of exposure solely by examining its own pages. Centralized intervention and cross-customer exposure belong in the same procurement discussion; neither cancels the other. [cf]

Bitsight’s February 24 analysis described a way its customers could identify monitored companies using Cloudflare and inspect potentially affected websites, addresses and domains. This was a vendor-described discovery capability, not a confirmed breach list. For buyers, it raises a useful information question: can the supplier explain the relevant shared dependencies, or must the customer assemble that picture from several sources? [bitsight]

Our proposed comparison asks providers for evidence of both control speed and isolation boundaries. Record who can stop a faulty feature, how that action is confirmed and which customer data share the processing path. Then ask what dependency information the buyer receives. The incident supports examining those trade-offs, not declaring outsourcing superior or inferior. Prices, switching costs and losses would require separate evidence before turning this architectural comparison into an economic verdict. [cf][bitsight]

Source documents

  1. Last Friday,https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/
  2. Cloudbleed: Breakdown of Cloudflare's Memory Leakhttps://www.bitsight.com/blog/cloudbleed-breakdown-of-cloudflares-memory-leak