What’s new
Since 2026-08-17 · caver-go 1.155.5 · collector 5.7.13 · updated 2026-09-02
Carbide is the headline: a first-party endpoint agent that did not exist at the last checkpoint and now collects, ships, updates and rolls itself back. Everything else in this window is the unglamorous half, correctness in the normalizers and reliability in the collector, which is what decides whether a quiet dashboard means a quiet estate.
The full compatibility list is its own page, searchable by technology and filterable by industry: Works with Caver.
Carbide EDR, new
- Linux eBPF CO-RE exec collectionOne artifact across kernel versions, container identity resolved in kernel so it survives a process that already exited, and a fidelity field on every event.
- The same OCSF contract as the Sysmon pathContent is written once and fires on Windows Sysmon hosts and Linux Carbide hosts alike. The product name is close to the only field that differs.
- Packaged as a systemd serviceInstaller validates its own config, because a blank environment variable used to reach the agent as an empty argument and turn one bad line into a restart loop.
- An update channel that can undo itselfSigned manifest verification, staged rollout at 0.5, 5, 25 then 100 percent, atomic install, and rollback counted on start attempts rather than elapsed time.
- Gap and tamper alerts, with suppression and acknowledgementAn agent that stops reporting is an alert, not an absence. Suppression exists so a planned window does not train anyone to ignore it.
Vulnerability prioritization
- KEV and EPSS joined onto findingsExploitation likelihood and known exploitation sit on the finding itself, so triage order is not a CVSS number that never moves.
- CISA KEV and FIRST EPSS ingested on a scheduleBoth feeds land as enrichment rather than as a lookup someone refreshes by hand.
Identity and access
- SAML 2.0 service providerAuthnRequest, assertion verification and published metadata.
- SSO configured in the UI, tested before it is enabledA misconfigured identity provider locks everyone out, so the test runs against the real IdP before the switch flips.
- Non-human identity inventoryService accounts, agents and automations inventoried as first-class actors rather than as users who never sleep.
OT / ICS
- Process Integrity screen with learned envelopesNormal is learned from the process rather than typed into a threshold field.
- Safety and Availability screen for operations managersWritten for the person who owns uptime, not for the analyst who owns alerts.
- Operator behaviour gets its own locality, retention and export classWho touched the plant floor is not the same data class as who logged into email, and it is no longer retained or exported as though it were.
Response and case work
- Time to contain, measured on human response intervalsThe number counts the intervals a person was actually in, so it is not flattered by an automation that closed the case at 3am.
- Findings page drilldown, consolidation, filtering and searchThe page that was a list is now something you can work from.
Collector reliability
- Receivers report to /metricsEight separate sets of counters were unreadable in logs and are now one surface.
- A source going silent reaches something that can act on itSilence used to be indistinguishable from calm.
- Dead-letter queue for caver_parquet, on by default, with a consumerA failed batch records how it failed, the backlog is a metric rather than one log line, and the queue can be drained instead of inspected.
- Undeliverable HEC batches spool to diskThey used to be deleted.
- All inputs failing is fatalA collector with every input dead used to keep looking alive.
- An unset variable is refused at parse timeIt used to resolve to an empty string and run.
OCSF correctness
- User access separated from group change across five feedsgcp_audit, cloudflare_audit, github_audit, launchdarkly_audit and opsgenie_audit were labelling access events with a group caption, which is content that cannot match.
- Account Locked and Account Disabled are Account ChangeNot the group class they were filed under.
- Tooling that answers what content breaks before a class is renumberedIncluding whether a class selector can identify a feed at all.
Detection content fidelity
- UniFi findings audited against what the sensor actually emits42 of 165 Detection Findings were assembled from process names, paths and rejected rule text, and 123 of 123 IDS findings named the defending gateway as the attacker.
- DCSync exclusion keys on the SIDAn attacker can choose a name. They cannot choose the SID.
- EHR audit semantics correctedA break-glass is tested before the refusal so an emergency access is not filed as a view, a Cerner-style sign-on is an authentication, and a note sign-off is still not a session ending.
Security of Caver itself
- PR bodies and titles stop being published into retained CI logsRedacting after the fact closes nothing, so they no longer ride in step environment variables.
- A webhook client can no longer name its own tenantBreaking change, deliberately.
- TLS verification could be disabled by an empty valueThe Wazuh adapter read raw truthiness, so an unresolved variable silently turned verification off.
- grpc-go raised to 1.83.1Clears the HTTP/2 DATA fragmentation out-of-memory condition.
Previous checkpoint
Since 2026-07-14 · caver-go 0.26.2 → 0.427.0 · collector 1.418 → 1.436 · updated 2026-08-17
37 capabilities landed in this window, across twelve areas. Each one links to where it is documented. Older releases are not listed here; this is what changed since the last checkpoint, and it is rewritten at the next one.
The full compatibility list is its own page, searchable by technology and filterable by industry: Works with Caver.
Healthcare & clinical
- EHR access, four audit formats into one shapeEpic CEF/LEEF, Oracle Health P2Sentinel, Meditech, IHE ATNA and FHIR AuditEvent, with fidelity reported rather than assumed.
- HL7 interface behaviorRead from a mirror, never in the message path. Reports the interface that quietly stopped.
- DICOM without reading an imageThe parser stops at the pixel data.
- Connected device triageSorts on change rather than CVE count.
- Patient identitySalted one-way keys, unique per deployment, with attribution reported three ways.
- Facility monitoringBACnet room pressure and air changes against ASHRAE 170 and FGI, with the citation on the finding.
- HIPAA mappingMapped with citations, and states where Caver does not help.
OT / ICS
- The command-chain modelLearns the control conversation from the wire alone. A positive model, not an anomaly score.
- Goal feasibilityCarries units and names the binding constraint instead of returning a pass or a fail.
- Deviation cause classificationA deviation is classified by why it happened rather than forced into an incident shape.
- Operating-practice baselinesSliced by shift, crew and season, because one baseline across all of them reports the difference as an anomaly every time.
- Competence and staffing driftThe slow loss of operating skill after a downsizing, months before an incident.
- OT operations monitoringThe screen an operator opens at 6am, so the data serves the control room and not only the SOC.
- Validated against a simulated plantIt found four defects in the two models it was built to test.
Compliance, CUI & FIPS
- Encryption as a preconditionRefuses to start against storage it cannot confirm is encrypted.
- CUI markings and NIST SP 800-171Registry-aware markings, control mapping, exportable as evidence.
- FIPS 140-3 modeSupport for the mode. Never validation of the product.
- Compliance APIFramework posture over JSON HTTP, so a GRC platform can pull it directly.
Migration & federation
- Splunk search peer and federationRun beside Splunk, Elastic, Sentinel, Sumo Logic or Datadog and compare answers on your own data.
- Six importersSplunk (with ITSI and UBA), Elastic, Sentinel, Defender, QRadar and SigmaHQ.
- One-command migrateOne entry point with a dry run, rather than a runbook per product.
Core data model
- ClassesIndex-to-class, sourcetype-to-class, and operator-created classes at runtime. Content written against a class survives an index rename.
- Durable tagsWritten to the warehouse first, so a tag survives a restart and reaches the search service.
Detection & response
- Change windowsApproved change work de-weighted rather than blinded, with every adjustment attributed back onto the finding.
- ChatOpsCommands from chat, with the source recorded for the audit trail.
- Vulnerability CenterRe-ranks CVEs by asset criticality, so a medium on a crown jewel out-ranks a high on an unclassified box.
Security of Caver itself
- Cleartext credential guardClassifies its own outbound addresses at startup. Loopback stays silent.
- Sensitive-data exposure mapWhich systems carry which classes of sensitive data, and which of them should not.
- SSRF-hardened operator fetchesAn operator-supplied URL cannot be turned into a request against your internal network.
- Demo data is markedA trial environment cannot be mistaken for production evidence.
AI
- MCP query contractAn assistant queries through a defined contract rather than being handed a shell.
- Natural-language queriesA sixth way to ask, and it shows the query it generated.
Threat intelligence
- IOC feedsIndicators joined against your data as it lands.
Query languages
- Splunk command coverageDozens of commands that used to fail a whole pipeline now run: cont=, bins=, timewrap, makecontinuous, outlier, set operators, per_second() and more.
- Refusals name themselvesWhere a command still cannot be honored it is refused by name with the reason, rather than failing the search anonymously.
Storage
- True on-disk footprintThe lake reports its whole footprint beside the parquet-only number, so the storage-efficiency ratio stops flattering itself.
Detection content
- PHI access and imaging packsThe chart-access review content a hospital is buying, plus the imaging estate and the retrieve nobody recognizes.
The end of the volume-based SIEM tax.
Caver is a next-generation security data platform. A rebuilt Go and Rust compute engine runs detection, SOAR, ITSI, UBA, and AI security directly on one open OCSF Parquet lakehouse, engineered for speed, horizontal scale, and future compatibility. It retires the expensive, per-GB SIEM model of the last decade: Caver ships and manages its own enterprise lake (bring your own S3 bucket only if you prefer), your data stays open and under your control, we work with everything you already run, federate with most search tools (Splunk, Elastic, Sentinel, Sumo, Datadog), and speak every major query language.
Five integrated layers
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.
/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.-- 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 descIngest Paths
Classes, sourcetypes and tags
Sites name things differently. One hospital calls it epic_audit,
another calls it ehr_prod, and content written against index names
breaks the first time somebody renames one.
A class is a logical grouping of data across indexes. Content is written against the class, so a dashboard or rule works whether you run Epic or Meditech and whether your HL7 arrives through Mirth or Rhapsody. Nothing has to be rewritten for your naming.
| Mapping | What it does |
|---|---|
| Index → class | Folds a whole index into a class. |
| Sourcetype → class | Folds an event into a class by its sourcetype, regardless of index, which is the dimension that survives an index rename. |
| Operator-created classes | New class names at runtime, from the Settings page. No restart, no config file. |
Both maps are operator-owned and default-dark: unconfigured, they are a no-op, and nothing on the existing routing path pays for them.
Tags are durable and shared. A tag created through the API is
written to the warehouse first and then installed, so it survives a restart and
reaches tag= expansion in the search service rather than living in
one process's memory.
Splunk command coverage
The largest body of work in this window went into the query languages, and it is the part a migration feels first: a single unsupported command used to fail the whole pipeline, so one unfamiliar function in a migrated dashboard took the panel down rather than degrading it.
Commands and options that now run, rather than rejecting the search:
| Area | What runs now |
|---|---|
| Time series | | timechart cont= keeps empty buckets in the answer instead of silently closing the hole, bins= derives bucket width from the data's own range, and | timewrap drives week-over-week and day-over-day panels |
| Charting | | chart span= bins= start= end= bucket the x axis for histograms and bounded bands; otherstr= and nullstr= name the two series a chart otherwise draws unnamed |
| Rates | per_second(), per_minute(), per_hour(), per_day() |
| Shaping | | makecontinuous, | outlier, | set diff/union/intersect, and useother= on | top and | rare so a ranked tail folds into an OTHER row instead of disappearing |
Where a command still cannot be honored, it is refused by name with the reason, rather than failing the pipeline anonymously.
Carbide, the Caver EDR
Carbide is the endpoint agent that ships with Caver. It collects at kernel level, emits OCSF on the wire, and lands in the same lake as every other source, so endpoint activity is queryable beside identity, network and cloud data rather than in a separate console. There is no per-endpoint charge.
Collection
Every event declares metadata.collection_source and metadata.collection_fidelity. The two paths are told apart by reading a field, never by noticing which optional fields are missing, so a degraded collector reads as degraded rather than as a quiet week.
Integration with Caver
Carbide is not a bolt-on with its own storage. Events arrive over the standard ingest path and are written to the same lake, under the same class model, as everything else Caver collects.
actor.process, the launched child is process, and the identifier is stable across event types. A chain joins from an execution to the network connection it made.Risk-based alerting
Carbide events feed risk-based alerting the same way any other source does. A rule that fires against endpoint activity attributes risk to an entity, the host or the user, and that score accumulates alongside risk raised by identity, network and cloud rules.
This is the point of collecting endpoint data into the same platform rather than beside it. A single suspicious execution is rarely worth waking anyone. The same execution on a host that also had an unusual login, an outbound connection to a new destination, and a privilege change an hour earlier is a different proposition, and only a shared risk model can see that. Carbide raises the endpoint half of that picture into the same score.
Response actions
Detection without response leaves an analyst reading about something they cannot stop. Carbide supports host response driven from Caver:
Automation
Response actions are available to SLAM playbooks, which means they can run automatically on the content of a detection rather than waiting for someone to read it.
Carbide and Sysmon
Carbide is not a replacement for Sysmon, and the two are not alternatives you pick between. They are the same telemetry on two operating systems, and the design goal is that a rule cannot tell which one produced the event it just matched.
Caver already normalizes Sysmon. The collector subscribes to the Microsoft-Windows-Sysmon/Operational channel through the windows_event_log receiver, and the default sourcetype matches the classification heuristic, so a Sysmon host is read with no per-host configuration. Carbide's output contract holds the Linux agent to the same OCSF class and the same field paths that the Sysmon normalizer produces. metadata.product is the field that should differ between the two producers, and close to the only one.
That is what makes the pairing worth anything. Detection content is written once. A rule matching on process.cmd_line with a parent in actor.process fires on a Windows Sysmon host and on a Linux Carbide host, and there is no second Linux version of the rule to keep in step with the first.
Where the two genuinely differ
The shipped normalizer grew up Windows-shaped, and pretending otherwise is how a field ends up silently empty on half an estate.
- Process identity. On the Sysmon path
process.uidis aProcessGuid, unique across reboots. Carbide supplies its own value for the same path rather than leaving it null, because content joins on it. - Path handling.
file.nameon the Sysmon path is a basename split on a backslash. A Linux path does not split that way, so the Linux agent does its own basename resolution rather than inheriting the Windows one. - Timestamps.
timeis epoch milliseconds on both paths. An agent emitting seconds is wrong by a factor of a thousand, which reads as a host with no recent activity rather than as a broken agent.
Sysmon events beyond process creation
Process creation is the one everybody starts with, but the channel carries more and Caver classifies it rather than dropping it into a generic bucket: file events become File System Activity, CreateRemoteThread and ProcessAccess become Memory Activity, ImageLoad becomes Module Activity, and DNSQuery becomes DNS Activity. Content written against those classes covers Sysmon hosts today and Carbide hosts as the equivalent Linux collection lands.
Windows, stated plainly
Carbide ships on Linux. On Windows, Sysmon through the collector is the supported path and is what the content assumes. Whether ETW alone can supply the same fields without Sysmon installed is an open research question with a written spike behind it, not a shipped capability, and it is the gate on a native Windows agent.
Deployment
The agent installs as a managed service with a unit file, so it starts on boot and survives a reboot. Configuration and the ingest token come from a mode 0600 environment file rather than the command line, because /proc/<pid>/cmdline is world readable and a token passed as an argument is visible to every local user.
Updates are signed with a key whose public half is built into the agent, so a compromised update service can withhold updates but cannot cause one to be installed. Rollout is staged by cohort, and a version that will not come up puts the previous one back on its own, using the same install path an ordinary update uses so the rollback is not a route first attempted on the day it is needed.
A rebuilt engine for speed, scale, and the long run.
Caver's compute plane was rebuilt in Go and Rust for throughput and horizontal scale, on the same open OCSF lake, so nothing about your data model breaks. Speed and scalability are the enablers for the economics: cheaper storage and faster queries than the volume-priced incumbents, on an engine built to scale out.
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.
CAVER_SEARCH_BASE_REUSE_*. Panels sharing a base search reuse it instead of re-running the scan.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.
CAVER_SEARCH_BASE_REUSE_*, so panels share one scan instead of each re-reading the lake.CAVER_LAKE_DATA_CACHE_MB. Repeat queries over the same columns skip the object-store round trip entirely.Storage that reports its whole footprint
The lake now publishes its true on-disk footprint beside the parquet-only number it has always published, and surfaces the metadata portion on Lake Health.
This matters because the parquet-only figure is the flattering one. Counting only data files makes the storage-efficiency ratio look better than the disk actually is, and a customer would have discovered the difference from their own cloud bill rather than from us.
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 5,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: selectionSigma Integration
Caver ships full first-class Sigma support, the community standard for vendor-agnostic detection rules.
enabled: false; enable per-category after tuning thresholds for your environment.caver-sigma import ./rules/ -o ./cavern/ to transpile any Sigma rule file or directory. caver-sigma stats ./rules/ for transpile coverage report.sigma-sync.yml GitHub Actions workflow polls SigmaHQ releases weekly. When a new release drops, it transpiles, opens a PR with a coverage delta table, and waits for your review.# 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.
| Multiplier type | Factor |
|---|---|
| Admin account | 2.0× |
| Critical production asset | 1.875× |
| Service account | 0× (suppressed) |
| Default (standard user) | 1.0× |
Content Packs (160+)
| Category | Packs | Rules |
|---|---|---|
| AI / LLM | ai_usage · ai_coding_assistants · shadow_ai · langflow · managed_llm · litellm · portkey · cloudflare_ai_gateway · mcp · vector_db · embeddings · rag_pipelines · agent_frameworks · browser_agents · voice_ai · image_generation · fine_tuning · on_prem_inference · huggingface · model_supply_chain · prompt_library_drift · ai_governance · ai_cost_governance · ai_data_governance | 200+ |
| ATT&CK / Endpoint | art_endpoint · credential_access · defense_evasion · discovery · initial_access · lateral_movement · persistence · command_and_control · execution · privilege_escalation · collection · exfiltration · impact | 240+ |
| Host telemetry | win_security_eventlog · sysmon · linux_auditd · powershell_scriptblock · osquery · yara · clamav | 140+ |
| Edge / Network | edge_security · network · network_infrastructure · firewall_syslog · rmm_tools | 75+ |
| OT / ICS | industrial_bacnet · industrial_dnp3 · industrial_modbus · industrial_iec104 · industrial_s7comm · industrial_ethernet_ip · scada_windows · it_ot_correlation | 95+ |
| Cloud platforms | aws_cloudtrail · aws_guardduty · azure_ad · google_workspace · k8s · m365_audit · devsec_correlation · cloud_correlation | 220+ |
| EDR / Endpoint | crowdstrike_falcon · sentinelone · microsoft_defender · wazuh · sysdig_secure · edr_common · edr_to_cloud_correlation | 130+ |
| SaaS audit (70+ adapters) | okta · slack_audit · github_audit · salesforce_audit · zoom_operations · and 65+ more | 380+ |
| Community (Sigma) | Auto-transpiled at every SigmaHQ release, 100% of corpus mapped | 2,960+ |
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.
Recent content packs
- PHI access — the chart-access review content a hospital is actually buying, judged against each role's own normal.
- Imaging — the estate a hospital did not know it had, and the retrieve nobody recognizes.
- Healthcare taxonomy bucket — a place for clinical content to live, so medical packs are findable rather than scattered.
- Six industrial protocol packs — see OT / ICS.
Supported Technologies
Caver ships out-of-box integrations for 160+ 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
KubernetesIdentity & SSO 10
Okta
Auth0
JumpCloud
Duo Security
OneLogin
Keycloak
1Password
BitwardenAzure AD / Entra
Google WorkspaceProductivity & Collaboration 12
Microsoft 365
Slack
Microsoft Teams
Zoom
Cisco Webex
Mattermost
Discord
Intercom
Box
Dropbox
Notion
AsanaDeveloper & DevOps 14
GitHub
GitLab
Jira
Confluence
CircleCI
Buildkite
LaunchDarkly
Snyk
Linear
Tines
PostHog
Sysdig
MongoDB Atlas
SnowflakeEDR & Endpoint 10
CrowdStrike
SentinelOneMicrosoft Defender
Carbon Black
Trend Micro
Wazuh
ClamAV
YARA
osquery
FalcoNetwork & Perimeter 11
TailscaleCloudflare Zero Trust
Cisco MerakiCisco Umbrella
Fortinet
Palo Alto Networks
Ivanti
Citrix
Suricata
Zeek
WiresharkCloud Security 8
Wiz
Lacework
TenableSysdig SecureMicrosoft SentinelAWS GuardDutyAWS SecurityHub
TrivyAI & LLM 12
OpenAI
AnthropicMicrosoft CopilotAmazon BedrockAzure OpenAIGoogle Vertex AI
Hugging Face
LiteLLM
Portkey
LangFlow
Ollama
LM StudioOT / ICS 7
Dragos
Claroty
Siemens
Rockwell / Allen-Bradley
Schneider Electric
ABB
HoneywellSales, CRM & Support 15
Salesforce
HubSpot
Stripe
Shopify
Zendesk
ServiceNow
PagerDuty
Twilio
SendGrid
Postmark
Mailgun
Mimecast
Atlassian Statuspage
Opsgenie
DatadogObservability & Analytics 10
Splunk
Grafana
Prometheus
Elastic
KibanaLoki
OpenTelemetry
Vector
Apache Kafka
ConfluentIf you do not see a tool you rely on, suggest it and we will scope it. New integrations land as a caver-collector receiver plus a CAVERN content pack, typically inside a single release cycle.
Already have a dashboard you love? Keep it. Caver registers as a peer on most search tools (Splunk, for example), so your existing dashboards, saved searches, and correlation rules keep running unchanged against the OCSF lake. Federation modes ship for Elastic / Kibana, Microsoft Sentinel, Sumo Logic, Datadog, and growing. See deployment options →
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
Change windows, so approved work stops looking like an attack
Approved change work generates activity that looks exactly like what detections fire on. Most SOCs hand-wave it. Caver makes it a queryable object: a change advisory is a time window plus a scope selector, carrying the change id and the approver.
It de-weights; it does not blind. By default an in-scope finding has its contribution to the entity's risk score multiplied down rather than dropped, and every adjustment is attributed back onto the finding with the change id and the original score. An analyst sees “lowered because CHG-1234” rather than a detection that silently went missing.
| Mode | Behavior |
|---|---|
deweight (default) | Risk multiplied down. Still alerts. |
suppress | Contributes no risk. Still alerts. |
| Full suppression | Available, and audited exactly the same way. |
ChatOps
Commands can arrive from Slack or another chat platform, and the source is recorded on the command rather than flattened into “automation”, so an audit trail says who asked and where they asked from.
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.
forensic_acquire playbook step. Standard E01 / AFF4 / raw supported.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.
| Field | What it proves |
|---|---|
artifact_sha256 | The bytes have not been altered since the moment of ingestion |
ingest_timestamp + Ed25519 signature | The artifact existed in Caver no later than this moment, signed by a Caver-controlled key |
ingest_actor | Which user / playbook / API caller deposited the artifact, with their IdP identity at time of write |
ingest_source_event_id | Which CAVERN notable / SLAM case / ECHO episode triggered the deposit, fully linkable |
ledger_merkle_root | The state of the entire Locker ledger at the moment of ingestion, so the ledger itself cannot be edited without detection |
access_log | Every subsequent read, including who, when, from what IP, with what justification (free-text + dropdown) |
retention_policy | The retention class that applied at ingest, including any legal holds layered on later |
verification_payload | Bundled SHA-256 + signature + ledger proof, downloadable as a standalone JSON for independent verification |
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 0Retention & 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.
| Policy class | Default retention | Common use |
|---|---|---|
p1_critical | 10 years | P1 / P2 incidents, regulated industries |
standard | 7 years | Default for all SLAM cases |
operational | 3 years | Low-severity tuning / FP investigations |
research | 1 year | Threat-hunt artifacts, intel-gathering |
legal_hold | Indefinite | Applied on top of any class, blocks deletion until released |
regulatory_lock | Per-policy (HIPAA 6y, PCI 1y after closure, SOX 7y) | Auto-applied when the affected asset is tagged with the compliance regime |
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/zipPython 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 deletionECHO 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.
| KPI type | Use case | Default thresholds |
|---|---|---|
throughput_rps | Requests per second | warn < 60% peer · crit < 30% |
latency_p50 | Median response time | warn > 2× baseline · crit > 5× |
latency_p95 | 95th-percentile latency | warn > 2× · crit > 5× |
latency_p99 | 99th-percentile latency | warn > 2× · crit > 5× |
error_rate | HTTP 5xx % | warn > 1% · crit > 5% |
saturation | CPU / memory / queue depth | warn > 70% · crit > 90% |
availability | Uptime % over window | warn < 99.5% · crit < 99% |
notable_count | SLAM notables per window | warn > 1 · crit > 3 |
anomaly_count | UBA anomalies per window | warn > 2 · crit > 5 |
auth_failure_rate | 4xx auth fail % | warn > 5% · crit > 15% |
data_freshness | Time since last event | warn > 5m · crit > 15m |
custom | Any SPL/SQL/KQL expression | operator-defined |
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"} 2Build a board, and every panel rides one scan.
Dashboard Studio turns any saved search into a live board of charts. Pick a visualization, tune it in a per-panel Configure pane, clone a shipped dashboard and make it your own. Underneath, a dashboard runs its base search once and every panel reuses that result, so a busy board never becomes a pile of redundant scans.
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.
stats, timechart, or chart command produces has a native visualization, so the same search that drives a detection also drives a panel.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.
A content pack is detections plus the board that makes them legible. When you subscribe a pack, its signature dashboard installs alongside the rules, already wired to the CLASS indexes the pack targets. Clone it to tailor thresholds or palette, and your edits live in My Dashboards while the shipped original keeps updating with the pack.
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.
When a board loads, its base search runs once and lands in ephemeral Parquet (TTL-bounded, capped, tuned via CAVER_SEARCH_BASE_REUSE_*). Each panel then runs its own stats, timechart, or top against that cached base rather than re-reading raw events. The cache is disposable by design: it accelerates, it never becomes a second source of truth.
This is the same base-reuse machinery described in the Engine section, shipped and on. It is separate from summary-table acceleration, a precomputed-rollup approach that is on the roadmap and not yet enabled anywhere.
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.
| Peer source | Cluster basis | Used by models |
|---|---|---|
| Identity graph (Azure AD / Okta / Google) | Manager · department · title | Department-outlier · role-outlier · manager-cluster |
| Security groups | Group membership intersect | Privilege-footprint · resource-set |
| Access patterns | K-means on application access histogram (30d) | Access-path · session-pattern |
| Asset graph | Service tag · tier · environment | Asset-tier outlier |
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.
| ATT&CK tactic | UBA models that fire here |
|---|---|
| Initial Access (TA0001) | First-time-app · impossible travel · MFA bypass · DGA shape |
| Execution (TA0002) | Rare process · LOLBin spike · unsigned binary · code injection |
| Persistence (TA0003) | Registry autorun · scheduled task · disabled-account reactivation · service account drift |
| Privilege Escalation (TA0004) | Token impersonation · privilege escalation · LSASS access · driver load |
| Defense Evasion (TA0005) | Token reuse · DLL sideload · unsigned binary · CloudTrail tamper |
| Credential Access (TA0006) | Password spray · credential dump · LSASS access · KMS key abuse |
| Discovery (TA0007) | Port scan · IAM enumeration · schema enumeration · column-mass-select |
| Lateral Movement (TA0008) | SMB/RDP lateral · token impersonation · cross-account assumption |
| Collection (TA0009) | Bulk export · sensitive-table access · S3 mass download |
| Exfiltration (TA0010) | Low-and-slow exfil · DNS tunneling · dump-to-stage anomaly |
| Command & Control (TA0011) | Beaconing detector · DGA shape · DNS tunneling · TLS fingerprint anomaly |
| Impact (TA0040) | Resource-deletion burst · KMS key abuse · disabled MFA admin |
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:
| Primitive | Description |
|---|---|
onboard_sample | Ingest a sample event → propose OCSF mapping → generate source config + rule + fixture |
nl_to_config | Convert plain-language description to a caver.toml stanza or CAVERN rule YAML |
forge_rule | Author a new CAVERN rule from a threat description or CVE |
replay_against_history | Run a rule against historical Parquet data, count fires, estimate FP rate |
lint_config | Validate caver.toml, CAVERN rule, or pipeline config against the schema |
enrich_text | Look up an IP, domain, hash, or CVE in threat-intel feeds |
explain_rule_silence | Why hasn't this rule fired in N days? (data gap, filter, threshold) |
tune_threshold | Propose + apply a score/threshold change based on FP/TP history |
start_canary | Route X% of traffic through a new rule/pipeline config for A/B validation |
pipeline_diff | Compare two pipeline configs in plain language |
compliance_report | Generate coverage map for SOC 2, PCI, HIPAA, controls mapped to CAVERN rules |
Vulnerability Center
A vulnerability list sorted by CVSS tells you what is severe. It does not tell you what to fix. Caver joins each per-CVE, per-asset finding against the asset registry and lifts criticality, owner and risk score onto the finding, then re-ranks by a priority score that folds severity together with how much the affected asset matters.
The point is the re-rank: a medium CVE on a crown-jewel asset should
out-rank a high CVE on an unclassified box. An asset with no registry
record keeps a criticality of unknown and is never dropped from the
list.
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.
| Feed | What you get | Indicator types | Cadence |
|---|---|---|---|
| RedEye Intel Feeds First-party | RedEye's own CVE-to-detection feed: newly published CVEs turned into Sigma and SPL detections, published as STIX 2.1 / TAXII 2.1 at feeds.redeyesecurity.com (TAXII endpoint taxii.redeyesecurity.com). Claim a free access token to subscribe. | CVE · Sigma · STIX bundle | hourly |
| abuse.ch URLhaus | Malicious URLs, live + recent | URL · domain · IP | 5m polling |
| abuse.ch MalwareBazaar | Malware samples, family + tags | SHA256 · YARA · family | real-time |
| abuse.ch ThreatFox | IOCs tied to malware family | IP · domain · URL · hash | 5m polling |
| abuse.ch Feodo Tracker | Botnet C2 IPs, Emotet / Dridex / TrickBot / QakBot / IcedID / BumbleBee | IP · port · family | hourly |
| abuse.ch SSL Blacklist | Malicious SSL/TLS certificates | SHA1 · family | daily |
| abuse.ch YARAify | YARA rules + sample matches | YARA · hash | 30m polling + webhook |
| LevelBlue OTX (formerly AlienVault) | Curated pulses with attribution + ATT&CK tagging | IP · domain · URL · hash · email · CVE | per-pulse subscription |
| OpenPhish Community | Verified live phishing URLs, last 5h | URL · target brand | 5m polling |
| CISA Known Exploited Vulnerabilities (KEV) | CVEs with confirmed in-the-wild exploitation + remediation due dates | CVE · vendor · product | daily |
| CISA AIS (Automated Indicator Sharing) | STIX/TAXII 2.1 indicator feed, US government and partner indicators | STIX bundle (full) | real-time TAXII |
| CISA CSAF Advisories | Structured security advisories from CISA + ICS-CERT | CVE · vendor · product | real-time |
| CISA / US-CERT Alerts | Human-readable APT bulletins + threat alerts | narrative + indicators | RSS / Atom |
| MISP (community sharing) | Plug into any MISP instance you have access to | full MISP attribute set | per-event subscription |
| Emerging Threats Open | Proofpoint community Suricata rules + IOCs | signature · IP · domain | daily |
| Spamhaus DROP / EDROP / ASN-DROP | Spam / hijacked / criminal hosting netblocks | CIDR · ASN | daily |
| Shodan InternetDB (free tier) | CVE-to-IP mapping, exposed services | IP · CVE · port · banner | on-demand lookup |
| GreyNoise Community | Benign internet-scan suppression (so an SSH scan does not light up every CAVERN rule) | IP · classification · noise score | on-demand lookup |
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.
| Feed | Coverage | Auth |
|---|---|---|
| Recorded Future | Full Intelligence Card API, risk lists, alerts | API token |
| Mandiant Advantage / Google Threat Intel | APT profiles, IOCs, vulnerability intel | OAuth2 service principal |
| CrowdStrike Falcon Intelligence | Adversary tracking, IOCs, MalQuery hash lookups | OAuth2 client credentials |
| VirusTotal Enterprise | File / URL / domain / IP reputation lookups, intelligence searches | API key |
| Anomali ThreatStream | Aggregated threat intel platform feeds | API key |
| OpenPhish Premium | Full historic feed + target-brand attribution + WebSocket live stream | API key |
| abuse.ch Commercial | Commercial use of all abuse.ch feeds with no rate limits | Auth-Key header |
| GreyNoise Enterprise | Full-context noise dataset, IP scan history, RIOT trust list | API key |
| DomainTools Iris | Domain whois history, hosting graph, threat scoring | API key + username |
| Mimecast Threat Intelligence | Email-borne threat intel (URLs, attachments, sender reputation) | OAuth2 |
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.
api_poll receiver against any HTTPS endpoint that returns JSON, NDJSON, or CSV. Map fields to OCSF via a small YAML config, no Python required.webhook receiver. Caver listens, normalises, and indexes.s3_sqs receiver picks it up via SQS notification, normalises, and loads it into the bloom-filter.src/caver_collector/transforms/ implementing the standard interface. Output OCSF, get the bloom-filter + enrichment + CAVERN integration for free.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:
enrich_indicator on notable creation to attach feed context: which feed first saw this IP, when, with what attribution.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
IOC feeds
Indicator feeds are indexed and joined against your data as it lands, so a match surfaces as a finding rather than as a report you have to go and read.
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)
api_key_leak_in_promptT1552 · credential accesssystem_prompt_exfil_suspectT1213 · collectionmodel_supply_chain_matchT1195 · supply chainprompt_injection_candidateT1059 · initial accessoutput_pii_leakT1567 · exfiltrationrag_indirect_injection_indicatorT1059 · indirect execdataset_poisoning_indicatorT1567 · exfiltrationcost_anomaly_per_userT1496 · resource hijackoff_hours_token_spikeT1078 · valid accountsmodel_variance_burstT1190 · exploit public appAI Content Packs (24)
ai_usageai_coding_assistantsshadow_ailangflowmanaged_llmlitellmportkeycloudflare_ai_gatewaymcpvector_dbembeddingsrag_pipelinesagent_frameworksbrowser_agentsvoice_aiimage_generationfine_tuningon_prem_inferencehuggingfacemodel_supply_chainprompt_library_driftai_governanceai_cost_governanceai_data_governanceSupported AI Tools
Gateways: LiteLLM · Portkey · Cloudflare AI Gateway · Helicone · LangSmith Proxy · Kong AI Gateway
Agents & orchestration: LangChain · LangGraph · AutoGen · CrewAI · LlamaIndex · LangFlow · MCP servers
Coding assistants: GitHub Copilot · Cursor · Codeium · Tabnine · Continue.dev · Amazon Q · Sourcegraph Cody · Windsurf
Browser / computer-use: Claude Computer Use · Browser-Use · Skyvern · Multi-On · OpenInterpreter
Voice / image / multimodal: ElevenLabs · OpenAI Realtime · Bland AI · DALL-E · Midjourney · Stable Diffusion · Flux · Replicate · Runway
Vector DBs: Pinecone · Weaviate · Qdrant · Chroma · pgvector · Milvus · LanceDB
On-prem inference: Ollama · LM Studio · llama.cpp · vLLM · TGI · TensorRT-LLM · any OpenAI-compatible endpoint
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.
MCP, with a query contract
Caver exposes an MCP surface so an assistant can query your data through a defined contract rather than by being handed a shell. Results are returned in a shape built for a model to consume safely rather than a raw marshalled blob.
Ask in plain language
Natural-language questions are translated into the query languages Caver already speaks, so the assistant is a sixth way to ask rather than a separate system with its own answers. The generated query is shown, so an analyst can read what actually ran instead of trusting a summary.
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 (36)
| Receiver | Purpose | Protocol / source |
|---|---|---|
hec | Splunk HTTP Event Collector ingress | HTTPS · JSON / raw events |
caver_hec_replay | Replay recorded HEC NDJSON payloads | file / S3 NDJSON archive |
syslog | Standard syslog ingress | RFC3164 + RFC5424 · TCP/UDP/TLS |
tcp_line | Reliable newline-delimited TCP | TCP framed by newline |
udp_packet | Generic UDP datagram (no syslog framing) | UDP raw |
file_tail | File log tailing with checkpointing | Local files · rotation aware |
webhook | Generic HTTP POST endpoint for SaaS push | HTTPS · arbitrary JSON |
otlp_http | OpenTelemetry Protocol over HTTP | OTLP/HTTP · logs/metrics/traces |
kafka_consumer | Kafka topic consumer with offset tracking | Kafka 2.x+ · SASL/SCRAM · mTLS |
kinesis_firehose | AWS Kinesis Firehose HTTP push | HTTPS · Firehose record format |
s3_sqs | S3 object notifications via SQS queue | S3 → SQS → object fetch |
caver_lake_replay | Replay caver lake Parquet partitions | OCSF Parquet · time-bounded |
windows_event_log | Windows EvtSubscribe live channel subscription | WMI EvtSubscribe |
uf_compat | Splunk Universal Forwarder S2S inbound | Splunk S2S binary protocol |
api_poll | SaaS API poller (70+ adapters) | HTTPS · per-vendor pagination |
modbus_tcp | Modbus TCP industrial protocol | Modbus TCP · function code 1-127 |
dnp3 | DNP3 SCADA protocol monitor | DNP3 TCP/UDP |
bacnet | BACnet/IP building automation | BACnet/IP UDP |
iec104 | IEC 60870-5-104 power grid SCADA | IEC 104 TCP |
ethernet_ip | EtherNet/IP (Allen-Bradley CIP) | EtherNet/IP TCP/UDP |
s7comm | Siemens S7-300/400/1200/1500 PLC | S7Comm TCP |
host_metrics | CPU, RAM and disk of the box the collector runs on | Local system counters |
journald | Tails the systemd journal | journalctl |
macos_unified_log | macOS unified log | log stream / log show |
script_exec | Runs a configured binary on an interval, captures stdout | Local process stdout |
snmp | Discovers and polls infrastructure telemetry | SNMP v1 / v2c / v3 · net-snmp |
netflow_v5 | NetFlow v5 flow records to OCSF Network Activity | UDP · NetFlow v5 |
pcap_tail | Packet capture, the front door for the OT decoders | libpcap · live or file |
kubernetes_audit_webhook | Kubernetes API server audit log | HTTPS · K8s audit webhook |
dicom | DICOM upper layer decode and OCSF normalization | DICOM DIMSE |
hl7_mllp | HL7 v2 decode and OCSF normalization | HL7 v2 over MLLP |
opc_ua | OPC UA binary decode | OPC UA binary |
goose | IEC 61850-8-1 GOOSE passive decode | L2 multicast · passive |
mms | IEC 61850 MMS observation | MMS on TCP 102 |
profinet | Passive L2/RT, DCP and PNIO-CM decode | Profinet · passive L2 |
scl | Imports the substation engineering model | SCL / CID file |
SaaS API Adapters (70+)
Transformation & Normalization (44)
SNMP: discovery and polling
The OT receivers speak plant-floor protocols. SNMP is the opposite problem: it is what every switch, router, firewall, UPS, printer and server in the building already speaks, and most estates have never pointed anything at it. The snmp receiver does two jobs on a schedule, across v1, v2c and v3.
Discovery
Sweep one or more CIDRs and probe every reachable host, trying each configured SNMP version. v1 is tried first and is never dropped, because old environments still run it and a sweep that skips it reports an empty rack. Each device that answers emits a discovery event carrying the host, the version that actually worked, and sysDescr, sysObjectID and sysName, so the inventory you found is itself queryable telemetry rather than a config file. Devices found this way are added to the poll set.
Polling
For every discovered or explicitly configured device, GET the metric OID set on an interval. Tables are walked into one event per instance, one per interface, per disk, per core, each carrying its own label from ifDescr or ifAlias or the storage description. That is the difference between charting eth0 and charting a dynamic dotted column, and interface throughput arrives as a rate rather than a counter you have to difference at search time.
Two modes, one binary
| Mode | What it does |
|---|---|
sensor | Default. Scans subnets and polls a remote device list from one box, the appliance pattern. |
localhost | Polls 127.0.0.1 only, a light per-host footprint. |
There is no second installer and no separate SNMP product. The backend is the net-snmp CLI, the reference implementation, so v1, v2c and v3 all behave the way the rest of your tooling expects. On Linux install snmp or net-snmp-utils; macOS ships it.
Sensor mode is the current default, which makes it easy to end up with every collector in an estate sweeping the same ranges. The cost is the probing rather than the duplicate records. A /24 is 254 hosts and each is tried across the configured SNMP versions, so thirty collectors pointed at one subnet is on the order of ninety probes per device per sweep. Old gear is not always robust to that, and sequential community-string attempts arriving from thirty sources looks like credential brute force to your own IDS.
It also skews the numbers. Interface throughput is a rate derived from counter deltas per polling collector, so several collectors polling one interface produce several independent series rather than one. Point sensor mode at a subnet from one collector, and use localhost mode on the rest.
Detail levels
| Level | What is collected |
|---|---|
simple | Default. A curated OID set including CPU, RAM and disk. |
detailed | The full tree, printable values only. |
experimental | The full tree including binary values, hex encoded. |
Full walks default to the 1.3.6.1 root, which is standard MIB-2 plus private enterprises, capped per device so one chatty switch cannot dominate a cycle. Events land under the snmp index by default, split across snmp:discovery, snmp:metric, snmp:interface, snmp:storage and snmp:processor sourcetypes, so a dashboard reads one shape and does not have to sort device scalars from per-interface rows itself.
Not yet: traps
This receiver polls and discovers. It does not listen for SNMP traps on UDP 162, so a device that only sends traps is not covered by it today. Traps are tracked separately; if that is your source of truth, say so and it moves up.
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.
remap transform.transform processor factory.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: parquetCaver App Store.
The collector ships lean: core plus sources plus the OCSF VRL framework. Per-vendor capability arrives as apps, versioned bundles that map a vendor's data fully to OCSF. A deployment-server subscription pipeline pushes app updates to subscribed collectors automatically. OCSF-mapped, versioned, subscribable.
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.
| App contents | What it provides |
|---|---|
| Source config | Receiver, poll, or webhook wiring for the vendor |
| OCSF VRL mapping | Full field-level normalization of the vendor's data to OCSF |
| Schema binding | Which OCSF classes and CLASS index the app writes to |
| CAVERN content | Detection rules and content packs tuned for that source |
| Version + changelog | SemVer bundle, so upgrades are explicit and reversible |
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)
stage_alerts/, queryable like any other lake data.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.
| ID | Type | Default | What it covers |
|---|---|---|---|
nvd | NVD | enabled | NIST canonical CVE feed (CPE-matched, CVSS-scored) |
cisa-kev | CISA KEV | enabled | CISA Known Exploited Vulnerabilities. Federal patch deadline |
osv | OSV | opt-in | OSV.dev open-source ecosystem vulnerabilities |
ghsa | GHSA | opt-in | GitHub Security Advisories |
zdi | RSS | opt-in | Zero Day Initiative published advisories |
msrc | MSRC | opt-in | Microsoft Patch Tuesday CVRF bulletins |
cisco-psirt | Cisco openVuln | opt-in | Cisco PSIRT advisories |
project-zero | Atom | opt-in | Google Project Zero public bug tracker |
github-advisory-db | Git repo | opt-in | github/advisory-database canonical mirror |
vulncheck-nvd | VulnCheck | opt-in | VulnCheck NVD++ commercial mirror (faster + enriched) |
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_TOKENPipeline
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 1hCaver-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
| Command | Description |
|---|---|
cve-forge feeds list | Show the registry + enabled state |
cve-forge feeds enable <id> | Enable a feed (writes to ~/.config/cve-forge/feeds.yaml) |
cve-forge feeds disable <id> | Disable a feed |
cve-forge scrape --hours N | One-shot, pull from every enabled feed for the last N hours |
cve-forge scrape --feeds-config /path/to/feeds.yaml | Use a custom feed config file |
cve-forge loop --interval 1h | Run autonomously, scrape every interval |
cve-forge replay <cve_id> | Re-process a specific CVE (debugging / re-grounding) |
cve-forge stats | Coverage stats: how many CVEs in the last 7d, how many staged, how many not_applicable, cost |
cve-forge cost --since <date> | LLM token cost report |
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.
| Aspect | Caver Forge | CAVERN |
|---|---|---|
| Authoring | Autonomous (Claude-generated) | Hand-authored by detection engineers |
| Trigger | New CVE published | Threat model / hypothesis / incident |
| Speed | Minutes to hours after CVE drop | Days to weeks (proper engineering cycle) |
| Output | stage_alerts/ Detection Finding rows | Production CAVERN rules, RBA-scored notables |
| Alerting | None (staged, batch) | Real-time, oncall paging via SLAM |
| Tuning | Per-CVE auto-regenerate | FP/TP feedback loop with caver-cavern auto-tune |
| Cost model | ~$0.01 per CVE in LLM tokens | Detection engineer time |
| Promotion | Stage to production via SLAM Phase-5 bridge | Already in production |
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
The command-chain model
Most industrial security products watch for known-bad traffic or list known vulnerabilities. Neither sees the plant that is running exactly as programmed and still cannot meet its target.
Caver learns the control conversation from the wire alone. Point it at a SPAN port and it learns what the plant normally says to itself: no project file, no engineering artifact, no integrator who left in 2019. It is the only OT capability that works on day one at a site that will never hand you anything.
It is a positive model, not an anomaly score. Plant command traffic is small, repetitive and machine-generated, so enumerating what is valid is tractable. Everything outside the learned set is suspect. There are no thresholds pulled out of the air and no “anomaly score of 0.73” that means nothing to an operator: every finding names the dimension that broke and shows the learned expectation beside what was observed.
Goal feasibility
Beyond “is this traffic normal” Caver asks whether what the operator is trying to do is achievable at all. Units are carried and checked rather than assumed, and a verdict names the binding constraint instead of returning a pass or a fail. Mixed units are refused rather than silently summed, because a quietly wrong answer about a process is worse than no answer.
Deviation cause classification
A deviation is classified by why it happened rather than forced into an incident shape. A signal that is a process problem, a maintenance problem or a staffing problem reads as what it is, instead of arriving as a security alert somebody has to translate.
Operating-practice baselines
Baselines are sliced by shift, crew and season, because a plant does not run the same way at 3am in February as at noon in July, and a single baseline across all of them reports the difference as an anomaly every time.
Competence and staffing drift
Detects the slow loss of operating skill in a plant: corrections shortly after actions, hesitation, and the drift that follows a downsizing. It is the finding that shows up months before an incident does.
Operations monitoring, next to the security screens
The screen an operator actually opens at 6am, so the same data serves the control room and not only the SOC.
How the OT model is validated
A simulated water plant exercises the models end to end. It found four defects in the two models it was built to test, which is the point of building it: we do not have a plant of our own, so the alternative was validating OT claims against nothing.
Healthcare & clinical
Caver reads the clinical estate through the standards healthcare already agreed on, rather than one integration per vendor. Nine subsystems cover EHR access, the clinical message bus, imaging, connected devices and the building itself. See the full compatibility list.
EHR access, four formats into one shape
Healthcare standardised audit export years ago and the largest vendors emit an ordinary SIEM feed. Caver normalises all of it into a single access record so the detections never learn which vendor produced them.
| Format | Where it comes from |
|---|---|
CEF / LEEF | Epic's own security and privacy feed, emitted natively |
ATNA | IHE audit records on the RFC 3881 model, over syslog |
FHIR AuditEvent | The modern representation, managed jointly by HL7, DICOM and IHE |
| Vendor extracts | Oracle Health P2Sentinel Listener, Meditech Audit Trail and MIS Dictionary |
Fidelity travels with the result. The most valuable field is the recorded reason an access was legitimate: care team, treating department, ancillary order. CEF, LEEF and ATNA have no field for it; FHIR AuditEvent can carry it and only does when the sender populates it. Where it is missing, behavioral detection degrades to counting, and Caver reports the degradation rather than presenting a confident number. An integration that silently dropped it would leave a customer believing their detections were behavioral when they had become volume counts.
The clinical message bus
Caver reads HL7 v2 from a mirror of the traffic and is never in the message path, so it cannot delay, alter or drop an order or a result. It learns each interface's normal conversation and reports the one that quietly stopped, which is a patient-safety event that no security tool usually surfaces.
Imaging, without reading an image
Caver reads DICOM on the wire, which every modality and archive speaks, so no vendor cooperation is required. The parser stops at the pixel data and never reads it. That is a privacy decision first, and the reason imaging monitoring costs no meaningful storage second. Retrieves to a destination the estate has never used lead the alert list.
Connected device triage
Device triage sorts on change, not on vulnerability count. An unpatchable infusion pump behaving exactly as it always has is not urgent; the same pump that started talking to something new is. Devices are identified from network behavior and manufacturer hardware address, and a device from a vendor Caver cannot name is still monitored, because a tool that only watched equipment it recognised would be blind to exactly the unusual equipment worth watching.
Patient identity
To spot a pattern you have to know it is the same patient. To be safe you would rather not hold their name. Caver converts the identifier into a salted one-way key: the same patient produces the same key so activity links across HL7, imaging and EHR records; the key cannot be reversed into a medical record number; and the salt is unique to your deployment, so the same patient at two hospitals produces two different keys and the sites cannot be cross-referenced, including by us. Carrying the real identifier is off by default and is reported when it is on, so an auditor sees it without reading a config file.
Access attribution is reported as attributable,
questionable or not attributable rather than as a
single confident verdict.
The building is clinical infrastructure
Caver reads BACnet and judges room pressure and air change rates against ASHRAE 170 and the FGI Guidelines, with the citation on the finding, because an infection preventionist works from those documents and a finding that points at their own standard starts a different conversation from one that points at our opinion.
Room class is declared by the operator and never guessed from a point name, and a suite that can serve either purpose is refused rather than assumed. BACnet reliability travels with each reading, so a point that is out of service is not believed: a stuck sensor reading a perfect value is indistinguishable from a healthy one, and Caver says so.
IsSecurityFinding() == false. Caver
produces findings that are not security findings, and does not dress them up as
breaches to make them sound urgent.
HIPAA mapping
Requirements are mapped to what Caver does with the citation attached, and the mapping states where Caver does not help at all rather than claiming partial credit. The 2025 HIPAA Security Rule proposal is not law and is not enforceable today; Caver builds readiness for it and does not sell it as a mandate.
Compliance, CUI & FIPS
Regulated deployments ask three questions early: what happens to the data at rest, what happens to markings that travel with a document, and whether the cryptography is the approved kind. Caver answers all three in code rather than in a policy document.
Encryption is a precondition, not a setting
When you tell Caver its lake holds protected data, it will not start against storage it cannot confirm is encrypted. That is a refusal, not a warning banner: a deployment that would have quietly written PHI or CUI to an unencrypted bucket does not come up.
CUI markings and NIST SP 800-171
Caver understands CUI markings from the NARA registry, the difference between CUI Basic and CUI Specified, and limited dissemination controls. Controls are mapped to NIST SP 800-171, which is the DFARS baseline, and the mapping is exportable as evidence rather than transcribed by hand into a spreadsheet.
FIPS, stated precisely
Caver builds and runs in FIPS 140-3 mode against the Go Cryptographic Module. That is support for the mode. It is not validation of the product, and it never will be. A CMVP certificate is issued to a module, not to software that uses one, so “Caver is FIPS validated” is not a sentence we write, and a test fails the build if the statement ever drifts into claiming otherwise.
The same discipline applies to CMMC: CMMC certifies an organization, never a product. No tool can be CMMC certified, and a vendor claiming otherwise should be asked which C3PAO issued it.
Compliance reporting
Framework posture is generated from your own environment rather than from a questionnaire, and exported signed. Ten frameworks ship built in.
Compliance API
Framework posture is available over a JSON HTTP surface, so an auditor's evidence request or a GRC platform can pull the current state directly instead of waiting on somebody to export a spreadsheet.
Migration & federation
A platform you have run for years has a consulting ecosystem, a hiring pool that already knows its query language, and a decade of your own custom content. Those are real switching costs and no architecture argument makes them disappear. So Caver is built to run beside what you have and let the comparison be measured rather than promised.
Run alongside, then decide
Caver can register as a Splunk search peer, so existing searches reach it without being rewritten, or federate with Elastic, Microsoft Sentinel, Sumo Logic and Datadog. Both systems answer the same question during the trial and you compare the answers on your own data.
What comes across
| From | What is imported |
|---|---|
| Splunk | Searches and saved content, plus ITSI service definitions and UBA models |
| Elastic | Detections and saved objects |
| Microsoft Sentinel | Analytics rules |
| Microsoft Defender | Custom detections |
| IBM QRadar | Rules and building blocks |
| SigmaHQ | The open rule standard, directly |
Detection content is mapped to Sigma and tagged to MITRE ATT&CK, so your coverage is expressed in terms an auditor and a peer organization both recognise rather than in a private taxonomy.
Four ways to start
- Full migration, with a practice run before cutover.
- Alongside your current SIEM, while your team checks coverage.
- Collection only, sitting in front of your current tool with no disruption.
- One piece at a time. Take the Evidence Locker, AI monitoring or compliance reporting without replacing anything.
One command
The importers sit behind a single caver-migrate entry point that
routes to the right one for the platform you are leaving, so a migration is one
command with a dry run rather than a runbook per product.
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
Caver vs Splunk
An honest comparison of Caver against Splunk Enterprise and Splunk Cloud. What Splunk does well, where Caver wins, and how to decide.
Splunk is the platform most teams compare Caver against, because Splunk is the platform most teams are running today. This page is the honest comparison.
At a glance
| Splunk Enterprise / Cloud | Caver | |
|---|---|---|
| License model | Ingest-per-day (Splunk Enterprise) or workload pricing (Splunk Cloud). Notoriously hard to predict. | Per-deployment, transparent license-key. No per-GB meter. |
| Cost trajectory at scale | Grows with telemetry volume. | Flat per deployment. |
| Cold-data search | Requires rehydration from frozen / archived buckets to a hot tier. Slow and expensive. | Native search over object storage. No rehydration. |
| Storage format | Splunk proprietary buckets. | Parquet, iceberg, and similar open formats. |
| Query languages | SPL. | SPL + KQL + SQL natively, all on the same backend with a language toggle. Plus AI agents over MCP, Grafana, Trino, and Athena against the same OCSF Parquet lake. |
| Forwarders | Universal Forwarder, per-agent licensing implications. | Pairs with caver-collector or your existing forwarders. No per-agent license. |
| Deploy time | Quarters for enterprise rollout. | Days for a working pilot. |
| App ecosystem | Splunkbase: largest catalog (thousands), 15+ years deep. Quality varies; many apps abandoned or shallow. Field normalization left to the operator. | Curated, meticulously authored. Each vendor pack includes dashboards, saved searches, data inputs, and OCSF field mappings. Daily updates. Ships with the product, no third-party install. Migrators auto-port Splunk dashboards, saved searches, ES correlation, ITSI, UBA, and SOAR playbooks. |
| Vendor lock-in | High (proprietary format, proprietary catalog). | Low (open storage formats, no proprietary catalog). |
| OT / ICS coverage | Splunk Industrial Asset Intelligence was deprecated in 2023. What’s left is community Splunkbase apps and the OT Security Add-on, both layered on the same general-purpose stack. No first-class industrial protocol decoding. | caver-industrial: passive deep-packet decoders for BACnet/IP, S7Comm, IEC 60870-5-104, DNP3, Modbus TCP, EtherNet/IP, OPC-UA. Framework alignment for NIST 800-82 + IEC 62443. Air-gap-friendly deploy. Curated industrial threat intel. |
| AI security visibility | Limited. | caver-aisec, purpose-built. |
Strengths
| Where Splunk wins | Where Caver wins |
|---|---|
| Ecosystem maturity. Splunkbase has been around for fifteen years. If there’s an obscure integration you need, someone has probably written it for Splunk. | Cost predictability. No quarterly ingest-license renegotiation. No “we ingested too much last month” surprises. |
| Enterprise sales motion. Splunk has the procurement story your CFO’s office already knows how to evaluate. | Cold data is just data. Years of telemetry, searchable at interactive speeds, without paying hot-tier storage cost or running a rehydration pipeline. |
| Operator pool. Hiring “a Splunk admin” is easier than hiring for any newer platform, just by candidate density. | No storage lock-in. Your data lives in object storage in standard formats. Your data engineering team can use the same data for non-SIEM purposes. |
| Query however you want. SPL, KQL, and SQL natively on the same backend. AI agents over MCP. Grafana, Trino, Athena over the same Parquet lake. Splunk gives you SPL. | |
| Content packs that ship complete. Each Caver pack includes dashboards, saved searches, data inputs, and OCSF field mappings, daily-updated. Splunkbase apps vary widely in completeness and freshness. | |
| Drop-in compatibility. Add Caver as a search peer to your existing Splunk environment. Operators don’t change tools. SPL queries fan out to both. | |
| Faster pilots. A working Caver pilot is days of work, not the multi-quarter procurement-plus-implementation cycle. | |
| OT and AI surfaces. caver-industrial and caver-aisec are first-class extensions, not bolt-ons. |
How to decide
If you have an existing Splunk investment you can’t justify ripping out, run Caver as a search peer alongside it. Use Caver for long-retention and cold-tier search; let Splunk continue to serve the workflows operators already know. The two work together.
If you’re greenfield, evaluate both. Splunk’s ecosystem maturity matters; Caver’s cost trajectory matters more if you expect telemetry volume to grow.
If you’ve already hit your Splunk license ceiling and the next true-up is the trigger for this conversation: that’s a great moment for Caver.
Talk to us about scoping, or read about how Caver works first.
Caver vs Elastic
Caver compared to Elasticsearch / Elastic Stack and Elastic Security. Open source pedigree vs. commercial focus, scale-engineering tax, and where each one fits.
At a glance
| Elastic Stack / Elastic Security | Caver | |
|---|---|---|
| License model | Open source (Apache 2.0 / Elastic License v2) + commercial subscriptions. | Per-deployment commercial license-key. |
| Storage | Elasticsearch indices. ILM moves data through hot / warm / cold / frozen tiers. | Native parquet / iceberg on object storage. |
| Cold-tier search | Frozen tier requires searchable snapshots with a performance penalty. | First-class search over object storage. |
| Query languages | KQL, EQL, ES|QL, Lucene. | SPL + KQL + SQL natively, all on the same backend with a language toggle. Plus AI agents over MCP, Grafana, Trino, Athena over the same OCSF Parquet lake. ES|QL native on roadmap. |
| Operator pool | Broad open-source community. | Smaller, focused on commercial deployments. |
| Scale engineering | Your team owns shard sizing, ILM tuning, rolling restarts, version upgrades. | We own the operational complexity. |
| Content ecosystem | Elastic integrations catalog plus community-authored content. Quality varies; many integrations require operator tuning. | Curated vendor packs that ship with dashboards, saved searches, data inputs, and OCSF field mappings. Daily updates. No third-party install. |
| OT / ICS coverage | No first-class OT product. Beats can ingest industrial telemetry via custom processors and community-authored content, but no out-of-box industrial protocol decoders and no framework-aligned content. | caver-industrial: passive deep-packet decoders for BACnet/IP, S7Comm, IEC 60870-5-104, DNP3, Modbus TCP, EtherNet/IP, OPC-UA. Framework alignment for NIST 800-82 + IEC 62443. Air-gap-friendly deploy. Curated industrial threat intel. |
| AI security visibility | Limited. | caver-aisec, purpose-built. |
Strengths
| Where Elastic wins | Where Caver wins |
|---|---|
| Open source heritage. You can run Elasticsearch entirely under your own roof, no commercial relationship required. | No scale-engineering tax. Shard layout, ILM policy, version upgrades, rolling restarts: these are operator-burden line items at any non-trivial Elastic deployment. Caver doesn’t ship that burden to you. |
| Broad community. Decades of community-authored detection content, dashboards, integrations. | Cold-tier economics. Searchable snapshots are a real Elastic capability, but they pay a measurable performance penalty. Caver’s object-storage search doesn’t. |
| Flexibility. Elasticsearch is a general-purpose engine that happens to also do SIEM. If you need full-text search, geospatial queries, log analytics, and observability all on the same platform, that’s a real story. | Query however you want. SPL, KQL, and SQL natively on the same backend. AI agents over MCP, Grafana, Trino, Athena over the same Parquet lake. Operators coming from KQL keep their language; operators on SPL or SQL get theirs too. |
| No license-key gate. Run as many clusters as you like with no per-deployment commercial conversation. | Content packs that ship complete. Each Caver pack includes dashboards, saved searches, data inputs, and OCSF field mappings, daily-updated. Elastic integrations vary widely in depth and freshness. |
| Purpose-built. Caver is SIEM-focused. Elasticsearch is general-purpose with a SIEM product layered on it. The differences show up at the edges (deployment hardening defaults, audit posture, retention guarantees). |
How to decide
If you have strong Elasticsearch operators on staff and the cluster is already healthy, Elastic Security on top of it is a reasonable answer.
If you’re paying real money in operator time for cluster maintenance, version upgrades, or shard sizing, and you’d rather that time go elsewhere, Caver removes that line item.
If you need OT / ICS visibility, caver-industrial is in a different league than what’s available for Elastic.
Caver vs Microsoft Sentinel
Caver compared to Microsoft Sentinel. Azure-bound SaaS SIEM with KQL as its native language vs Caver, which speaks KQL natively but doesn't lock you to Azure.
Microsoft Sentinel is the SIEM most cloud-native shops compare Caver against if they’re already running on Azure. The honest answer: if you’re all-in on Azure and the Microsoft ecosystem, Sentinel is hard to beat. If you’re not, or if Azure lock-in is a problem you want to avoid, Caver is the structural answer.
Worth noting up front: Caver speaks KQL natively. The Sentinel-migration story is real, not aspirational.
At a glance
| Microsoft Sentinel | Caver | |
|---|---|---|
| Deployment model | Azure-only SaaS. Multi-tenant managed by Microsoft. | Self-hosted in your cloud, on-prem, or air-gapped. BYO Azure / AWS / GCP / on-prem. |
| License model | Azure ingest + retention pricing. Variable by Log Analytics workspace and commit tier. | Per-deployment commercial license-key. Flat. No per-GB meter. |
| Cost predictability | Variable. Ingest spikes cost real money. | Predictable. Flat per deployment. |
| Cold-tier search | Archived logs require restore to interactive tier. Slow and expensive. | First-class search over object storage. No rehydration. |
| Storage | Microsoft-managed Log Analytics + Azure storage. Opaque to you. | Native Parquet on object storage. Your bucket, your keys, open format. |
| Query languages | KQL only. | KQL natively (same operator surface: where, extend, summarize, join inner/leftouter/anti, let, parse, mv-expand, bin, case/iff, union). Plus SPL and SQL. Plus AI agents over MCP, Grafana, Trino, Athena. |
| Azure ecosystem integration | Deep. Defender for Cloud, Defender for Endpoint, Purview, Entra ID, Sentinel Notebooks. | Standalone. Integrates via APIs and standard log sources, but isn’t a Microsoft-blessed component. |
| SOAR | Logic Apps. Mature but Azure-bound. | SLAM. Built into Caver. Configuration-as-code playbooks, version-controlled, no separate Logic Apps subscription. |
| Content packs | Sentinel content hub (community + Microsoft + partner). Variable depth, Azure-flavored. | 35+ vendor packs with bundled dashboards + data inputs + OCSF field mappings. Daily updates. |
| Threat intelligence | Microsoft Threat Intelligence + Sentinel TI connectors. | Curated industrial threat intel for caver-industrial; AI threat feeds (NIST AI 100-2, OWASP) for caver-aisec; built-in TI integration for the core. |
| OT / ICS coverage | Defender for IoT (separate product, separate license). | caver-industrial: passive decoders for BACnet/IP, S7Comm, IEC 60870-5-104, DNP3, Modbus TCP, EtherNet/IP, OPC-UA. NIST 800-82 + IEC 62443. Air-gap-friendly. |
| AI security visibility | Limited. | caver-aisec: prompt-injection detection, AI Observatory for LLM spend, NIST AI 100-2 + OWASP feeds. |
| Data residency | Azure regions only. | Your chosen environment, your storage account. |
| Air-gap deployment | Not supported. | Supported, including caver-industrial. |
| Migration tooling | Migration paths from Splunk, ArcSight, QRadar via Microsoft-published guides (manual). | caver-migrate ports dashboards, saved searches, ES correlation, ITSI, UBA, SOAR/Demisto playbooks. 9-of-9 migrator coverage tested end-to-end. KQL-native landing for Sentinel queries. |
Strengths
| Where Sentinel wins | Where Caver wins |
|---|---|
| Deep Azure integration. If your stack is Defender + Purview + Entra ID + Logic Apps + Sentinel, the integration story is unbeatable. Microsoft does this category as well as anyone. | Not locked to Azure. Multi-cloud, on-prem, hybrid, air-gapped, edge. Sentinel can’t follow. |
| Microsoft enterprise sales motion. Procurement, EA renegotiation, Microsoft credit consumption: all paths your finance team already understands. | Transparent licensing. Per-deployment flat. No ingest meter, no commit-tier negotiation, no quarterly Azure-bill surprise. |
| KQL is its native language. Operators who came up on Sentinel won’t switch query languages. | Query flexibility. KQL natively (so Sentinel queries land directly), plus SPL and SQL. Sentinel gives you KQL only. |
| Mature SOAR via Logic Apps. If you’re already a Logic Apps shop, the SOAR story is already familiar. | Cost predictability at scale. Azure ingest pricing punishes growth. Per-deployment pricing doesn’t. |
| Sentinel Notebooks for hunt-style investigations in Jupyter. | OT / ICS coverage. caver-industrial is first-class. Defender for IoT is a separate product with separate licensing and limited integration. |
| AI security visibility. caver-aisec is first-class. Sentinel doesn’t have a comparable AI-runtime product. | |
| Data residency. Your storage account, your keys, open format. Sentinel’s storage is opaque. | |
| Air-gap and on-prem. Sentinel can’t run in either; Caver can. | |
| Open storage. Same OCSF Parquet data is queryable by Grafana, Trino, Athena, AI agents, your data engineering team for non-SIEM purposes. Sentinel’s storage is locked behind KQL only. | |
| Migration tooling. caver-migrate ports a Sentinel deployment in one command, including the KQL queries that land directly on Caver’s native KQL engine. |
How to decide
Stay on Sentinel if: - You’re all-in on Azure and the Microsoft ecosystem. - Your security team’s depth is in KQL and the Defender stack. - Variable ingest pricing is something your finance team is OK negotiating quarterly. - You don’t need OT/ICS, AI security, multi-cloud, or air-gap deployment.
Move to Caver if: - You want to leave Azure-only or you’ve already left. - Your ingest is growing fast enough that the Azure bill has become an existential conversation. - You need OT/ICS, AI security, multi-cloud, or air-gapped deployment. - You want your data in open formats your data engineering team can also use. - Your operators speak SPL or want to add SQL alongside KQL.
Run both during a migration window if: - You have an existing Sentinel investment you can’t justify ripping out immediately. - Stand Caver up alongside, point new data sources at it, gradually move the KQL queries (they land natively). Decommission the Sentinel workspace when the bill is gone.
Talk to us about scoping, or read about caver-migrate for the Sentinel migration path.
Caver vs Sumo Logic
Caver compared to Sumo Logic. Cloud-native SIEM economics, multi-tenant SaaS tradeoffs, and where each fits.
At a glance
| Sumo Logic | Caver | |
|---|---|---|
| Deployment model | Multi-tenant SaaS only. | Self-hosted in your cloud, on-prem, or air-gapped. |
| License model | Per-GB ingest + per-credit pricing. | Per-deployment commercial license-key. |
| Data residency | Sumo’s chosen regions. | Your chosen environment, your storage account. |
| Storage | Sumo’s. | Your object storage. |
| Cold-tier search | Continuous and frequent tiers; performance varies by tier. | Single object-storage tier, consistent performance. |
| Query languages | Sumo’s own query language plus LogReduce / LogCompare. | SPL + KQL + SQL natively, all on the same backend with a language toggle. Plus AI agents over MCP, Grafana, Trino, Athena over the same OCSF Parquet lake. |
| Content ecosystem | Sumo Apps catalog (vendor-published, varying depth). | Curated vendor packs that ship with dashboards, saved searches, data inputs, and OCSF field mappings. Daily updates. No third-party install. |
| Air-gap deployment | Not supported. | Supported, including for caver-industrial. |
| Custom integration cost | API integration. | Direct repo access in customer environment. |
| OT / ICS coverage | No first-class OT product. The multi-tenant SaaS deployment model is structurally incompatible with air-gapped industrial environments. | caver-industrial: passive deep-packet decoders for BACnet/IP, S7Comm, IEC 60870-5-104, DNP3, Modbus TCP, EtherNet/IP, OPC-UA. Framework alignment for NIST 800-82 + IEC 62443. Air-gap-friendly deploy. Curated industrial threat intel. |
| AI security visibility | Limited. | caver-aisec, purpose-built. |
Strengths
| Where Sumo Logic wins | Where Caver wins |
|---|---|
| Zero infrastructure operations. Sumo runs the platform. Your team writes queries and reads dashboards. | Data sovereignty. Your data stays in your environment. Important for regulated industries, government work, OT, and any organization with a “data does not leave our infrastructure” policy. |
| MSP and multi-tenant friendliness. Sumo has a strong MSP / managed-service motion built into the product. | Cost trajectory at scale. Per-GB ingest pricing punishes growth. Per-deployment pricing doesn’t. |
| Predictable SaaS economics if your volume is stable. When your ingest doesn’t grow much month-to-month, Sumo’s pricing is straightforward. | Air-gap and on-prem. Sumo cannot run inside an air-gapped industrial network. Caver can. |
| Open storage format. Your data engineering team can use the same parquet / iceberg data for non-SIEM purposes. Sumo’s storage is opaque to you. | |
| Query however you want. SPL, KQL, and SQL natively on the same backend. AI agents over MCP, Grafana, Trino, Athena over the same Parquet lake. Sumo gives you Sumo’s query language. | |
| Content packs that ship complete. Each Caver pack includes dashboards, saved searches, data inputs, and OCSF field mappings, daily-updated. | |
| OT and AI surfaces. caver-industrial and caver-aisec have no Sumo equivalent. |
How to decide
If you’re cloud-native, multi-tenant, and your data-residency requirements don’t matter, Sumo is a reasonable SaaS answer.
If you have regulatory, compliance, or operational reasons to keep data in your own environment, or if your ingest is growing fast enough that per-GB pricing has become an existential conversation, Caver is the structural answer.
If you have OT, ICS, or air-gapped requirements, Caver is the only one of the two that can actually deploy there.
caver-collector vs Cribl Stream
A direct comparison between the caver-collector pre-index pipeline tier and Cribl Stream. Where the established player wins, where the integrated stack wins.
This comparison is specifically about caver-collector, the Caver-family pre-index pipeline component, against Cribl Stream. (For full SIEM-vs-SIEM comparisons, see vs Splunk, vs Elastic, or vs Sumo Logic.)
At a glance
| Cribl Stream | caver-collector | |
|---|---|---|
| Position | Independent pipeline tier in front of any SIEM. | Pipeline tier integrated with the Caver storage and search stack (also runs standalone). |
| Underlying engine | Cribl’s purpose-built pipeline. | Vector + OpenTelemetry dual backend. |
| License model | Cribl commercial license. | Per-deployment license-key (or included with Caver). |
| Pipeline UI | Mature visual pipeline builder. | Configuration-as-code first; UI a secondary surface. |
| Routing | Multi-destination routing, broadly. | Multi-destination routing, broadly. |
| Transformation primitives | Cribl’s own pack catalog. | Vector + OTel native primitives plus Caver-specific manipulation. 14 new stateless transforms shipped last week (parse_csv, parse_kv, cast_field, hash_field, rename_field, coalesce, extract_timestamp, filter, mask_value, json_parse, field_extract, rate_limit, dedupe, and more). |
| Adapter / source ecosystem | Cribl Packs catalog plus vendor-published TAs. | 60+ vendor adapters across two release cycles (Webex, Lacework, Mattermost, Buildkite, Discord, Meraki, CircleCI, Linode, MongoDB, and many more). Each ships with OCSF field mapping built in. |
| Industrial protocol decoding | Cribl Stream can route OT telemetry (syslog, raw TCP, custom inputs) but doesn’t decode industrial protocols natively. No first-class OT product story. | 7 passive deep-packet decoders (BACnet/IP, S7Comm, IEC 60870-5-104, DNP3, Modbus TCP, EtherNet/IP, OPC-UA). Air-gap-friendly. Pairs with caver-industrial on the SIEM side for NIST 800-82 + IEC 62443 framework alignment. |
| Vendor independence | Vendor-neutral (works in front of any SIEM). | Vendor-neutral (works in front of any SIEM), with first-class integration into Caver. |
Where Cribl wins
- Maturity. Cribl has been the dominant independent pipeline tier for years. The UI is more polished. The pack catalog is broader. The operator pool is bigger.
- Pure-play independence. Cribl explicitly positions as vendor-neutral. If neutrality from any single SIEM vendor is a procurement requirement, Cribl tells that story cleanly.
- Visual pipeline builder. If your team prefers to drag-and-drop transformations rather than write configuration, Cribl’s UI is better.
Where caver-collector wins
- Open-source engine pedigree. Vector and OpenTelemetry are both open-source, both mature, both have huge community ecosystems. Cribl’s engine is proprietary.
- Integration with Caver. When paired with Caver, the storage, search, content, and pipeline tiers all share an operator surface. With Cribl + Caver, you get two separate operator surfaces.
- Configuration-as-code first. GitOps-friendly. Version-controlled pipeline definitions. PR review on pipeline changes.
- No additional commercial conversation if you already have Caver. caver-collector is included with Caver deployments. Cribl is a separate purchase.
How to decide
If you’ve already chosen Cribl and it’s working, there’s no urgent reason to replace it. Cribl + Caver is a valid combination; Caver doesn’t care what fronts it.
If you’re greenfield and considering both, evaluate the integrated-stack benefit of caver-collector + Caver against Cribl’s maturity advantage. For most teams, the integrated stack wins on operational complexity. For teams that need a long-term independent pipeline tier as a deliberate architectural choice, Cribl wins.
Caver vs Wazuh
Caver compared to Wazuh (open-source SIEM/XDR). Why these two are a deliberate combo, not an either-or choice.
Wazuh is the dominant open-source SIEM/XDR. Free, Apache 2 licensed, deployed on roughly 25 million endpoints worldwide. The honest answer to “Caver vs Wazuh” is that for most teams, they’re a combo, not a choice. Wazuh is the endpoint-agent + assessment layer; Caver is the storage, search, analytics, AI-security, and OT layer behind it.
At a glance
| Wazuh | Caver | |
|---|---|---|
| License model | Open source (Apache 2). Free agent + manager + indexer. Paid Wazuh Cloud for SaaS. | Per-deployment commercial license-key. |
| Endpoint agent | First-class: Windows, macOS, Linux, Solaris, AIX. Self-updating, signed, manageable. | None native. We recommend Wazuh agent + Caver as the analytics tier. |
| File Integrity Monitoring (FIM) | First-class via Wazuh agent syscheck module. | Inherited from Wazuh agent via the partnership integration; CAVERN detection content consumes the events. |
| Compliance modules | PCI DSS, HIPAA, NIST 800-53, GDPR mapped to rules out-of-box. | Same coverage via Wazuh agent + dedicated compliance mapping page on docs.etairos.ai (planned). |
| Configuration assessment | CIS benchmark scanning via Wazuh sca module. | Inherited from Wazuh agent. |
| Vulnerability scanning | Package-CVE matching via Wazuh vulnerability detector. | Inherited from Wazuh agent. |
| Storage backing | Wazuh indexer (OpenSearch fork). Same scale-engineering tax as Elastic. | Native Parquet on object storage. No shard sizing, no ILM tuning. |
| Query languages | OpenSearch DSL (Lucene). | SPL + KQL + SQL natively. AI agents over MCP, Grafana, Trino, Athena over the same Parquet lake. |
| Container / K8s security | Wazuh-Kubernetes integration via API audit. | Falco + Trivy partnership for first-class K8s coverage: runtime detection, image scanning, and policy violations all normalised into the CAVERN content pipeline. |
| OT / ICS coverage | Limited; no first-class industrial product. | caver-industrial: passive decoders for BACnet/IP, S7Comm, IEC 60870-5-104, DNP3, Modbus TCP, EtherNet/IP, OPC-UA. NIST 800-82 + IEC 62443. Air-gap-friendly. |
| AI security visibility | None. | caver-aisec: prompt-injection detection, AI Observatory for LLM spend, NIST AI 100-2 + OWASP feeds. |
| Content packs / integrations | Wazuh agent built-in modules plus community-contributed rules. | 35+ vendor packs shipping with dashboards, saved searches, data inputs, and OCSF field mappings. Daily updates. |
| Cold-tier search | OpenSearch ISM moves data through hot/warm/cold/frozen with performance penalties. | First-class search over object storage. No rehydration. |
Strengths
| Where Wazuh wins | Where Caver wins |
|---|---|
| The endpoint agent itself. ~25M endpoints can’t be wrong. Mature, signed, self-updating, broad OS coverage. | The analytics tier. Object storage backing instead of OpenSearch indexer. No shard sizing, no ILM tuning, no version-upgrade pain. |
| Free OSS pricing for the agent + manager + indexer. If you can run the indexer yourself, the only cost is your operator time. | Query however you want. SPL, KQL, and SQL natively. Wazuh gives you OpenSearch DSL. |
| Established compliance posture. PCI DSS / HIPAA / NIST 800-53 mappings are mature and accepted by auditors. | AI security. caver-aisec has no Wazuh equivalent. |
| Active-response framework. Lightweight SOAR built into the agent (block IP, kill process, quarantine file). | OT / ICS. caver-industrial has no Wazuh equivalent. |
| Community + Wazuh Cloud. Real ecosystem, real managed-service option. | Daily-updated content packs with bundled dashboards + data inputs + OCSF field mapping. Wazuh’s vendor coverage is broad but variable in depth. |
| Transparent commercial license-key on the analytics tier vs OSS+paid-cloud bimodal pricing. |
How to decide
For most teams: deploy both. Run Wazuh agent on your endpoints. Land the events in Caver. Use Wazuh for endpoint coverage (FIM, CIS, CVE, OS-level events) and Caver for storage, search, AI security, OT/ICS, and cross-source correlation.
For shops already running Wazuh end-to-end (Wazuh agent + Wazuh manager + Wazuh indexer): Caver replaces just the indexer + analytics tier. Keep everything else.
For shops greenfield-evaluating SIEMs: Wazuh alone is a strong free starting point. The reasons to add Caver are scale economics, query-language flexibility, AI security, or OT/ICS coverage. None of those are urgent at small scale; all of them become urgent at scale.
For shops with regulated workloads where the “free OSS” answer doesn’t fly: Caver gives you the commercial backing, transparent licensing, and analytics tier that procurement can sign off on. Wazuh stays as the endpoint layer.
Caver vs Dragos
Caver compared to Dragos Platform for OT/ICS buyers. Where Dragos's decade of OT focus wins, where unified IT plus OT in one stack wins.
Dragos is the established OT/ICS security platform. A decade of industrial focus, deep ICS-vendor relationships, well-known threat research (the WorldView intel, the CHERNOVITE / VOLTZITE attributions), and a large federal customer base. If you’re an OT-only buyer evaluating OT-only platforms, Dragos is the incumbent.
Caver answers a different procurement question: do you want one stack that covers IT and OT, or two stacks? caver-industrial extends the same Caver lakehouse SIEM with passive industrial-protocol decoders and OT-aware detection content, so OT and IT events land in one analytics tier with one query language.
At a glance
| Dragos Platform | Caver (caver-industrial + caver-collector) | |
|---|---|---|
| Buyer focus | OT-only specialist. | IT and OT in one stack (convergence buyer). |
| Deployment model | Appliance and virtual sensor; vendor-managed and on-prem options. | On-prem lakehouse, air-gap friendly. caver-collector pipeline on the OT side, caver storage and analytics on the IT side. |
| Passive protocol coverage | Broad and mature: 25+ industrial protocols including DNP3, Modbus, IEC 60870-5-104, IEC 61850 GOOSE/SV, S7Comm, EtherNet/IP, OPC-UA, BACnet, plus vendor-specific dialects. | Active decoders for BACnet/IP, S7Comm, IEC 60870-5-104, DNP3, Modbus TCP, EtherNet/IP, OPC-UA. Roadmap aligns with the published industrial integration order. |
| Asset inventory | First-class, mature, with vendor-firmware mapping. | Native asset inventory built from passive decoder output and partner ingestion. |
| Industrial threat intel | WorldView intel program with named-threat attribution and quarterly releases. | Curated TI feeds focused on industrial CVEs and adversary TTPs. Updates daily through the Caver content pipeline rather than quarterly. |
| Framework alignment | NIST 800-82, IEC 62443, NERC CIP. | NIST 800-82, IEC 62443. Roadmap includes NERC CIP content. |
| IT-side coverage | Limited; integrates with IT SIEMs rather than being one. | Native. Caver is an IT SIEM that also covers OT. No second stack. |
| AI security visibility | None. | caver-aisec: prompt-injection detection, AI Observatory, NIST AI 100-2 + OWASP feeds. |
| Query languages | Platform-native UI and queries. | SPL, KQL, SQL natively against the Parquet lake. AI agents over MCP. |
| Pricing model | Enterprise procurement; per-asset and per-site licensing typical. | Transparent per-deployment license-key. Industrial pricing marketed Custom. |
| Update cadence | Quarterly platform releases plus intel updates. | Daily content updates through the pipeline. |
Strengths
| Where Dragos wins | Where Caver wins |
|---|---|
| A decade of OT-only focus. When the entire product roadmap is industrial, the depth shows. Protocol coverage, vendor-firmware mappings, and threat research are mature in a way a younger product cannot match. | One stack, not two. Caver is an IT SIEM that also handles OT. You don’t run separate query languages, separate dashboards, separate alerting tiers for the IT and OT halves of the same investigation. |
| Named-threat attribution. WorldView’s adversary profiles (CHERNOVITE, VOLTZITE, ELECTRUM, and others) carry weight with executive readers and federal buyers. | Transparent licensing. Per-deployment license-key with a published model on the Caver landing page. Dragos requires enterprise procurement. |
| Established federal and asset-owner base. If your procurement requires Dragos-by-name references in critical infrastructure, that’s a real moat. | Lakehouse economics. Caver stores everything as Parquet on object storage. The cost ceiling that keeps OT teams from keeping more than 90 days of historian data does not apply. |
| OT-vendor relationships. Deep integrations with Schneider, Siemens, GE, Honeywell, Rockwell, ABB built over years of co-engagement. | Native AI security. caver-aisec is part of the same stack. OT teams that are starting to deploy LLM-assisted maintenance copilots have one place to monitor that traffic. |
| OT-only specialization is sometimes the right answer. Some buyers do not want their OT analytics commingled with IT log volume; Dragos lets them buy an OT-only platform without that tradeoff. | Daily content updates. Caver’s content pipeline ships daily. Dragos’s platform releases are quarterly. |
| Convergence is the trend. OT and IT are merging operationally (remote engineering access, cloud-connected historians, IT-IDS in the OT DMZ). Buyers who plan for the convergence buy convergence-native tools. |
How to decide
For OT-only shops with a mature, separately-staffed OT security program and no plans to converge with IT: Dragos is the safer pick. A decade of OT focus is hard to argue with.
For shops where the same team owns IT and OT, or where the IT SOC is being asked to cover OT events as part of the convergence push: Caver removes a stack. One query language, one analytics tier, one license.
For shops doing a competitive bake-off: the honest comparison is depth-of-OT vs breadth-of-coverage. Dragos is deeper on OT specifically. Caver is broader across IT, OT, and AI security in one place. Map that to which procurement question is louder for you.
For shops where industrial pricing is a budget blocker: Caver’s per-deployment license-key is published, and industrial pricing is quoted Custom but built on the same transparent model rather than enterprise per-asset arithmetic.
caver-aisec vs Lakera
caver-aisec compared to Lakera Guard. Why these two are complementary, not competitive, for most AI-security buyers.
caver-aisec and Lakera live in adjacent halves of the AI-security problem. Lakera is the inline guard at the prompt boundary. caver-aisec is the runtime detection + SOC correlation layer. For most teams the right answer is to use both, not pick one.
At a glance
| Lakera | caver-aisec | |
|---|---|---|
| Posture | Inline guard. Intercepts prompts, scores, blocks or allows before the LLM call. | Runtime detection. Sees prompts after the LLM call, alerts, correlates with the rest of your security telemetry. |
| Latency profile | Sub-100ms; sits in the request path. | Asynchronous; doesn’t add latency to the LLM call itself. |
| Deployment | SaaS-first. | Self-hosted. On-prem, air-gapped, or cloud. |
| PII detection | Built-in PII detector with configurable redaction. | Shipped: Presidio integration with per-tenant policy and redaction. |
| Hallucination scoring | Faithfulness / groundedness scoring on RAG outputs. | Shipped: Ragas + TruLens integration with per-response scoring surfaced to SLAM notables. |
| Red-team testing | Lakera Red for adversarial probing. | Shipped: Garak + PyRIT scheduled probes with MITRE ATLAS coverage matrix. |
| Inline blocking | Lakera Guard, primary product. | Shipped: NeMo Guardrails + Rebuff runtime allow / deny / rewrite on the LLM-to-tool boundary. |
| SOC integration | Limited. AI-side product, not SOC-side. | First-class. AI events flow into Caver alongside identity, endpoint, network telemetry. |
| Cross-source correlation | None native. | Native. Prompt-injection attempt correlates with the IP, identity, endpoint, and tool-call activity around it. |
| AI Observatory / spend tracking | Limited. | First-class per-tenant LLM spend tracking with budget alerts. |
| Alert channels | Webhook + integrations. | PagerDuty, Discord, Teams, Slack, Telegram, SMTP, webhook. |
| Threat feeds | Lakera-curated. | NIST AI 100-2, OWASP Agentic AI Top 10, OWASP ML Top 10, HuggingFace Security, vendor advisories. |
| MCP tool-call audit | Not a focus. | First-class: LLM-to-MCP bridge instrumentation with CAVERN detection content. |
| Pricing | SaaS subscription. | Per-deployment commercial license-key. |
| Open source posture | Closed-source commercial. | Closed-source commercial. Built on open-source components (planned: NeMo Guardrails, Presidio, Ragas, Garak). |
Where Lakera wins
- Inline blocking is shipping today. Lakera Guard intercepts and blocks at the prompt boundary in production now. caver-aisec’s inline-block ticket is open but unshipped.
- PII detection is shipping today. Same.
- Lakera Red is shipping today. Pre-deploy adversarial test framework.
- SaaS-first delivery. Fast pilots, zero infrastructure.
- Established AI-security brand. Lakera holds mindshare in the inline-guard category.
- Browser-side Chrome extension for shadow-AI catch is real and useful.
Where caver-aisec wins
- SOC correlation. A prompt-injection attempt that touches identity, network, endpoint, and tool-call activity should show up in one queryable timeline. caver-aisec puts AI traffic next to the rest of your security telemetry; Lakera doesn’t.
- AI Observatory. Per-tenant LLM spend tracking with budget alerts. Lakera doesn’t track spend.
- Self-host / air-gap. Lakera is SaaS-first. For regulated industries, government, OT-adjacent, or air-gapped environments, Lakera can’t deploy. caver-aisec can.
- Alert channel breadth. 7 named channels (PagerDuty, Discord, Teams, Slack, Telegram, SMTP, webhook) vs Lakera’s webhook + integrations.
- Threat feed breadth. Multiple public AI-security feeds ingested as detection content, not just curated by the vendor.
- MCP tool-call audit. Caver instruments the LLM-to-tool boundary specifically; useful for agentic AI deployments.
How to decide
Most teams: use both.
Lakera + caver-aisec is a deliberate combo. Lakera blocks at the prompt boundary. caver-aisec gives you SOC-side visibility into what was blocked, why, and what other telemetry correlates with the attempt. Same posture as a WAF + SIEM combo on the traditional web stack: the WAF blocks, the SIEM investigates.
Lakera-only is reasonable when: - You’re SaaS-only, no SOC, no regulated workloads. - AI security is your only security tool (small shop, AI-first product). - You need inline blocking today and can’t wait for caver-aisec parity (#24).
caver-aisec-only is reasonable when: - You need air-gap, on-prem, or data-residency reasons SaaS won’t satisfy. - You’re already running Caver as your SIEM and want AI security on the same operator surface. - You need OT-adjacent or industrial AI deployments where SaaS can’t deploy. - You want a single per-tenant spend + visibility surface, not just guarding.
Both is best when: - You want inline prevention + runtime detection + SOC correlation. - You’re at the scale where a missed prompt-injection costs more than two vendor relationships.
caver-aisec vs Mindgard
caver-aisec compared to Mindgard. Pre-deployment red-teaming vs runtime detection, complementary not competitive.
caver-aisec and Mindgard solve different halves of the AI-security problem. Mindgard tests AI systems before deployment with automated red-teaming. caver-aisec detects attacks at runtime and correlates them with your SOC telemetry. Same defense-in-depth posture as a vulnerability scanner + EDR pairing on the traditional security stack: scanner finds the exposures, EDR catches the exploits.
At a glance
| Mindgard | caver-aisec | |
|---|---|---|
| Posture | Pre-deployment + scheduled continuous testing. Probes target AI systems with adversarial inputs to find weaknesses. | Runtime detection. Observes deployed AI systems and detects attacks in flight. |
| Test catalog | Curated test pack covering jailbreak, prompt injection, model extraction, training-data leakage, supply chain. | Detection content pack for the same categories, but observed at runtime, not probed pre-deploy. |
| ATT&CK-for-ML mapping | Formal mapping of test coverage to MITRE ATLAS techniques. | Shipped: Garak + PyRIT integration with MITRE ATLAS technique coverage matrix and OWASP LLM / Agentic / ML Top 10 tagging across the detection corpus. |
| Deployment | SaaS platform. | Self-hosted. On-prem, air-gapped, or cloud. |
| Continuous testing | Scheduled probes against deployed AI endpoints. | Shipped: scheduled Garak + PyRIT probes against your deployed endpoints, with results flowing into Caver alongside runtime telemetry for cross-source correlation. |
| SOC integration | Limited. AI-testing product, not SOC-side. | First-class. AI events + test results flow into Caver alongside identity, endpoint, network telemetry. |
| Cross-source correlation | None native. | Native. Failed probe correlates with deployed model version, the prompt patterns that triggered it, and the rest of your security telemetry. |
| AI Observatory / spend tracking | Limited. | First-class per-tenant LLM spend tracking with budget alerts. |
| Alert channels | Email + integrations. | PagerDuty, Discord, Teams, Slack, Telegram, SMTP, webhook. |
| Threat feeds | Mindgard-curated test catalog. | NIST AI 100-2, OWASP Agentic AI Top 10, OWASP ML Top 10, HuggingFace Security, vendor advisories. |
| MCP tool-call audit | Not a focus. | First-class: LLM-to-MCP bridge instrumentation. |
| Pricing | SaaS subscription. | Per-deployment commercial license-key. |
Where Mindgard wins
- SaaS-first delivery. Fast pilots, zero infrastructure.
- Established AI red-team brand. Mindgard holds mindshare in the pre-deploy testing category and ships a polished probe authoring UI.
- Curated proprietary test catalog. Their in-house research team adds novel attacks the open Garak / PyRIT corpora may lag on.
Where caver-aisec wins
- Pre-deploy probes + runtime detection in one stack. Shipped: Garak + PyRIT probes run on a schedule against your deployed AI endpoints, results land in Caver alongside runtime telemetry, the same operator surface investigates both. You don’t pick test-first vs detect-first, you get both.
- Formal MITRE ATLAS coverage matrix. Shipped: per-technique coverage report driven by the Garak + PyRIT corpus + Caver’s hand-authored detection content, with OWASP LLM, Agentic, and ML Top 10 tagging cross-referenced.
- Runtime detection + SOC correlation. A failed probe is a hypothesis; a successful exploit in production is the actual attack. caver-aisec catches the latter and correlates it with the rest of your telemetry.
- AI Observatory. Per-tenant LLM spend tracking with budget alerts. Mindgard doesn’t track spend; testing is its product.
- Self-host / air-gap. Mindgard is SaaS. For regulated industries, government, OT-adjacent, or air-gapped environments, Mindgard can’t deploy. caver-aisec can.
- Alert channel breadth. 7 named channels vs email + integrations.
- Threat feed breadth. Multiple public AI-security feeds ingested as runtime detection content, not just as testing inputs.
- MCP tool-call audit. Runtime instrumentation of the LLM-to-tool boundary; useful for agentic AI deployments.
How to decide
Most teams: use caver-aisec.
caver-aisec now ships both halves: pre-deploy probes (Garak + PyRIT, scheduled, with MITRE ATLAS coverage) and runtime detection on the same operator surface. The same notable surface investigates both probe failures and live exploits. For a team building an AI security program from one stack, this is the simpler path.
Mindgard remains a good fit when: - Your AI security mandate is testing-only and you want a polished SaaS authoring UI. - You’re a security testing firm or red-team consultancy and runtime detection is your customer’s problem, not yours. - You don’t have a SOC and aren’t building one. - You specifically value Mindgard’s in-house proprietary test catalog over the open Garak + PyRIT corpora.
caver-aisec-only is reasonable when: - You need air-gap, on-prem, or data-residency reasons SaaS won’t satisfy. - You already have a SIEM and want AI security on the same operator surface. - Your AI systems are deployed and you need to know what’s happening to them now, not what could happen in a lab.
Both is best when: - You ship AI systems to production and want both prevention (testing) and detection (runtime). - You operate at the scale where a missed AI attack costs more than two vendor relationships.
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.
| OCSF class | Class UID | Examples |
|---|---|---|
| Authentication | 3002 | Okta logon, AWS Console login, SSH auth |
| Network Activity | 4001 | Firewall connection, VPN tunnel, DNS query |
| Process Activity | 1007 | EDR process start, sysmon event 1 |
| File Activity | 1001 | File write, file delete, file rename |
| Application Activity | 6005 | LLM API call, SaaS audit event |
| Security Finding | 2004 | CAVERN detection fire, Sigma rule match |
| Vulnerability Finding | 2002 | Tenable scan result, Wiz CVE finding |
| Cloud API | 3005 | CloudTrail event, Azure activity log |
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.
| Format | Vendor lock | Cold-storage cost | Cross-tool query | Caver pick |
|---|---|---|---|---|
| Splunk tsidx | Hard | High (replicated indexers) | None | No |
| Elastic shards | Hard | Medium | Limited | No |
| QRadar Ariel | Hard | High | None | No |
| OCSF Parquet on S3 | None (Apache 2.0) | Lowest (~$0.023/GB) | Trino, Athena, Spark, Pandas, anything | Yes |
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.
| CLASS index | Data model | Example sourcetypes |
|---|---|---|
endpoint | Process, file, and host activity | crowdstrike, sysmon, defender |
network | Connections, DNS, flows | zeek, suricata, firewall |
identity | Authentication and IdP events | okta, azure_ad, google_workspace |
cloud | Cloud control-plane activity | aws_cloudtrail, azure_activity, gcp_audit |
saas_audit | SaaS application audit logs | github, slack, salesforce |
Other architectural choices
| Choice | Caver pick | Why |
|---|---|---|
| Detection rule format | CAVERN YAML (Sigma-shaped) | Sigma is the community standard. CAVERN rules transpile cleanly from Sigma and back. Operators do not need to learn a proprietary DSL. |
| Query layer | Multi-language (SPL, SQL, KQL, ES|QL, LSQL + Sigma, AI assistant) | Teams pick the language they already know. Federation across tools is a first-class capability, not a migration project. |
| Pipeline backend | Lean core on Vector (Rust) + OpenTelemetry, with App Store apps | The collector core stays small; per-vendor mapping and content ship as versioned OCSF apps. Vector for hot paths, OTel for orgs already running OTel infrastructure. |
| Schema enforcement | OCSF validators with coerce / reject / DLQ modes | Bad events go to a DLQ, not into the lake. Schema drift surfaces as a notable, not a silent corruption. |
| AI integration | MCP server, native primitive registry | The assistant is a first-class operator, not a chatbot bolted on. It acts only through Caver's authenticated APIs, under the caller's role-based access. |
| Tenancy | Per-tenant S3 prefix + row filter + LLM config | MSSPs and large enterprises get hard tenant isolation at the storage layer, not just at the query layer. |
| Identity | OIDC / SAML / LDAP, role-based access control with audit | No custom auth. Plug Caver into the IdP you already use. |
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.
Cleartext credential guard
Every inter-service call inside Caver carries something as good as a password.
On the shipped single-host deployment every one of those addresses is loopback,
so nothing touches a wire, which is exactly why the risk is easy to carry
into a multi-host split without noticing: the moment one backend address
becomes another box's IP and stays http://, all of it is readable on
the network.
So Caver classifies its own outbound addresses at startup and says so. Loopback stays silent, because warning about the shipped topology would train operators to ignore the warning that matters.
Where your sensitive data actually is
Everybody has regexes; pattern matching is table stakes. The capability is the exposure map: which systems, indexes, sourcetypes and hosts carry which classes of sensitive data, and therefore which of those places should not have it.
This is a different axis from storage routing. It does not change where an event is stored; it describes what the event contains. See also Healthcare, where the same map answers “where is our PHI”.
Finding sensitive data does not mean copying it. Caver records that a match was found, its type and its location. It never stores the value it matched, because a tool that catalogued PHI by copying it into a second system would create the exposure it was bought to find.
Operator-facing fetches are SSRF-hardened
Anywhere an operator can point Caver at a URL, the fetch goes through a hardened client rather than a bare HTTP GET, so a feed or webhook address cannot be turned into a request against your internal network.
Demo data is marked as demo data
Synthetic and demonstration events carry a marker, so a trial or a demo environment can never be mistaken for production evidence.
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
| Variable | Default | Description |
|---|---|---|
CAVER_LAKE_S3_ENDPOINT | AWS S3 | Any S3-compatible endpoint (MinIO, R2, on-prem) |
CAVER_LAKE_WAREHOUSE | none | Iceberg warehouse location for the OCSF lake |
CAVER_LAKE_CATALOG_DSN | none | Iceberg catalog connection |
CAVER_LAKE_RETENTION_DAYS | unlimited | Global retention window; per-index overrides supported |
CAVER_LAKE_RETENTION_DRY_RUN | false | Report what retention would delete without deleting |
Query engine
| Variable | Default | Description |
|---|---|---|
CAVER_SEARCH_BASE_REUSE_DIR | off | Enables the ephemeral base-result cache for dashboards and repeat searches |
CAVER_LAKE_DATA_CACHE_MB | off | In-memory Parquet data cache for hot columns |
Ingest & lifecycle
| Variable | Default | Description |
|---|---|---|
CAVER_HEC_TOKEN | none | HEC ingest authentication |
CAVER_INGEST_MAX_EVENT_AGE | off | Drop over-age events at decode |
CAVER_LAKE_ROLL_ENABLED | false | Hot-to-warm roll engine |
CAVER_LAKE_PRESET | auto | Sizing preset; auto_high_volume for heavy ingest |
AI assistant
| Variable | Default | Description |
|---|---|---|
CAVER_LLM_PROVIDER | none | LLM provider (OpenAI-compatible or Anthropic) |
CAVER_LLM_BASE_URL / CAVER_LLM_API_KEY / CAVER_LLM_MODEL | none | Endpoint, key, and model for the grounded assistant |
DR replication
| Variable | Default | Description |
|---|---|---|
CAVER_DR_REPLICA_BUCKET | off | Second bucket/region/site the lake replicates to; enables replica health monitoring |
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.