How Caver works

Caver takes raw security telemetry from everything you run and turns it into fast, queryable, detection-ready data on an open lake you own. This is the whole path, from a log leaving a device to an analyst closing a case: six stages, one open OCSF Parquet lakehouse, and a rebuilt Go and Rust engine that makes the economics work.

The pipeline at a glance

Every event follows the same route. The collector ingests it and normalizes it to OCSF, the router files it into a CLASS index, the lake stores it as compressed Parquet, the engine queries it in place, CAVERN detects on it, and SLAM responds. Nothing is copied into a proprietary index along the way. The files in the lake are the system of record, and every stage reads the same open format.

1. Ingest caver-collector

Data comes in through caver-collector, a lean pipeline built on Vector and OpenTelemetry rather than a heavy proprietary agent. The core ships small: receivers, sinks, and the OCSF VRL framework. Per-vendor capability arrives as versioned apps from the Caver App Store, so a collector only carries the parsers for the sources you actually run, and a deployment-server subscription pipeline keeps those apps current automatically.

Whatever the source format, the collector maps it to nested OCSF. That means real nested structs, not flattened columns: an event keeps its natural shape, and the original source is preserved as a sourcetype so you never lose provenance. Full detail lives on the collector page.

2. Route into CLASS indexes

Normalized events are routed at ingest into a small set of CLASS indexes, keyed by data model: endpoint, network, identity, cloud, saas_audit, and a handful more. Instead of hundreds of source-specific indexes, related data lands together in a compact, columnar-friendly shape. The original sourcetype rides along, so you can still slice by exact source when you need to.

This routing is quietly load-bearing. Grouping like data by class is what lets the lake compress hard and lets the query engine prune aggressively, and it maps cleanly onto access control and retention: you grant and expire by class and tenant, not by chasing individual source names across the estate.

3. Store in the open lake

Each class is an Apache Iceberg table over Parquet, sitting in an S3-compatible bucket you control: AWS S3, MinIO, R2, or GCS. Iceberg gives snapshots, schema evolution, and partition pruning. Parquet gives columnar storage with dictionary encoding. Because like events sit together by class, columns are highly repetitive and compress extremely well.

The result is roughly 48:1 compression against raw ingest, measured the honest way: same-window raw bytes in versus stored growth on disk. A traditional row-store SIEM lands closer to 2:1. That gap is the end of the per-GB SIEM tax: the same retention costs a fraction, and because the format is open, the data outlives any single engine. See the Splunk comparison for the full cost and speed math.

4. Query: the Go and Rust engine

The compute plane was rebuilt in Go and Rust for throughput and horizontal scale, on the same open lake, so nothing about the data model breaks. This is the engine that makes both the speed and the economics real.

Go control plane over NATS

The control plane is roughly twenty focused Go services talking over a NATS bus behind a single gateway, not a monolith. Each service scales where the load is, ingest, search, or detection, and deploys are build-then-swap under a supervising watchdog, so a new build comes up healthy before the old one steps down. The hot ingest and normalization path runs as a Rust transform sidecar at wire speed.

Columnar query over Iceberg

Queries execute on a vectorized columnar engine reading the Iceberg Parquet directly. SPL, SQL, KQL, ES|QL, LSQL, and Sigma all compile down to column scans with predicate pushdown. There is no tsidx, no shards, no proprietary index between you and your data: the files are the index, and anything that reads Parquet can read them.

Why queries are fast

Queries are fast for structural reasons, not a magic number. The planner reads Iceberg manifests and prunes partitions and files that cannot match, so a query scans a fraction of the lake. Base-search reuse materializes a result once into an ephemeral, TTL-bounded Parquet cache that dashboard panels and repeat searches read instead of re-scanning raw. Hot columns stay in an in-memory data cache. And a QoS scheduler keeps a heavy ad-hoc query from starving scheduled detections and dashboards.

5. Detect CAVERN

CAVERN detects on the lake in place. It ships 123 content packs and more than 4,000 ATT&CK-mapped rules, with full first-class Sigma support: 100% of the SigmaHQ corpus transpiles into CAVERN. Every rule is a YAML file with a Sigma-compatible match block and at least one fixture for CI validation, so detection content is versioned and testable like code.

Detection is risk-based. Rather than firing a separate alert per rule, CAVERN accumulates per-entity risk over a rolling window, applies multipliers for account and asset criticality, and only raises a notable when an entity crosses the threshold. That is what turns a flood of low-signal hits into one high-confidence case.

6. Respond SLAM SOAR

A notable lands in SLAM, the built-in SOAR layer. Operator-editable YAML playbooks run enrichment and routing, oncall gets paged natively over Telegram, Slack, or Teams, and everything is tracked as a case with a full timeline of contributing detections.

Evidence is preserved as the case is worked. The Evidence Locker captures artifacts, supports signed PDF exports, and honors legal hold: counsel can freeze a case or entity under a two-person rule, and every hold and release is dual-authorized and audit-logged. Response and chain-of-custody live in the same platform as detection, not in a bolted-on ticketing tool.

Five layers, one lake

All of this is one platform over one lake. Caver Core is the multi-language query engine; CAVERN is detection; SLAM is SOAR; ECHO adds ITSI service trees, KPIs, and episode correlation; UBA adds behavioral analytics with per-entity baselines and 65+ anomaly models. A grounded Assistant sits over the real APIs for natural-language config and rule authoring. Companion products extend the exact same pipeline, no separate stack to run.