Five integrated layers

Companion products

Caver Core

Caver is a language-agnostic security data platform. The storage layer is open OCSF Parquet on any S3-compatible object store. The query layer speaks whatever language your team prefers, SPL, SQL, KQL, PromQL, or natural language via AI agents.

Architecture

The central concept: your security data lives as OCSF Parquet in a bucket you control. Caver sits on top, exposing multiple query interfaces and running detection, SOAR, ITSI, and UBA logic against the same data lake.

Query Languages

Caver exposes a unified security data layer that any query interface can address. There is no lock-in to a single language, teams pick the tool they already know.

-- Same data, any language
-- SPL
index=aws_cloudtrail sourcetype=aws:cloudtrail eventName=ConsoleLogin
  | stats count by userIdentity.userName | sort -count

-- SQL (DuckDB / Trino)
SELECT actor_user_name, COUNT(*) as logins
FROM caver_lake.aws_cloudtrail
WHERE class_uid = 3002 AND activity_name = 'Logon'
GROUP BY 1 ORDER BY 2 DESC

-- KQL
CaverLake
| where class_uid == 3002 and activity_name == "Logon"
| summarize logins=count() by actor_user_name
| order by logins desc

Ingest Paths

CAVERN Security for Enterprise

CAVERN is the detection engine inside Caver. It replaces Splunk Enterprise Security with risk-based alerting, ATT&CK-mapped correlation rules, and 123 out-of-box content packs covering 4,000+ detection rules.

Detection Rules

Every CAVERN rule is a YAML file with a Sigma-compatible match block, an optional query override in any supported language (SPL, SQL, KQL, PromQL, raw Sigma), risk score, ATT&CK tags, and at least one fixture for CI validation.

id: cavern.ai_usage.prompt_injection_candidate
enabled: true
title: Prompt-injection candidate in LLM request
severity: high
score: 65
attack: [T1059, T1190]
match:
  selection:
    sourcetype: ai_usage
    prompt|contains:
      - "ignore previous instructions"
      - "forget the system prompt"
  condition: selection

Sigma Integration

Caver ships full first-class Sigma support, the community standard for vendor-agnostic detection rules.

# Transpile a single Sigma rule
caver-sigma import ./my_rule.yml

# Import the full SigmaHQ corpus
caver-sigma import ~/sigma/rules/ -o src/caver/cavern/content/v1/sigma/

# Coverage report
caver-sigma stats ~/sigma/rules/
# → 2960 transpiled (94.5%), 172 skipped (aggregations, field-refs)

Risk-Based Alerting

CAVERN's RBA model accumulates per-entity risk scores over a rolling window, then creates a SLAM notable when an entity's score crosses the threshold.

Content Packs (123)

Detection IDE

The built-in Detection IDE at /ui/cavern-detection-ide lets you author, lint, backtest, and diff rules without touching the filesystem. Write a rule, paste a sample event, see it fire or not fire, live. Auto-tune proposes threshold adjustments based on historical FP/TP rates; apply with one click and roll back if needed.

Supported Technologies

Caver ships out-of-box integrations for 121+ vendors and protocols across security, identity, infrastructure, and OT. Every integration includes a caver-collector receiver/adapter and at least one CAVERN content pack with detection rules tuned to the source's event shape.

Cloud Platforms 12

AWS

Microsoft Azure

Google Cloud

Cloudflare

DigitalOcean

Linode

Vercel

Netlify

Fastly

HashiCorp

Terraform

Kubernetes

Identity & SSO 10

Okta

Auth0

JumpCloud

Duo Security

OneLogin

Keycloak

1Password

Bitwarden

Azure AD / Entra

Google Workspace

Productivity & Collaboration 12

Microsoft 365

Slack

Microsoft Teams

Zoom

Cisco Webex

Mattermost

Discord

Intercom

Box

Dropbox

Notion

Asana

Developer & DevOps 14

GitHub

GitLab

Jira

Confluence

CircleCI

Buildkite

LaunchDarkly

Snyk

Linear

Tines

PostHog

Sysdig

MongoDB Atlas

Snowflake

EDR & Endpoint 10

