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.
Editorial analysis by NHI Mgmt Group, 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.
Key questions
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: Why does detection-as-code improve auditability and operational resilience?
A: Because every change becomes a traceable artifact with commit history, review context, and test evidence.
A: Detection engineering is working when alerts and logs perform consistently across locations, zones, and subsidiaries, and when teams can prove that signals reach the SIEM and incident responders on time.
Practitioner guidance
- Move detection logic into version control Store detection rules in Git so every change has history, review context, and a reversible commit trail instead of living only in the SIEM UI.
- Require peer review for rule changes Use pull requests and approval workflows for detections that can affect production alerting, especially where the rule change could create false positives or blind spots.
- Add automated tests for detections Validate rules against known benign and malicious event patterns before promotion so syntax errors and logic regressions are caught before they reach production.
Bottom line: Detection-as-code replaces ad hoc SIEM editing with governed, testable change management for threat detection.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:54 pm
Detection-as-code is a governance model, not just a tooling choice. The important shift is that detection logic becomes reviewable, testable, and reversible in the same way software changes are. That closes a long-standing operations gap where security outcomes depend on undocumented GUI edits and individual operator memory. For practitioners, the message is to govern detections as release-managed security artefacts, not ad hoc dashboard settings.
A few things that frame the scale:
- 96% of security operations teams report critical blind spots, most commonly in cloud infrastructure (74%) and identity and access behaviour (67%).
A question worth separating out:
Q: Should SOC teams prioritise version control or automation first for detections?
A: Version control should come first because it establishes traceability and review discipline before automation accelerates change. Once detections are in Git, automated tests and CI/CD can safely build on that foundation. Without source-of-truth control, automation can simply make bad changes happen faster.
👉 Read our full editorial: Detection-as-code is closing the security operations gap