Five integrated layers

Caver Core →

Multi-language query engine on OCSF Parquet. Supports SPL, SQL, KQL, ES|QL, and LSQL, plus Sigma content and a grounded AI assistant. Federates with most search tools (Splunk, Elastic, Sentinel, more).

CAVERN Security for Enterprise →

Per-entity risk-based alerting, ATT&CK-mapped detection rules, 123 content packs, 100% SigmaHQ corpus mapped, full Detection IDE with live backtest.

SLAM SOAR →

Notables, incident cases, and approval-gated playbooks with a credential vault, auto-block response, allowlists, and auto-run analyzers. Evidence preservation, signed PDF exports, a SOAR operations dashboard. Native Telegram, Slack, Teams oncall routing.

ECHO ITSI →

Service trees, KPIs, episode correlation. Health scores per service. Real-time Grafana integration.

UBA →

Per-entity behavioral baselines with admin and criticality multipliers. 65+ unsupervised anomaly models. Threat assembly across identity, endpoint, network, cloud.

Intelligence →

Claude AI agent layer with 13 wrapped operator primitives. Natural-language config, rule authoring, playbook dispatch, compliance reporting via MCP.

Engine & 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, ES|QL, or LSQL, or plain English via the grounded AI assistant.

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.

Caver UI

The native operator console at /ui. Speaks every supported language transparently, type SPL, SQL, KQL, ES|QL, or LSQL and caver routes to the right engine. Built-in search lab, Detection IDE, SLAM notables, ECHO service trees.

SPL

Native Splunk Processing Language. Caver registers as a standard distributed search peer, existing dashboards, saved searches, and ES correlation searches run unchanged. Zero re-training for Splunk teams.

SQL

Standard ANSI SQL natively, or at scale via Trino and AWS Athena. Point any SQL client directly at the OCSF Parquet lake. Full window functions, JOINs, and aggregations across the full event history.

KQL

Kusto Query Language (Azure / Microsoft Sentinel compatible). Security teams familiar with KQL from Azure Sentinel or ADX can run KQL queries against Caver's OCSF lake without changing their workflows.

Sigma

The community standard for vendor-agnostic detection rules. Caver ships a full Sigma-to-CAVERN transpiler and 100% of the SigmaHQ release corpus mapped. Write once, run everywhere.

Grafana

Point Grafana at Caver's metrics endpoint for dashboards and alerts. ECHO service health, UBA anomaly scores, and CAVERN firing rates are all exposed as Prometheus metrics.

Natural Language

Describe what you want in plain language. The Intelligence assistant translates it to a query, executes it against the OCSF lake, and returns a plain-language answer with the query it ran.

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

-- SQL
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

The 48:1 figure is measured the honest way: same-window raw ingest volume versus stored lake growth, not a synthetic benchmark. Everything below is how the engine earns it.

Go control plane

The compute plane is a set of roughly twenty focused Go services communicating over a NATS message bus behind a single gateway, not a monolith. Each service scales independently. Deploys are build-then-swap with a supervising watchdog, so a new build comes up healthy before the old one steps down.

Columnar query over Iceberg

Queries execute on a vectorized, columnar engine reading Apache Iceberg tables of OCSF Parquet directly. SPL and other dialects compile down to column scans with predicate pushdown, no proprietary index format sits between you and the data. Column projection and dictionary encoding are why the same events compress dramatically better and scan far faster than a row-store SIEM.

Caching and ephemeral acceleration

Repeat work is not re-scanned. Base-search reuse materializes a query's base result once into an ephemeral, TTL-bounded Parquet cache; dashboard panels and repeat searches read the cache instead of re-scanning raw. An aggregate cache serves repeat aggregations. The cache is disposable by design: it accelerates, it never becomes a second source of truth.

Open and future-compatible

The engine sits on Apache Iceberg tables and the OCSF schema, both open. You can query in place, federate across tools, or bring your own S3 bucket. There is no lock-in: the lake outlives any single engine, and the compute plane can be upgraded underneath your data without a migration. That is the point of separating an open storage layer from the engine that reads it.

Performance and resource control

The engine is built to scan as little as possible and to keep interactive work fast while heavy jobs run. The controls below are real mechanisms in the compute plane, and most are tunable per deployment.

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, ES|QL, LSQL, 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

Dashboard Studio and the panel editor