CrowdStrike

SentinelOne

Microsoft Defender

Carbon Black

Trend Micro

Wazuh

ClamAV

YARA

osquery

Falco

Network & Perimeter 11

Tailscale

Cloudflare Zero Trust

Cisco Meraki

Cisco Umbrella

Fortinet

Palo Alto Networks

Ivanti

Citrix

Suricata

Zeek

Wireshark

Cloud Security 8

Wiz

Lacework

Tenable

Sysdig Secure

Microsoft Sentinel

AWS GuardDuty

AWS SecurityHub

Trivy

AI & LLM 12

OpenAI

Anthropic

Microsoft Copilot

Amazon Bedrock

Azure OpenAI

Google Vertex AI

Hugging Face

LiteLLM

Portkey

LangFlow

Ollama

LM Studio

OT / ICS 7

Dragos

Claroty

Siemens

Rockwell / Allen-Bradley

Schneider Electric

ABB

Honeywell

Sales, CRM & Support 15

Salesforce

HubSpot

Stripe

Shopify

Zendesk

ServiceNow

PagerDuty

Twilio

SendGrid

Postmark

Mailgun

Mimecast

Atlassian Statuspage

Opsgenie

Datadog

Observability & Analytics 10

Splunk

Grafana

Prometheus

Elastic

Kibana

Loki

OpenTelemetry

Vector

Apache Kafka

Confluent

SLAM SOAR

SLAM (Security Localization And Mapping) is Caver's SOAR layer. It handles the full lifecycle from CAVERN notable creation through analyst triage, case management, evidence collection, and compliance-ready reporting.

Notables

A notable is created when an entity's RBA score crosses the configured threshold, or when a rule fires directly at high severity. Each notable carries the contributing rules, scores, entity identity, and a timeline of events.

Playbooks

Operator-editable YAML. Shipped playbooks cover AI usage, host telemetry, cloud privilege escalation, edge appliance exploitation, and OT/ICS anomalies. Playbook steps are composable, mix enrichment, routing, alerting, and case creation freely.

name: ai_usage_critical
trigger:
  notable_severity: [critical]
  pack: ai_usage
steps:
  - enrich_identity:
      field: actor.user.name
  - alert_telegram:
      message: "🔴 {title}, {actor.user.name} ({actor.department})"
  - create_case:
      priority: P1
      sla_minutes: 15
  - tag_notable:
      tags: [ai-security, auto-cased]

Cases

Cases aggregate related notables, attach evidence (Parquet exports, network captures, screenshots, forensic images) into the Evidence Locker with full chain of custody, track SLA timers, and export signed PDF reports for compliance, legal, or post-incident review. SOC KPI dashboards surface MTTD, MTTR, and false-positive rates per content pack.

Oncall Integration

Evidence Locker

The Evidence Locker is Caver's tamper-evident, audit-logged store for any artifact that needs to survive an incident's full legal lifetime. It pairs with SLAM cases, CAVERN notables, ECHO episodes, and compliance reports. Every artifact lands with a SHA-256 hash, a timestamped signature, and an immutable audit trail. The same artifact can be exported decades later with full chain-of-custody verification.

Architecture

The Locker is a thin write-once layer over standard S3-compatible object storage. Caver writes artifacts with S3 Object Lock in compliance mode (legal-grade WORM). A separate ledger tracks every read, write, hold, and export. The ledger itself is appended-only and Merkle-tree hashed for integrity.

Evidence Types

The Locker is artifact-agnostic. Anything you can serialise to bytes lands as evidence with the same chain-of-custody guarantees.

Chain of Custody

Every artifact is admissible-ready. Caver records who touched it, when, and with what cryptographic proof. The chain survives operator turnover, vendor swaps, and platform migrations.

Independent verification

Caver ships caver-evidence-verify, a standalone CLI binary signed and distributed with the product. Point it at an exported evidence bundle and it re-computes the SHA-256, validates the Ed25519 signature, walks the Merkle proof, and exits 0 if the chain is intact. The verifier runs offline. A defence expert, opposing counsel, or auditor can confirm chain integrity without access to your Caver deployment.

