PATTERN Cited by 1 source
Platform security at the application layer¶
Shape¶
Apply infrastructure-security techniques — continuous monitoring, sampling-based detection, centralized telemetry pipelines, rate-limited inspectors — to the application layer instead of restricting them to the network / OS / proxy layer. Treat application surfaces as infrastructure to be observed.
Named directly in Figma's post (Source: sources/2026-04-21-figma-visibility-at-scale-sensitive-data-exposure):
"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."
Why it's a mindset shift¶
Historically:
- InfraSec monitors flows, packets, syscalls, file-integrity — continuous, sampled, centralized. Think Cilium, Datadog CWP, eBPF kernel hooks.
- AppSec reviews code, writes unit tests, runs SAST/DAST, coordinates pentests + bug bounty — predominantly ahead-of-time / point-in-time checks.
The mindset shift: take the InfraSec continuous observability playbook and run it inside the app server, on its data flows.
Techniques borrowed from InfraSec¶
| InfraSec technique | App-layer analogue |
|---|---|
| Network-flow sampling | Response-body sampling |
| File-integrity monitoring | Schema-drift / unexpected-field detection |
| Centralized SIEM | Unified analytics warehouse for findings |
| Anomaly detection on traffic | Anomaly detection on response shape |
| Policy as code (firewall rules) | concepts/data-classification-tagging |
| Rate-limited packet inspection | Rate-limited response inspection |
| Two-environment defense (DMZ + internal) | Staging + production detection layers |
Concrete properties¶
- Continuous, not point-in-time. Runs on every production request (at sampled fraction), not just in CI.
- Centralized pipeline across services. Multiple application services post into the same detection backbone — unified schema, unified warehouse, unified triage. Figma's LiveGraph + monolith pattern.
- Non-blocking on the hot path. Detection errors degrade detection, never the product (patterns/async-middleware-inspection).
- Rate-limited. The detector itself can't be a DoS vector.
- Config-driven allowlists for intentional safe-exposure cases (patterns/dynamic-allowlist-for-safe-exposure) so alerts stay signal-dense.
- Security engineers ship code alongside product teams — from the post: "Our security engineers ship code alongside product and platform teams, bringing the same creativity and rigor to detection systems that we do to user-facing features."
When this beats adding another preventive gate¶
- Your preventive controls are already strong — adding another synchronous gate yields diminishing returns + latency cost.
- Your product + infra complexity is growing faster than review / test-coverage capacity.
- You need to catch regressions in already-shipped code, not just block new mistakes.
- You want to quantify what actually happens in production vs what the threat model assumed.
When prevention still wins¶
- Stakes are existential on a single miss (root credentials, payment execution) — detection after-the-fact is too late.
- The action is destructive + irreversible.
- The rule is cheap to express as a preventive gate (a type system, a required middleware, a DB CHECK constraint).
Prevention and detection compose; this pattern adds the detection leg to existing prevention, not a replacement.
Adoption hurdles¶
- Org structure: AppSec teams often don't own runtime pipelines. Detection-in-depth requires them to ship code in the app-server repo, own on-call triage, and operate data pipelines.
- FP rate management: early detection layers emit noise; teams that don't invest in dynamic allowlisting + triage workflows lose trust in the alerts fast.
- Performance discipline: tuning sampling rates + keeping async correctness takes engineering taste the same way p99 tail reduction does.
Example systems¶
- systems/figma-response-sampling — continuous detection of sensitive-data exposure at Figma's Ruby app layer.
- systems/datadog-workload-protection — parallel InfraSec-level pattern: eBPF-driven continuous kernel observability applied to workload behaviour.
- concepts/observability — the non-security sibling pattern (production-first introspection of application behaviour for reliability).
Seen in¶
- sources/2026-04-21-figma-visibility-at-scale-sensitive-data-exposure — the explicit framing of the mindset and its application to a production detection system.