Notifications
Clear all
Topic starter
02/08/2026 11:43 am
TL;DR: Security operations remains a manual holdout, with 69% of SOCs still relying on manual or mostly manual processes for core functions, and the result is brittle detection logic, noisy alert queues, and weak auditability, according to Panther. Treating detections as code shifts security work toward version control, testing, and CI/CD, making rule changes safer and more reproducible.
NHIMG editorial — based on content published by Panther: Everything as Code: Bringing Software Engineering Discipline to Security Operations
By the numbers:
- 69% of SOCs still rely on manual or mostly manual processes for core functions.
- 76% of organizations cite security skill gaps as a barrier to security-as-code adoption.
- 85% of organizations lack full visibility into third-party vendors connected via OAuth apps.
Questions worth separating out
Q: How should security teams implement detection-as-code in a SOC environment?
A: Start by moving high-value detection logic into Git, then add peer review, test cases, and a promotion pipeline before allowing production deployment.
Q: What breaks when detection rules are edited directly in SIEM consoles?
A: Direct SIEM edits remove version history, weaken review discipline, and make rollback difficult when a rule misbehaves.
Q: How do security teams know detection-as-code is actually working?
A: Look for fewer untracked production edits, faster safe deployment of rule changes, and test results that show known threats trigger as expected before rollout.
Practitioner guidance
- Move detection rules into version control Store every high-value detection rule in Git so changes, reviewers, and rationale are preserved across incidents and audits.
- Add automated tests for core detections Create test cases that validate expected matches, known false positives, and basic syntax before a rule is promoted.
- Enforce peer review before production changes Require pull request approval for detection logic, with explicit review of the detection intent, expected data sources, and rollback path.
What's in the full article
Panther's full article covers the operational detail this post intentionally leaves for the source:
- Example detection-as-code workflow patterns for SOC teams moving from GUI edits to Git-based change control
- Implementation detail on Python, SQL, and YAML rule authoring in a security data lake environment
- How peer review, testing, and CI/CD are wired into detection rule promotion and rollback
- Customer-specific examples showing how teams operationalised code-based detection management
👉 Read Panther's analysis of detection-as-code for security operations →
Detection-as-code: what it means for SOC teams now?
Explore further
02/08/2026 12:54 pm
Detection-as-code is really a governance model for security operations, not just a tooling pattern. The core change is that detection logic becomes reviewable, testable, and reversible in the same way infrastructure code already is. That shifts SOC operations away from click-driven edits toward controlled change management, which is the only durable way to preserve trust in a control that changes every day. For practitioners, the lesson is to govern detections as production policy, not as ad hoc content.
A question worth separating out:
Q: What is the difference between manual detection management and detection-as-code?
A: Manual detection management treats rules like mutable operational content, usually edited in a console with limited traceability. Detection-as-code treats rules like software, with Git history, automated validation, and controlled deployment. The distinction matters because the second model gives teams repeatability and governance evidence, while the first often depends on memory and informal process.
👉 Read our full editorial: Detection-as-code is closing the security operations gap