caver-evidence-verify --bundle case-2026-04127.evidence.zip
# → verifying 41 artifacts...
# → 41/41 SHA-256 valid
# → 41/41 Ed25519 signature valid
# → ledger Merkle proof valid (root: 0x4f3a...)
# → chain of custody intact through 2026-04-18T14:23:01Z
# → exit 0

Retention & Legal Hold

Retention is policy-driven and per-evidence-class. Legal holds layer on top and freeze deletion until the hold is released by an authorised user. Every hold action is logged.

Legal hold workflow

Export Formats

API & SDK

The Locker exposes a REST API and Python SDK for integration with custom workflows, SOAR connectors, and external case-management systems.

REST endpoints

# Deposit an artifact under a case
POST /api/locker/cases/<case_id>/artifacts
Content-Type: multipart/form-data
X-Caver-Justification: incident-response

# Retrieve an artifact (logged in access ledger)
GET /api/locker/artifacts/<artifact_id>?justification=...

# Apply legal hold (requires dual-auth)
POST /api/locker/holds
{"case_id": "...", "second_auth_token": "...", "reason": "..."}

# Export a case as signed PDF
POST /api/locker/cases/<case_id>/export?format=pdf

# Verify an exported bundle
POST /api/locker/verify
Content-Type: application/zip

Python SDK

from caver_sdk import Locker

vault = Locker(endpoint="https://caver.internal", token=token)

# Deposit a PCAP under a case
art = vault.deposit(
    case_id="2026-04127",
    artifact_type="pcap",
    body=pcap_bytes,
    justification="suspicious egress flow capture",
)
print(art.sha256, art.locker_uri)

# Apply legal hold with dual-auth
vault.apply_hold(
    case_id="2026-04127",
    reason="pending litigation, see legal-2026-31",
    second_auth_token=counsel_token,
)

# Export and download a signed PDF
pdf_bytes = vault.export(case_id="2026-04127", format="pdf")
open("incident-report.pdf", "wb").write(pdf_bytes)

Configuration

[evidence_locker]
bucket = "caver-evidence-locker"
object_lock_mode = "compliance"   # or "governance"
retention_default = "standard"   # see retention table
signing_key_env = "CAVER_EVIDENCE_SIGNING_KEY"   # Ed25519 private key
ledger_anchor_cadence = "1h"   # how often to write the Merkle root to a public timestamping authority

[evidence_locker.acl]
deposit = ["role:analyst", "role:playbook"]
read = ["role:analyst", "role:lead", "role:legal"]
hold = ["role:legal", "role:ciso"]   # dual-auth enforced
export = ["role:lead", "role:legal"]

[evidence_locker.retention.regulatory]
hipaa = "6y_after_closure"
pci = "1y_after_closure"
sox = "7y_after_closure"
gdpr_subject_rights = "subject_request_override"   # allow regulator-driven deletion

ECHO ITSI

ECHO is Caver's service intelligence layer. It replaces Splunk ITSI with service trees, KPI tracking, episode correlation, and real-time health scores, all built on the same OCSF Parquet lake.

Service Trees

Define services hierarchically with parent/child relationships. Each node has a health score derived from its KPIs and contributing notables. Health propagates upward, a degraded leaf impacts every ancestor.

KPI Types

Attach any SPL, SQL, or KQL query as a KPI on any service node. ECHO ships 12 built-in KPI types covering throughput, latency, error rate, saturation, and security signal.

Episode Correlation

Correlated bursts of notables that share an entity, timeframe, and kill-chain stage become episodes. Episodes reduce alert volume from 40 individual notables down to one full-story incident with timeline.

Grafana Integration

Every service health score, KPI value, and episode count is exposed as a Prometheus metric at /metrics. Point Grafana at the endpoint for real-time dashboards. PagerDuty / Opsgenie / Telegram alerting via Grafana Alertmanager.

# Service health gauge
caver_echo_service_health{service="api-gateway"} 31

# KPI values
caver_echo_kpi_value{service="api-gateway",kpi="latency_p99"} 4823
caver_echo_kpi_value{service="api-gateway",kpi="error_rate"} 7.2

