Wazuh keeps the log record. Hanu reads the cloud, code and AI layers.
These two products are not substitutes. Wazuh collects and keeps host and log telemetry at scale; Hanu reads cloud, code, identity, certificate and AI surfaces and tells you when signals from them form one chain. The comparison only makes sense as a question about layers, which is why this page argues for running both.
A page arguing that Hanu should replace Wazuh would be arguing in bad faith. Hanu does not collect host logs, does not run an endpoint agent, and does not keep a searchable log lake with retention measured in years. What it does is the layer above: it reads the surfaces a log pipeline cannot see - cloud configuration, CI/CD, release provenance, certificate trust, model and agent activity - and it emits compound risks with the evidence attached.
Where the other tool wins
On every axis that belongs to log collection and host telemetry, Wazuh wins by design rather than by accident.
- Log collection at scale, with agents. Wazuh's agent fleet covers the hosts, and its decoders and rules exist to turn that stream into something alertable. Hanu has no endpoint agent and no host log pipeline; runtime telemetry arrives through EDR integrations such as CrowdStrike and SentinelOne.
- The raw record. Searching raw events, keeping history, and answering what a specific host did on a specific date is a SIEM's job. Hanu's evidence trail points at the signals and the rule that produced a risk; it is not a log lake and we will not present it as one.
- Documentation, community and deployment experience. Wazuh has been deployed in far more environments than Hanu ever will be, including air-gapped and regulated estates, and the material to operate it is abundant and field-tested.
- The licence. Wazuh is open source and free to self-host. Hanu is source-available under the Elastic License 2.0 - not OSI-approved open source - and while the Community edition is $0 in production, that is a different promise and worth comparing before you commit.
- Host-level change detection. File integrity monitoring and host configuration assessment are host-native capabilities. Hanu reasons about configuration from cloud APIs and about code from the forge, which is a different vantage point with different blind spots.
Where Hanu fits
Hanu is the correlation layer, and it fits beside a SIEM rather than in front of it.
- Typed signals rather than log lines. 166 typed signals arrive on one bus, emitted by collectors across 32 domains, each carrying the resource, principal, account and confidence. Detections are rules over those types, which is what makes a risk reproducible six months later without rebuilding context from three dashboards.
- Two tiers of correlation. 34 tier-1 rules evaluate one signal against history and context. 41 tier-2 rules fuse signals from different providers inside a declared window: a workflow change and a secret exposure, a poisoned release and model enumeration, a certificate in use and an authority whose keys are recoverable. 75 rules in total, all readable in the source.
- Compound risk is the deliverable. 609 behavioural detections feed the joins. The output is one ranked risk per chain, scored by fixed arithmetic with 0 LLMs anywhere in the detection or scoring path, and every risk carries its contributing signals.
- Self-hosted with zero egress, under ELv2. Eight services, minimum 2 vCPU, 6 GB RAM and 10 GB disk, 0 bytes of telemetry leaving your account, air-gap capable, source-available with no time conversion and a Community edition that is $0 in production.
- Output goes to the process you already run. Jira, ServiceNow, Cortex XSOAR, PagerDuty, Slack, or a Splunk or Datadog pipeline, plus a generic webhook action for an arbitrary HTTPS endpoint. A correlation engine that hands work to the systems you own is easier to add beside a SIEM than one that wants to become it.
| Surface | Log-first SIEM (Wazuh) | Hanu |
|---|---|---|
| Host logs and endpoint telemetry | The core of the product, collected by agents | Not collected; runtime telemetry arrives through CrowdStrike and SentinelOne integrations |
| Raw log search and retention | Yes, and it is the reason the product exists | No; risks carry an evidence trail rather than a log lake |
| Cloud posture | Not the centre of the product | 368 AWS · 77 Azure · 77 GCP checks, read from read-only cloud roles |
| CI/CD, releases and provenance | Visible only if you forward the logs and write the rules | First-class signals: workflow tamper, unpinned actions, release freshness, provenance gaps |
| Certificate trust and issuer reputation | Not part of the product; you would write it yourself | Tracked as supply-chain inventory, with name-pattern matching recorded on the signal |
| AI workload and agent activity | Not part of the product | Model enumeration, credential validation, MCP servers and agent identity signals |
| Cross-domain correlation | Rules over the events you collected | 75 rules joining typed signals from different providers |
RULE-T2-014CI workflow tamper, then a secret becomes readable
Two observations from the same repository inside seven days, one of them routine. Neither half justifies an alert on its own, which is exactly why the pair is invisible to any single-tool console, including a log platform that has not been taught what a workflow change looks like.
CERTIFICATE_TRUST_COMPROMISEDA chain rooted in somebody else's mistake
A certificate in use that chains to a hierarchy whose private keys are recoverable. The useful question is not whether the CA was compromised - that is public - but which of your services, images and pinned trust stores came from that hierarchy. That is inventory, not log search.
MCP_SERVER_DETECTEDThe newest surface in the estate
MCP servers, their tool permissions and the agent identities that reach them. It is a surface with no host log signature, which is the case for keeping a cloud-and-code correlation layer next to your log platform rather than asking one product to be both.
| Log-first SIEM (Wazuh) | Hanu | |
|---|---|---|
| Deployment | Server plus agents across hosts | 8 services, no endpoint agent anywhere |
| Who runs it | Your team | Your team, or us on a managed instance; minimum host 2 vCPU · 6 GB RAM · 10 GB disk |
| Data residency | Inside your boundary | Inside your boundary, with your datastores and your KMS key |
| Telemetry egress | None for a self-hosted deployment | 0 bytes; air-gap capable with a signed detection bundle |
| Licence | Open source, free to self-host | Elastic License 2.0, source-available; Community edition $0 in production |
| Content model | Rules and decoders, extended by you and the community | 609 behavioural detections and 75 correlation rules, updated from a signed feed |
| Where output goes | Its own dashboards and alerting | Jira, ServiceNow, Cortex XSOAR, PagerDuty, Slack, Splunk or Datadog |
Verdict
Run Wazuh if you are a SOC engineer or a platform lead whose requirement is a log record you can search: host telemetry, retention you control, alerting that works, and a licence that lets you do what you like with it. Add Hanu if the gap is that nobody is reading the cloud, CI/CD, certificate and AI surfaces, or that the findings you do get arrive unjoined and unranked. Replacing one with the other leaves a hole either way, and the teams that get this right run a log platform for the record and a correlation layer for the joins.
Run both, then what
Is Hanu a SIEM?
No, and it is not trying to be one. It correlates across cloud, identity, code, certificate and AI surfaces and hands the result to the response process you already run. There is no log lake, no query language over raw events, and no retention tiering to configure.
Can we send Hanu's alerts into our log pipeline?
Yes. Remediation and alerting destinations include Jira, ServiceNow, Cortex XSOAR, PagerDuty, Slack, and Splunk or Datadog pipelines, and there is a generic webhook action for an arbitrary HTTPS endpoint. There is no Wazuh connector, so a log pipeline receives Hanu output as events you route rather than as a native integration.
Do we have to choose one?
No, and the products are shaped so that you should not. Wazuh keeps the record of what your hosts did; Hanu reads the cloud, code and AI surfaces and emits one risk per chain. Different inputs, different outputs, and a compound risk makes a sensible event in a log platform.
Does Hanu keep raw events?
It keeps the typed signals behind a risk and the evidence a rule used, and an evidence pointer back into the event that produced a signal. It is not built for full-fidelity log retention, and we would not ask you to replace a log platform with it.
What about agents on our servers?
Hanu ships no endpoint agent. Runtime and endpoint telemetry arrives through EDR integrations such as CrowdStrike and SentinelOne, and the platform's own collection is read-only API access to cloud accounts, forges and identity providers.
Run it in your own account
One Docker Compose stack, your datastores, read-only credentials into your clouds. The Community edition is free to run in production.