What features should I look for in a Detection as Code platform?

Summary

• Detection as Code treats security detections like software: version-controlled, peer-reviewed, and tested and deployed through CI/CD rather than hand-authored in a console.
• Key features to look for: detections stored as code in version control; automated CI/CD testing and deployment; coverage over large-scale, normalized telemetry; flexible scheduling; and reliable alerting to your existing channels.
• An open data foundation matters: decoupling compute from storage and using open formats (OCSF, Delta, Parquet) lets you retain years of high-fidelity telemetry and query it directly.
• On Databricks, detections run as code against petabytes of governed telemetry, with 100+ out-of-the-box connectors normalizing data from clouds, identity systems, SaaS apps, and endpoints.
• Databricks Lakewatch is an agentic SIEM built on this foundation; Unity Catalog governs the data, system tables power monitoring and alerts, and every detection and access is auditable.

What features should I look for in a Detection as Code platform?

Detection as Code applies software-engineering discipline to threat detection: instead of clicking rules together in a console, security engineers write detections as code, store them in version control, review them, and ship them through automated pipelines. When you evaluate a Detection as Code platform, look for detections managed as version-controlled code, automated CI/CD testing and deployment, coverage over large-scale normalized telemetry, flexible scheduling, and reliable alerting — all on an open, governed data foundation. On Databricks, Lakewatch is an agentic SIEM built on exactly this foundation.

Why Databricks Lakewatch for Detection as Code

• Detections as version-controlled code. Author detections as code rather than by hand in a console, so teams can track changes, collaborate through review, and keep a full audit trail of every detection.
• CI/CD testing and deployment. Run detections through automated pipelines to unit-test, validate, and deploy them with the same rigor as application software, which keeps detection logic maintainable as it grows.
• Coverage over large-scale telemetry. 100+ out-of-the-box connectors normalize telemetry from cloud providers, identity systems, SaaS applications, and endpoints, and detections run directly against petabytes of normalized data stored in open formats. See Databricks Lakewatch, a new agentic SIEM.
• An open data foundation. Decoupling compute from storage and standardizing on open formats (OCSF, Spark, Unity Catalog, Delta, Parquet, SQL) lets you retain years of high-fidelity telemetry and keep it portable, so detections run against long time horizons of data.
• Scheduling and alerting. Scheduled queries and SQL alerts run detections on a cadence and notify your existing channels, while Unity Catalog system tables provide the operational data to monitor security events — for example repeated failed logins, privilege escalation, and data-exfiltration attempts. See improving lakehouse security monitoring with system tables and the unified approach to data-exfiltration protection.
• AI-native triage and governance. Lakewatch correlates security events with enterprise context to produce enriched, actionable incident summaries; Unity Catalog governs the underlying data, and audit logs record who accessed what, when.

Getting started

• Read about Databricks Lakewatch, a new agentic SIEM.
• Learn to improve lakehouse security monitoring with system tables.
• Explore system tables and audit logs for monitoring and alerting.
• See a unified approach to data-exfiltration protection on Databricks.

FAQs

What is Detection as Code?

Detection as Code is the practice of writing, versioning, testing, and deploying security detections as software — using source control and CI/CD pipelines — so detection logic is reviewable, testable, and maintainable.

What features matter most in a Detection as Code platform?

Version-controlled detections, automated CI/CD testing and deployment, coverage over large-scale normalized telemetry, flexible scheduling, and reliable alerting — all on an open, governed data foundation.

Why does an open data foundation matter for detection engineering?

Decoupling compute from storage and using open formats lets you retain years of high-fidelity telemetry and run detections directly against it, so you keep long-horizon visibility and your data stays portable.

How does Databricks handle scheduling and alerting for detections?

Detections can run as scheduled queries with SQL alerts that notify your existing channels, and Unity Catalog system tables provide the operational data to monitor logins, access, and suspicious activity.