# Episode count
caver_echo_episode_count{service="customer-platform",window="15m"} 2

UBA, User Behavior Analytics

Caver UBA builds per-entity behavioral baselines and surfaces anomalies no single rule could catch. It operates across identity, endpoint, network, cloud, and OT signals simultaneously, with 65+ unsupervised anomaly models and ATT&CK kill-chain mapping built in.

Per-entity Baselines

Baselines are computed per individual entity over a rolling 30-day window. Deviation is scored relative to each entity's own history, not a global threshold.

Anomaly Models (65+)

Caver UBA ships 65+ unsupervised models organised by signal type. Models run continuously; scores update on every event. No labelled training data required.

Peer Group Analysis

UBA constructs peer groups from the identity graph: managers + reports, department members, role-based clusters, security-group membership. An action is "anomalous" not because it crosses a fixed threshold but because it is rare for this entity AND rare among its peers.

Threat Assembly

Individual anomalies are assembled into threat timelines when they share an entity, overlap in time, and span multiple ATT&CK phases. A timeline is one SLAM notable that contains the full attack story rather than 40 individual alerts.

ATT&CK Kill-Chain Mapping

Every anomaly model is tagged with the ATT&CK tactics it surfaces. Threat assembly preferentially groups anomalies that span multiple kill-chain phases, a high-confidence signal of an active intrusion.

Cross-source Correlation

UBA correlates anomalies across signal sources through the entity graph. An identity anomaly on alice@corp + an endpoint anomaly on alice-laptop (which Azure AD links to alice) + a cloud anomaly under role alice-iam become a single threat timeline scoring 3× their individual sum.

Identity + Asset Graph Enrichment

Every anomaly is enriched at fire time with the entity's full context:

Intelligence & AI

Caver exposes its full capabilities to AI agents via the Model Context Protocol, and ships a built-in orchestrator for natural-language operator workflows.

MCP Server

Install caver[mcp-server] and connect any MCP-compatible AI client, Claude Desktop, Claude Code, GPT-4 with function calling, or a custom agent. The MCP server enforces Caver's auth model across all queries.

// Claude Desktop / Claude Code config
{
  "mcpServers": {
    "caver": {
      "command": "caver",
      "args": ["mcp", "--config", "/etc/caver/caver.toml"]
    }
  }
}

Available MCP tools: query (run SPL/SQL/KQL), search_rules (find CAVERN rules by name/ATT&CK), get_notables, get_case, trigger_playbook, get_entity_timeline, get_service_health.

Orchestrator, 13 primitives

The Intelligence orchestrator is a Claude-powered admin interface. Operators describe what they need; the orchestrator plans and dispatches across these primitives:

Threat Intelligence

Caver ships first-class threat intelligence as a layer in the platform. Every supported feed normalises to OCSF 2003 (Threat Intelligence) or OCSF 2002 (Vulnerability Finding), populates the IOC bloom-filter for detection-time matching, and is queryable via the orchestrator's enrich_text primitive. Free open feeds ship enabled by default. Commercial feeds plug in with bring-your-own credentials.

Default Feeds (free, open, ship enabled)

These feeds ship enabled in a default Caver install. No commercial licence required, attribution preserved per source license.

Commercial / Paid Feeds (bring your own credentials)

Commercial feeds plug in via standard receivers using credentials you already pay for. Configure your API key in caver.toml threat_intel section (Doppler-backed) and the feed lights up.

Custom Feeds

Any feed you can produce as STIX 2.1, OCSF JSON, CSV, NDJSON, or a webhook can be wired in without writing code. For weirder shapes, drop in a Python normaliser under src/caver_collector/transforms/ and the rest of the pipeline picks it up.

Custom feed config example

[[threat_intel.custom]]
name = "acme-internal-misp"
receiver = "misp"
endpoint = "https://misp.acme.corp"
auth_key_env = "ACME_MISP_KEY"
sharing_groups = ["internal-ops", "soc-tier-3"]
poll_interval = "5m"

