Fig Security

Fig Security is building a control and engineering layer for security operations rather than another endpoint, network, or threat-intelligence feed. Its official product positioning focuses on two causes of SecOps failure: unplanned drift, in which an upstream change silently breaks a detection or automation, and planned change, in which teams move cautiously because a rollout can reduce coverage or disrupt production. Fig says its platform can detect a broken security flow, trace the cause, suggest a repair, test it, and deploy it after approval. It also presents a workflow for modeling a planned change, checking its impact, deploying through version control, and rolling back when needed.

The underlying customer problem is credible and expensive. Detection-as-code is useful only when the parsers, data sources, routing, schemas, and downstream automations beneath a detection continue to work. In a modern hybrid or multi-cloud SOC, those dependencies are changed by infrastructure migrations, vendor updates, new telemetry, normalization work, and AI or automation initiatives. Fig’s proposed value is therefore operational continuity: preserving detection and response coverage while security teams change the stack. This is distinct from generic security posture management because the relevant unit is the functioning security workflow, not merely a configuration snapshot or list of vulnerabilities.

The initial market is enterprise security engineering and SOC teams with complex, heterogeneous tooling. The platform is intended to work across security infrastructure, including open-source components, and its messaging emphasizes reducing data plumbing, increasing coverage, and shipping changes faster with verification. That creates a potentially attractive wedge into teams that already spend heavily on SIEM, SOAR, detection engineering, and observability but still rely on scripts, tribal knowledge, and manual regression testing. The commercial challenge is that the product must integrate deeply enough to understand real data and control dependencies while remaining safe to operate in the customer’s most sensitive systems.

Fig emerged from stealth in March 2026 and public reporting describes $38 million raised across seed and Series A rounds, led by Team8 and Ten Eleven Ventures with experienced security-industry angels. The founders’ backgrounds at Google SecOps, Siemplify, and Cymulate are relevant to the problem, but public evidence does not establish recurring revenue, customer counts, retention, production scale, or independent security certifications. Customer testimonials displayed on the company site are useful market signals, including references attributed to security leaders at BNSF Railway, Netskope, Elastic, AppLovin, and a Fortune 500 pharmaceutical company, but they should not be treated as proof of paid deployments without diligence.

Competitive pressure comes from several directions. SIEM and SOAR vendors can add reliability, content-management, and automation features; detection-as-code and security-content vendors can own the development workflow; observability and data-pipeline platforms can expose upstream failures; and internal platform teams can build bespoke testing and rollback systems. Fig’s prospective edge is a cross-stack model of security-flow health combined with approval-gated repair and deployment. That edge will be durable only if the product has broad integrations, low false positives, strong change-impact analysis, and a measurable reduction in broken coverage and engineering toil.

The dual-use case is substantive but bounded. The same operational-resilience layer can protect commercial enterprises, regulated sectors, critical infrastructure operators, and defense-adjacent networks where a broken detection or response workflow can leave a mission-critical environment blind. It is not evidence of defense procurement or a defense-exclusive capability. Strategic relevance comes from making cyber defense more dependable under change: fewer silent coverage gaps, safer modernization, and better recovery from configuration or dependency failures. Diligence should therefore prioritize verified production outcomes, integration depth, data-handling architecture, deployment isolation, customer references, and evidence that automated repair remains explainable and reversible under pressure.