Detection-as-Code Won on Paper and Lost in Production

Detection-as-code might be the most agreed-upon idea in security operations.

For nearly a decade it’s headlined conference talks, roadmaps, and vendor datasheets. Treat detections like software: version them, review them, test them, ship them through a pipeline. Nobody disagrees with it. But almost nobody does it. Here’s some thoughts on why, because the answer matters more right now than it ever has.

First, there’s “code.”

A detection is not a standalone thing. It sits on top of parsers, pipelines, log sources, and routing decisions, and it breaks when any of them move. SecOps engineers were never just writing detections. They were holding up the entire infrastructure beneath them. Detection-as-code put the top layer in git and let everything underneath drift. Version-controlling one layer of a five-layer system isn’t engineering. It’s decoration.

Second, there’s testing.

CI/CD earned its name because of the tests. Software engineers don’t merge on faith; the pipeline proves a change works before it ships. SecOps got the pipeline without the proof. There was no way to know what a change would do to your environment until it was in production, doing it. That isn’t CI/CD. It’s a faster way to ship unverified changes.

Third, there’s the walled garden.

Nearly every detection engine now claims detection-as-code, inside their platform, in their format, behind their walls. Your process becomes an extension of their product. The moment you want to add a tool or replace one, everything you built stays behind. That isn’t a methodology. It’s lock-in with better branding.

Fourth, the most important reason.

Detection-as-code was never democratized. The teams practicing it today are the biggest and best-resourced in the industry, because only they could afford to build what the concept was missing: the context, the test environments, the glue. Everyone else kept working the way they did ten years ago. Not because they disagreed, but because the idea shipped without the tooling. A practice only elite teams can afford isn’t a standard. It’s a luxury.

And now the stakes have changed. SecOps engineers are already building with AI, flying blind: no context about their environment, no way to test what comes out, no way to know it still works next week. AI is about to multiply the volume of change moving through every SOC while verification stays stuck at zero. That isn’t acceleration. It’s compounding risk.

Detection-as-code wasn’t wrong. It was never finished. The idea always needed a full engineering lifecycle behind it: every change designed with full context, proven before it hits production, and continuously verified after. No production leaps of faith. No more plumbing and pipefitting.

Fig. The full engineering lifecycle SecOps never had.

That’s what we built the Fig platform to deliver. It starts with security data lineage: a deterministic, ground-truth graph of every detection flow across the entire SecOps stack, because you can’t engineer what you can’t see. That foundation powers the first true CI/CD for SecOps. Every change is simulated and tested against your environment before it ships, deployed in a click with full version control and rollback, and monitored to confirm it keeps working, through your own changes and upstream drift alike. On any infrastructure. For every team, not just the biggest.

The result is what detection-as-code promised a decade ago: teams that move faster while coverage and resilience hold through every change. The promise was never the problem. In 2026, it finally gets kept.