Skip to content

CONCEPT Cited by 1 source

Detection-in-depth

What it is

Detection-in-depth is the security posture of layering continuous detection on top of preventive controls, so that when (not if) prevention misses a class of bug, detection catches it before the impact compounds. A specialization of the classical defense-in-depth principle oriented around observing actual behaviour in production rather than adding another gate.

Motivating argument

From Figma's post (Source: sources/2026-04-21-figma-visibility-at-scale-sensitive-data-exposure):

"But preventive measures and testing alone can't catch every edge case. As our products and infrastructure have grown in complexity, the risk of subtle oversights or unexpected data flows has naturally increased. Even well-designed systems can produce surprises when services interact in new ways or when existing paths behave differently than expected."

Three combinatorial forces defeat pure prevention:

  1. Service composition at runtime produces call graphs that nobody reviewed end-to-end.
  2. Schema drift — new columns, new fields, new response shapes — exceeds the reviewer's ability to re-audit every endpoint.
  3. Legacy paths — rarely-exercised code routes continue to exist but fall out of the review / testing coverage over time.

Prevention vs detection (complementary, not substitute)

Prevention Detection
When it runs Before / during request After / during request
Failure mode Gate blocks the request Alert surfaces the leak
Coverage What the gate knows about What actually happens in prod
Latency cost Synchronous — on the hot path Async — off the hot path
Examples AuthZ DSL, unit tests, code review Response sampling, audit logs, anomaly detection

The two are complementary: prevention handles the known; detection handles the unknown-unknowns.

Canonical properties of good detection-in-depth

From Figma's stated goals, generalizing:

  1. Continuous — runs on production traffic, not just test fixtures.
  2. Broad coverage — applies across diverse parts of the product, not just one endpoint.
  3. Actionable — surfaces specific incidents engineers can investigate and fix, not just aggregate health metrics.
  4. Early — active in staging to catch issues before prod.
  5. Layered across environments — staging + production, two lines of defense.
  6. Non-blocking — detection never blocks the user-facing path, so detection errors degrade detection (not the product).

The platform-security mindset

A related framing from Figma's post:

"We approached this problem with a platform-security mindset — treating our application surfaces like infrastructure and layering continuous monitoring and detection controls on top. By applying techniques typically reserved for lower-level systems to our application layer, we were able to gain continuous visibility into how data moves through our products, without slowing development."

Techniques that AppSec teams can borrow from infrastructure security:

  • Sampling-based continuous monitoring (replace DPI with response-body sampling).
  • Anomaly-based detection (baseline the normal response shape per endpoint; alert on novel fields).
  • Centralized detection pipeline that many application services post into (unified warehouse + triage, cf. patterns/platform-security-at-application-layer).
  • Rate limiting on the detection pipeline itself (protecting the monitors from the thing they monitor).

Examples across the wiki

Seen in

Last updated · 200 distilled / 1,178 read