BLOG
Everything as Code: Bringing Software Engineering Discipline to Security Operations
Every engineering team at your company ships code through version control, peer review, automated tests, and CI/CD. Infrastructure changes go through Terraform. Pipeline updates go through YAML commits. Policy enforcement goes through OPA.
Then there's the security team. Detection rules get created in a SIEM GUI, deployed straight to production, and modified on the fly when something breaks. There's no Git history to revert to, no test suite to catch regressions, and no pull request trail explaining why a rule was changed at 2 AM during an incident. The numbers back this up: 69% of SOCs still rely on manual or mostly manual processes for core functions.
Security operations is the last major holdout in the "as code" movement, and the cost shows up in noisy alert queues, brittle detection logic, and institutional knowledge that doesn't survive team turnover.
This article explains how the everything-as-code philosophy evolved, why security operations got left behind, and how detection-as-code closes the gap by bringing Git, testing, and CI/CD to threat detection.
Key Takeaways:
Everything as code is a software engineering philosophy that treats infrastructure, configuration, pipelines, policies, and operational processes as version-controlled, testable, and continuously deployable code, not manual, GUI-driven tasks.
The "as code" pattern has expanded well beyond infrastructure; security operations remains a significant holdout, with 69% of SOCs still relying on manual processes.
Detection-as-code closes the gap by applying Git, peer review, automated testing, and CI/CD to threat detection rules; security teams get version history, rollback capabilities, and pre-production validation that GUI-based SIEMs struggle to provide.
Code-based security workflows enable teams to scale coverage without proportional headcount growth.
What Is Everything as Code?
Everything as code is a software engineering mindset that treats infrastructure, policies, testing, deployment, configuration, and monitoring as version-controlled, human-readable files. If you can define it, you define it as code. If you can automate it, you automate it. If you can review it, put it in Git.
Here's what separates everything as code from plain automation: it's not just about scripting manual tasks. It's about applying the full discipline of software engineering (version control, testing, peer review, CI/CD) to domains that were previously managed by hand. The list is long: source code management, test-driven development, continuous integration, refactoring, and peer review.
Two technical foundations make this work:
Declarative definitions describe the desired end state rather than procedural steps.
Idempotence ensures that applying the same change repeatedly results in the same outcome, which makes deployments safer and more predictable.
Where Everything as Code Started
The "as code" movement evolved over three decades, from early configuration management to cloud-native provisioning; each generation established patterns the next domain would adopt. This timeline matters because it explains why today's best practices look so similar across domains.
From Manual Infrastructure to Infrastructure as Code
Infrastructure as code evolved from manual server configuration through three waves: configuration management, cloud provisioning, and general-purpose programming.
The conceptual origin was CFEngine (1993), which introduced declarative, idempotent configuration management. Configuration management tools matured the space: Puppet with its declarative language, Chef with deterministic execution and cloud provisioning, and Ansible with its agentless SSH architecture.
Cloud provisioning changed everything. AWS CloudFormation introduced provisioning infrastructure itself as code. Terraform extended this to be cloud-agnostic, and Pulumi brought general-purpose languages like Python, Go, and TypeScript into infrastructure management.
The Expansion Beyond Infrastructure
Once teams saw how version control, testing, and CI/CD transformed infrastructure management, they applied the same pattern everywhere. GitOps emerged as the unifying framework: it uses Git repositories as the source of truth, pull requests as the change mechanism, and CI/CD as the enforcement layer.
GitOps is mostly discipline rather than tooling. The hard part isn't choosing a tool; it's building the habit of never touching the cluster manually again.
What are the Core "As Code" Practices?
Four "as code" domains form the foundation of modern DevOps, and each applies the same underlying principles: version control, peer review, automated testing, and declarative definitions. If you're trying to apply the same discipline to security operations, these domains are the reference model. The patterns repeat: define changes as code, validate them automatically, and promote them safely.
1. Configuration as Code
Configuration as code manages application and system settings through version-controlled, declarative definitions rather than manual changes. The twelve-factor methodology establishes the foundational principle: configuration is everything that varies between deploys, and it must be strictly separated from code.
In practice, this means environment variables, Kubernetes ConfigMaps, and externalized config files. Kubernetes ConfigMaps are explicitly designed to decouple configuration artifacts from image content, which makes configuration changes reviewable, auditable, and consistent across environments.
2. Pipeline as Code
Pipeline as code defines CI/CD pipelines in YAML files stored alongside application source code: .github/workflows/ for GitHub Actions, .gitlab-ci.yml for GitLab, .circleci/config.yml for CircleCI. Every pipeline change becomes a reviewable, versioned commit.
When security checks are embedded in version-controlled pipeline code, branch protection and required approvals can make bypassing those checks much harder, and every modification creates an audit trail. YAML pipelines are checked in and versioned like any other code, which means every pipeline change gets the same review and audit trail as application code.
3. Policy and Compliance as Code
Policy as code transforms manual governance into automated, version-controlled enforcement. Instead of reviewing configurations by hand, tools like Open Policy Agent (OPA) and HashiCorp Sentinel evaluate changes via policy evaluation and block non-compliant deployments before they reach production.
Compliance as code embeds policies, controls, and audits directly into your infrastructure and application code, providing continuous audit readiness with minimal overhead. In practice, security feedback moves from days (manual review) to seconds via an automated policy check.
4. Testing as Code
Testing as code applies software development testing practices to infrastructure validation. Frameworks like Terratest deploy and validate real infrastructure through the Terratest framework, then automatically clean up.
InSpec takes a compliance-focused approach, enabling teams to specify requirements using the InSpec language. Static analysis and policy checks can also be integrated into CI to catch misconfigurations earlier, before deployment rather than after.
The Missing Piece: Bringing "As Code" to Security Operations
Infrastructure, configuration, pipelines, policies, and testing all have well-established "as code" practices. Security operations is the significant outlier, and the gap is both quantifiable and structurally rooted. This section breaks down why many security teams still default to click-ops workflows, then shows how detection-as-code maps the same engineering controls onto detection rules.
Why Most Security Teams Still Rely on GUIs and Manual Processes
The "as code" pattern reached infrastructure, pipelines, configuration, and policy years ago. Security operations didn't follow, and the reasons are structural, not just technical. 76% of organizations cite security skill gaps as a barrier to security-as-code adoption, followed by tool integration challenges (68%) and perceived delivery delays (54%).
Three factors explain why the gap persists:
Skills mismatch. DevOps engineers already had programming competencies they could apply to infrastructure automation; IaC was a natural extension of existing skills. Security practitioners historically centered on monitoring, detection, and human analysis, making code-based workflows a fundamental skills pivot, not just a tool swap.
GUI-first tooling. No-code security platforms were intentionally designed to avoid requiring programming skills. This democratized access but perpetuated workflows that lack version control, testability, and reproducibility — the opposite of infrastructure-as-code's design philosophy.
Integration friction. Even organizations actively adopting secure pipelines report moderate CI/CD difficulty. Connecting security tooling to existing Git and CI/CD workflows remains harder than it should be.
These barriers aren't insurmountable. They just require a platform built from the ground up for code-based security workflows.
Detection-as-Code Brings Software Rigor to Threat Detection
Detection-as-code applies Git, peer review, automated testing, and CI/CD to threat detection logic — the same engineering workflow you already use for applications and infrastructure.
In most SIEM workflows, detection rules are created directly in production UIs with no version history, no regression testing, and no rollback path. When most SOCs still rely heavily on manual processes, broken rules stay broken longer and institutional knowledge walks out the door with every departure.
Panther was built to fix this. As a cloud-native SIEM paired with a security data lake (Panther's Security Data Lake), Panther lets teams write detection rules as Python, SQL, or YAML, store them in Git, test before deployment, and push to production through CI/CD pipelines.
Wolt's security team adopted this approach, with their Security Operations Lead noting: "Making changes with the integrated testing in Panther Analysis Tool makes it possible to be much more fearless with the changes."
Benefits of Applying Everything as Code to Security
The benefits of treating security operations as code aren't theoretical. They map directly to the operational challenges your team faces daily: compliance evidence, production reliability, and doing more with the same headcount. Three wins stand out:
1. Version Control and Audit Trails
Git provides a complete history of every detection rule change: who modified it, what changed, when, and why. When a detection rule starts generating excessive false positives, version control enables immediate reversion without losing broader detection context or requiring complete rule rewrites.
Pull request discussions become institutional knowledge, capturing not just the detection logic but the reasoning behind it. This context survives team turnover in a way that undocumented SIEM GUI changes rarely do.
Cockroach Labs' security team saw this play out directly. Python-based detection rules with version control replaced their click-ops workflows, cutting audit prep time by 85% across PCI, SOC 2, HIPAA, and ISO 27001, with 365 days of hot storage eliminating the auditor back-and-forth that previously consumed engineering hours.
2. Automated Testing and CI/CD for Detection Rules
A CI/CD pipeline for detection rules mirrors a software deployment pipeline: pull request workflows with peer review, automated testing triggered on every commit, staging deployment, and production promotion. Only tested, reviewed rules reach production.
Here's what that looks like in practice: you can validate rules against real or simulated attack data before deployment, verify that logic triggers on known attack patterns, and catch syntax errors and obvious false-positive issues before they generate volume in production. Panther supports this workflow natively.
Python detection rules can be tested with the Panther Analysis Tool, validated in CI/CD, and deployed on merge.
The trade-off is real: testing takes additional time per detection rule. But CI/CD automation amortizes that upfront cost across every future iteration. The first rule takes longer. The hundredth rule deploys in minutes with confidence.
3. Scalability Without Proportional Headcount
Code-based security workflows act as a capacity multiplier, with measured outcomes including 61% faster vulnerability remediation, 17x faster detection speed compared to manual reviews, and a 93% reduction in security misconfigurations through automated policy checking.
Automation handles the repetitive work so your security engineers focus on the work that actually requires human judgment:
Linting detection rules for basic quality issues
Running test suites on every change
Deploying validated changes through CI/CD
Enforcing policy checks before promotion to production
This is why automation typically increases capacity without requiring the team to scale linearly. Automation frees teams from mundane tasks so they can tackle higher-impact security work.
Panther is designed for this reality. Teams write detection rules in Python with full CI/CD integration, and Panther AI assists with alert triage, detection rule writing, and tuning. This shifts your team's time from manual firefighting to proactive threat hunting.
Treating Security Like Software Is the Path Forward
Security operations is the last major holdout in the "as code" movement, but the trajectory is clear. The operational constraints holding SOCs back are well-documented: heavy reliance on manual processes and lack of skilled staff remain the leading barriers to SOC excellence.
The starting point doesn't require a complete overhaul. Start with a small set of high-impact detection rules, especially the noisy ones generating the most false positives, and build the workflow that makes changes safe and repeatable:
Store rules in Git so you have history, context, and rollbacks.
Add peer review through pull requests.
Write basic tests that validate expected behavior.
Set up CI/CD so only reviewed, tested changes deploy.
From there, everything else follows: audit trails, rollback capability, collaborative review, and the confidence to iterate quickly.
Panther makes this practical for lean security teams. As a cloud-native SIEM built on a security data lake (the Security Data Lake), Panther lets you write detection rules in Python, test them before deployment, deploy through CI/CD, and use Panther AI to assist with triage and tuning. Your detection logic deserves the same engineering discipline as your application code.
Git, tests, peer review, CI/CD — security teams that adopt these practices get the same reliability and velocity that software teams already take for granted.
Share:
RESOURCES