[[threat_intel.custom]]
name = "isac-stix-feed"
receiver = "taxii"
endpoint = "https://taxii.example-isac.org/api/v21/"
collection_id = "94b1a4eb-..."
auth_basic_env = "ISAC_AUTH_BASIC"
poll_interval = "15m"

[[threat_intel.custom]]
name = "soar-playbook-output"
receiver = "webhook"
listen_path = "/ti/playbook"
secret_env = "SOAR_WEBHOOK_SECRET"

How feeds integrate

Every feed, whether default open, commercial, or custom, follows the same path through the platform.

From there, four things automatically light up:

caver.toml threat-intel section

[threat_intel]
bloom_filter_rebuild = "0 3 * * *"   # nightly 3am
enabled_default_feeds = ["abusech", "otx", "openphish", "cisa_kev", "cisa_ais"]

[threat_intel.commercial]
recorded_future.api_key_env = "RECORDED_FUTURE_KEY"
crowdstrike.client_id_env = "CS_CLIENT_ID"
crowdstrike.client_secret_env = "CS_CLIENT_SECRET"
virustotal.api_key_env = "VT_API_KEY"

[threat_intel.attribution]
preserve_source = true   # every IOC carries original feed + first-seen + tags
preserve_sharing_group = true   # MISP sharing groups + STIX TLP retained

AI Observatory

Caver provides the most comprehensive security coverage for AI/LLM usage in the industry. 24 dedicated content packs and 200+ purpose-built CAVERN rules cover the full AI threat surface, prompt injection, shadow AI, agent framework abuse, vector-DB exfiltration, supply-chain compromise, voice/image generation misuse, and on-prem inference monitoring.

Core CAVERN Rules (ai_usage pack)

AI Content Packs (24)

Supported AI Tools

Telemetry is normalized to OCSF Application Activity (class 6005) by the caver-collector ai_usage_normalize source. All rules operate on OCSF fields, no raw HTTP inspection, no perimeter TLS break.

Caver-Collector v1.175

The security data pipeline layer. Three equally-featured backends, Python for orchestration and complex normalisation, Vector (Rust) for high-throughput hot paths, and an OTel collector distro for organisations already running OTel infrastructure.

Python Pipeline

The Python orchestrator handles control-plane logic, vendor-specific API polling, and complex normalisation that benefits from Python's ecosystem.

Receivers (21)

SaaS API Adapters (70+)

Transformation & Normalization (44)

Vector Backend (vector-caver)

Rust-speed hot path for high-throughput log sources. Fork of Vector (MPL-2.0) with four custom Caver crates targeting 300k+ events/s.

OTel Backend

An OpenTelemetry Collector distribution (caver-otelcol) built with ocb v0.129. Deploy it anywhere you already run OTel infrastructure, it speaks native OTLP and drops into existing pipelines.

receivers:
  filelog:
    include: ["/var/log/app/*.jsonl"]
processors:
  transform/ocsf:
    log_statements:
      - context: log
        statements:
          - set(attributes["class_uid"], 4001)
          - set(attributes["metadata.product.name"], "caver-otelcol")
  batch:
    send_batch_size: 500
    timeout: 30s
exporters:
  awss3:
    s3uploader:
      endpoint: "http://minio:9000"
      s3_bucket: "caver-lake"
    marshaler: parquet

Caver Forge

Caver Forge is the companion product that turns newly published CVEs into queryable detection content with no human in the loop. It scrapes new CVEs from configurable threat-intel feeds, drafts Sigma rules via Claude grounded in your OCSF schema, transpiles to SPL, runs the query through Caver's /services/search/run endpoint, and writes Detection Finding (OCSF 2004) rows to stage_alerts/ in the lake. The output answers one question continuously: "would my lake have caught this CVE if I had been watching?"