Every panel is a saved search plus a visualization. Open the panel editor to switch the chart type on the fly, then open the per-visualization Configure pane to set palette, legend placement, axis bounds and scale, and data labels. No JSON hand-editing to get a chart that reads well.

Chart types and the ECharts 6 engine

Rendering runs on ECharts 6, upgraded from the 5.x line, with 15 or more chart types covering the full stats and charting surface: line, bar, column, area, pie, donut, scatter, single-value, gauge, table, heatmap, treemap, sankey, sunburst, radar, and funnel. Charts stay crisp in both light and dark themes and export cleanly into cases and reports.

Network Flow and lake health

Two purpose-built boards ship in the box. Network Flow renders connection data as a graph, and the lake-health dashboard turns the platform itself into something you can watch the same way you watch your estate.

Signature dashboards on content packs

Rich content packs ship with a signature centerpiece chart: one striking visualization that frames the pack's story, surrounded by supporting panels. Install the pack, get the dashboard. The board is a first-class part of the content, not an afterthought bolted on later.

Base-search reuse acceleration

A dashboard opens with one base search. Caver materializes that base result a single time into an ephemeral, TTL-bounded Parquet cache, then every panel applies its own transform against the cached result instead of re-scanning the lake. Ten panels cost roughly one scan, not ten. This acceleration is shipped and enabled by default.

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. The grounded assistant does not guess: it discovers your accessible indexes under your own permissions, generates and validates the query, then runs a live bounded preview against the lake before it answers.

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. RedEye's own intelligence feed, feeds.redeyesecurity.com, ships first.

Commercial / Paid Feeds (bring your own credentials)

Commercial feeds plug in via standard receivers using credentials you already pay for. Point the feed receiver at your API key (an environment variable, secret-manager 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.

Three ingest modes

Caver watches AI usage three ways, and you can run any combination. Every mode lands in the ai_observability index as OCSF Application Activity, with CAVERN rules on top.

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.418

The security data pipeline layer, shipped lean. A Vector (Rust) hot path and an OpenTelemetry collector distribution move data at throughput; receivers, sinks, and the OCSF VRL transform framework form the core. Per-vendor capability arrives as versioned, OCSF-mapped apps from the Caver App Store, so the core stays small and every source normalizes the same way.

Sources and Receivers

The collector core exposes receivers and sinks and runs the OCSF VRL transform framework. Vendor-specific API polling and normalization ship as App Store apps rather than being baked into the core, so adding a source does not mean upgrading the collector.

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

What it is

Caver-Collector no longer carries every vendor integration in its core. The core stays small: receivers, sinks, and the OCSF VRL transform framework. The catalog carries 167 versioned, OCSF-mapped apps today. Everything vendor-specific, the parser, the schema mapping, and the detection content for a given source, lives in an app you install. A proven app-marketplace model, rebuilt around OCSF and versioning.

App bundles

Each app is a versioned bundle. It declares what it maps, which OCSF classes it emits, and the content it ships. Because every app normalizes to OCSF, apps compose cleanly: two vendors in the same category land in the same CLASS index with a consistent shape.

Subscription pipeline

A deployment server tracks which apps each collector subscribes to. When an app publishes a new version, subscribed collectors pull and apply it on their next check-in, the same operational model as a Splunk deployment server, so a mapping fix or a new detection reaches every collector that runs that source without hand-editing configs.

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 major threat-intel feeds, NVD, CISA KEV, MSRC, GHSA, and OSV among them, prioritizes by KEV, EPSS, and CVSS, drafts Sigma rules via Claude grounded in your OCSF schema, transpiles to SPL (and Sentinel KQL), 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?" RedEye publishes the same forge-generated detections publicly as STIX 2.1 / TAXII 2.1 feeds at feeds.redeyesecurity.com, so you can subscribe to RedEye's stream even before you run your own Forge.

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.

Device-identity decode

Caver Industrial passively decodes industrial protocol telemetry to build asset identity without active scanning, which OT networks cannot tolerate. From Modbus, DNP3, EtherNet/IP, and S7comm traffic it extracts device fingerprints: vendor, model, firmware, unit and station IDs, and function-code behavior, so you get an inventory of what is on the wire plus a baseline of normal control activity to detect against.

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.

Nested OCSF and CLASS indexes

Two design decisions make the lake both compact and fast to query. First, events are normalized to nested OCSF: real nested structs (actor, device, target, metadata), not a flattened wall of columns. The shape matches the schema, so a query reads exactly the fields it needs and nothing else. Second, events are routed at ingest into a small set of CLASS indexes by data model, endpoint, network, identity, cloud, saas_audit, and a handful more, with the original source preserved as the sourcetype.

Instead of hundreds of per-source indexes, you get a dozen or so CLASS indexes that group like data together. That is what lets column projection, dictionary encoding, and partition pruning do their work: similar events sit in the same columns, so they compress hard and scan fast. The CLASS model is also where RBAC and retention attach cleanly, you grant and age by data model, not by chasing every source name.

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

Security

Caver treats its own posture as a feature. The stack is hardened secure-by-default: services refuse to start in an insecure shape rather than warning about it, security headers and a content-security policy ship on by default, and every API surface is rate-limited.

Hardened by default

SSO & access control

Enterprise sign-on via OIDC, role-based access control over a closed capability set, and least-privilege defaults: a token issued without a role gets read-only viewer access, never admin. Login attempts are throttled per account.

Multi-tenant isolation

Index-scoped RBAC and per-index ingest ACLs make the index the tenant boundary: one deployment serves many customers with no cross-tenant reads. See Configuration Reference for the MSSP model.

Caver also watches itself: every service ships its own telemetry into the same lake it protects, so the SIEM is one of the sources it monitors.

Deployment

Caver deploys as a single self-contained stack: one gateway in front of the Go service fleet and the Rust transform sidecar, brought up and swapped atomically by one lifecycle script. Run it managed, self-hosted in your cloud, on-prem, or fully air-gapped. There are no config files to template: every knob is an environment variable, so the same artifact promotes cleanly from lab to production.

Installation

The stack ships as prebuilt binaries plus a lifecycle script that owns start, stop, deploy, and status. A deploy is build-then-swap: the new build comes up beside the old one and takes over only after it passes health checks, with a supervising watchdog guarding the running stack afterward. The collector installs as a native service (systemd, launchd, or Windows service) with one command, and vendor capability arrives as versioned apps from the App Store rather than a monolithic reinstall.

Configuration (environment-only)

All configuration is environment variables with the CAVER_ prefix. No caver.toml, no sidecar files, no config drift between boxes. Secrets are injected at runtime from your secret manager and never baked into an artifact.

# the essentials
CAVER_LAKE_S3_ENDPOINT=https://s3.internal:9000   # any S3-compatible store
CAVER_LAKE_WAREHOUSE=s3://caver-lake/warehouse    # the Iceberg warehouse
CAVER_LAKE_CATALOG_DSN=postgres://...             # Iceberg catalog
CAVER_HEC_TOKEN=...                               # ingest auth
CAVER_LLM_PROVIDER=anthropic                      # AI assistant (optional)

The full reference lives in the Config Reference section.

Splunk Peer Mode

Register Caver as a distributed search peer of your existing Splunk search head: no source or forwarder changes required. Caver receives SPL, scans the OCSF Parquet lake, and returns results over the splunkd wire format, so your team keeps its search head while the lake does the heavy lifting.

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 & diagnostics

# the gateway aggregates per-service health and build identity
curl http://caver.internal:18088/healthz
curl http://caver.internal:18088/version   # version + commit, per backend

# caver-doctor: structured diagnostics, machine-readable, optional self-heal
caver-doctor --json
caver-doctor --heal

Every deploy stamps its exact commit into every binary and asserts it live after the swap, so what is running is provably what you shipped.

DR replication

The lake replicates continuously to a second S3 bucket, region, or box, with replica health monitored from inside Caver: lag and divergence surface as first-class health, not a silent gap you discover during an incident. Because the lake is open Parquet on object storage, the replica is immediately queryable, and flexible: replicate to a different provider, a different site, or cold storage.

Configuration Reference

Caver is configured entirely through CAVER_* environment variables. The most-used families:

Storage & lake

Query engine

Ingest & lifecycle

AI assistant

DR replication

Multi-tenancy (MSSP)

Tenancy is enforced at the index boundary: each tenant lands in its own indexes, HEC tokens carry per-index ACLs, and index-scoped RBAC keeps every query, dashboard, and detection inside the caller's tenant. One deployment, many customers, no cross-tenant reads.