What it does (and what it doesn't)

Threat Intel Feed Registry

Forge ships a curated default feed registry. Two feeds are enabled by default (NVD + CISA KEV); the rest are listed and opt-in. User overrides live in ~/.config/cve-forge/feeds.yaml.

Custom feeds drop in via the same YAML, point at any RSS / JSON / Atom endpoint:

feeds:
  - id: my-private-feed
    name: "Internal threat intel"
    type: rss
    url: https://intel.internal.example.com/feed
    enabled: true
    auth_env: INTERNAL_FEED_TOKEN

Pipeline

Each CVE flows through five stages, fully observable, retry-safe, idempotent on CVE ID. Stages emit structured telemetry to Caver's /metrics for ECHO health tracking.

Enabled feeds (NVD, CISA KEV, custom, ...)
    │
    ▼
cve_forge.scrape   normalised CVE record (id, description,
    │               CVSS, CPEs, CWEs, references)
    ▼
cve_forge.generate Claude prompt grounded in caver/sources.json,
    │               returns a validated Sigma YAML
    ▼
cve_forge.transpile pysigma + pysigma-backend-splunk to SPL
    │               (sentinel-aware: _not_applicable: true on
    │                rules that cannot match this lake's sources)
    ▼
cve_forge.run      POST SPL to caver, read X-Caver-Row-Count
    │               header, build StagedResult
    ▼
S3 OCSF parquet sink   s3://lake/stage_alerts/year=.../...
                       (class_uid 2004, Detection Finding)

Sentinel handling

Some CVEs do not map to any data shape your lake collects (firmware vulns in IoT devices you do not monitor, vulns in apps your org does not run). Forge does not pretend to generate a rule for those. The generate stage returns _not_applicable: true with a structured reason, the row lands in stage_alerts/ with status not_applicable, and the loop moves on. The kiosk surfaces these so an operator can review the coverage gap and decide whether to add a source.

Configuration

Forge runs as its own process with its own config. Caver reads Forge's output as one more lake source. Minimal install:

pip install caver-forge   # separate distribution

# point at your caver instance + LLM
export CAVER_URL=https://caver.internal:8089
export CAVER_TOKEN=$(doppler secrets get CAVER_HEC_TOKEN --plain)
export ANTHROPIC_API_KEY=$(doppler secrets get ANTHROPIC_API_KEY --plain)

# write target (same MinIO bucket caver reads from is fine)
export FORGE_S3_BUCKET=caver-lake
export FORGE_S3_PREFIX=stage_alerts/

# kick off a one-shot scrape
cve-forge scrape --hours 24

# or run the autonomous background loop
cve-forge loop --interval 1h

Caver-side source config

Add stage_alerts to your Caver sources.json so the kiosk + SPL surfaces light up the same way they would for any other source:

{
  "stage_alerts": {
    "bucket": "caver-lake",
    "prefix": "stage_alerts/",
    "schema": "ocsf_detection_finding_v1.3.0",
    "default_index": "stage_alerts"
  }
}

CLI Reference

Forge vs CAVERN

Forge and CAVERN sit at opposite ends of the detection lifecycle. Forge is breadth-first (every CVE, no human), CAVERN is depth-first (every rule hand-tuned). They feed each other.

Promotion bridge

When a Forge-generated staged finding surfaces an obviously valuable detection (high CVSS, observed in your lake, plausible threat model), SLAM's Phase-5 bridge offers a one-click promotion: the staged Sigma rule moves into a CAVERN content pack with operator review, gets fixtures, and joins the production detection set. The lineage from CVE to staged rule to production CAVERN rule is preserved end-to-end.

OT / ICS, Caver Industrial

Caver Industrial extends the core platform to operational technology and industrial control system environments. It ships as a separate plugin with per-deployment pricing.

IT/OT Correlation

The it_ot_correlation and scada_windows packs bridge IT and OT telemetry, correlating Windows event logs from engineering workstations with industrial protocol anomalies on the same OT network segment. An attacker moving from the IT perimeter to a SCADA workstation to a PLC shows up as a single correlated timeline in SLAM.

Vendor integrations

Compare Caver

Honest side-by-side comparisons against the field. Pick a tab, the comparison expands inline: at-a-glance table, where the incumbent wins, where Caver wins, and how to decide.

Active comparison

OCSF, design choices

Caver's storage layer is open OCSF (Open Cybersecurity Schema Framework) Parquet on any S3-compatible object store. This page explains what that means, why we picked it, and the other architectural calls we made along the way.

What is OCSF?

OCSF (Open Cybersecurity Schema Framework) is a vendor-neutral, open-source schema for security data. Originally announced by Splunk and AWS at Black Hat 2022 and now maintained at the OCSF Project on GitHub under the Linux Foundation, it has broad industry support: AWS, Splunk, IBM, CrowdStrike, Cloudflare, JupiterOne, Tanium, Zscaler, Salesforce, Okta, Trend Micro, DTEX, and dozens more.

OCSF defines a normalised event shape for every category of security telemetry: authentication, network activity, process activity, file activity, application activity, vulnerabilities, findings, configuration, audit. Every event has a stable schema with class_uid, category_uid, severity_id, activity_id, ATT&CK tagging, actor / target / source structures, and an OCSF-defined version field.

Why we chose OCSF

Why Parquet on object storage

The second half of the storage decision: store OCSF as Apache Parquet on S3 / MinIO / R2 / GCS, not in a proprietary index format.

Same files are queryable by Caver, by your data team via Athena or Snowflake external tables, and by your ML/AI team via PyArrow or Spark. The data lives once.

Other architectural choices

External references

• OCSF Schema Browser, browse every class and field
• OCSF Project home, governance and contributors
• OCSF on GitHub, schema source
• Apache Parquet, columnar storage format
• SigmaHQ/sigma, the community detection rule corpus

Deployment

Installation

# Core install
pip install caver

# Install with specific roles
pip install 'caver[cavern-engine,slam-engine,scheduler]'
pip install 'caver[search-head]'
pip install 'caver[mcp-server]'
pip install 'caver[all-roles]'  # dev / dogfood only

# Caver-Collector
pip install caver-collector
pip install 'caver-collector[parquet]'  # adds PyArrow for Parquet sink

Configuration (caver.toml)

[roles]
enabled = ["search-peer", "cavern-engine", "slam-engine", "scheduler"]

[storage]
bucket = "caver-lake"
endpoint = "http://localhost:9000"   # MinIO / LocalStack / R2
access_key_env = "MINIO_ACCESS_KEY"
secret_key_env = "MINIO_SECRET_KEY"

[cluster]
discovery = "static"
peers = ["localhost"]

[cavern]
content_path = "/etc/caver/content/v1"
rba.notable_threshold = 100

[slam]
oncall_telegram_chat_id = "YOUR_CHAT_ID"
telegram_token_env = "TELEGRAM_BOT_TOKEN"

[caver.ai]
user_daily_cost_usd = 50

Available roles

Splunk Peer Mode

Register Caver as a distributed search peer of your existing Splunk SH. No Splunk source or forwarder changes required. Caver receives SPL, scans the OCSF Parquet lake, and returns results over the splunkd wire format.

caver-cluster join   --splunk-host splunk.internal   --splunk-port 8089   --splunk-user admin   --splunk-pass "$SPLUNK_PASS"   --peer-uri https://caver.internal:8089

Any licensing change to your Splunk contract is made through Splunk per your existing agreement. Caver does not modify, patch, or bypass any Splunk license mechanism.

Health Check

caver-doctor --role search-peer
caver-doctor --role cavern-engine --config /etc/caver/caver.toml
# → exits 0 if healthy, 1 with structured error output if not

Docker / Kubernetes

docker run --rm -it \
  -e MINIO_ACCESS_KEY=minioadmin \
  -e MINIO_SECRET_KEY=minioadmin \
  -v /etc/caver:/etc/caver \
  ghcr.io/redeyesecurity/caver:latest \
  --config /etc/caver/caver.toml

# Helm
helm install caver oci://ghcr.io/redeyesecurity/charts/caver \
  --set storage.bucket=caver-lake \
  --set storage.endpoint=http://minio:9000

Configuration Reference

Storage

CAVERN

SLAM

AI config

Multi-tenancy (MSSP)

[[tenants]]
id = "acme"
display_name = "Acme Corp"
s3_prefix = "tenants/acme/"
row_filter = "metadata.tenant_uid = 'acme'"

[tenants.llm]
provider = "anthropic"
model = "claude-sonnet-4-6"
api_key_env = "ACME_ANTHROPIC_KEY"