Wazuh FIM: the collection is good. The tuning is the problem.

If you are evaluating file integrity monitoring on Linux, you will end up looking at Wazuh. It is free, it is widely deployed, and it does the job. This post is about a narrower question: why teams running Wazuh FIM often end up ignoring it anyway — and why that problem is not fixed by better kernel-side collection.

First, the part most comparison posts get wrong

A lot of vendor content claims the open-source tools detect file changes by polling checksums or reading auditd, and that eBPF is the modern alternative. For Wazuh in 2026, that is simply not true.

Wazuh 5.0 ships an eBPF implementation of FIM whodata. Their own engineering work on it is public: PR #38545 covers BPF-LSM hooks with a kprobe fallback, including the kernel constraints (bpf_d_path needs 6.8; attaching BPF-LSM on arm64 needs CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS, so 6.4) and measured behavior on arm64 and btrfs.

So if you are choosing between Wazuh and something else on the basis of "who reads the kernel", that is not a real difference any more. We build on eBPF too. It is not our argument.

The actual problem: you still have to describe "normal"

Here is a real question from a Wazuh user, on r/Wazuh earlier this month:

High Wazuh firedtimes for PAM sudo session opened/closed — I'm trying to investigate a large amount of noise from sudo PAM events on one of my Linux agents.

Nothing is broken here. Collection worked perfectly. The events are real, the rules fired correctly, and the outcome is a person asking how to make their monitoring stop shouting at them.

That is the shape of the problem. Every rule-based FIM tool asks you to encode, up front and by hand, what routine activity looks like on your systems: which paths change during a deploy, which cron jobs rewrite which files, what package updates touch, what log rotation does at 3am. You write those exclusions, then you maintain them as the estate changes. Miss one and you get noise. Over-suppress and you miss the thing you installed the tool for.

The cost is not licensing — Wazuh is free. The cost is the engineer who owns that ruleset.

The whodata path is also more fragile than it looks

Worth knowing if you are planning a rollout. These are all current, all filed against 5.0, and several come from Wazuh's own QA:

None of these makes Wazuh a bad tool. Every actively developed agent has a list like this, and the fact that you can read it is a point in favor of open source, not against it. The reason to look at them is narrower: the setup effort you are budgeting for whodata is probably larger than the documentation suggests.

What we built instead

kaimon reads file events from the kernel via eBPF, the same as Wazuh 5.0 does. The difference is what happens next.

Instead of asking you to write rules describing normal, it watches for seven days and learns them: container startup, log rotation, package updates, cron, weekly maintenance. Then it locks a baseline. After that, routine deployment writes stop producing findings, and what you see are deviations from the pattern that host actually established.

Containers are where the rule problem compounds

A containerized app's files live behind a runtime-specific overlay path — /var/lib/docker/overlay2/<hash>/diff/etc/nginx/nginx.conf — and that hash changes when the container is replaced. Any rule written against it either hard-codes a hash that will not exist after the next deploy, or needs a regex broad enough to swallow all of them. Scale that across a fleet of ephemeral replicas and the ruleset stops being maintainable by hand.

Wazuh's answer here is to not go there: its FIM module has no overlay-path handling (searching src/syscheckd for overlay or container returns nothing), the shipped configuration monitors /etc, /usr/bin, /usr/sbin, /bin, /sbin and /boot, and the default rootcheck config explicitly ignores /var/lib/docker/overlay2 and /var/lib/containerd. You can point it at an overlay path yourself — you will just get the raw hashed path back, and your rules have to cope with it.

kaimon's agent watches at host level and captures the fully qualified overlay path, then normalizes it before any rule or baseline is evaluated: known runtime prefixes for Docker, containerd, Kubernetes and LXC are stripped, so a baseline learned as /etc/nginx/nginx.conf matches wherever that file turns up. The same anomaly across a dozen transient replicas collapses into one finding rather than a dozen, and the original host path is preserved in the report so you keep the forensic detail. One agent covers the host and everything running on it — no sidecars, no image changes. An unrecognized runtime prefix degrades gracefully: the event is still monitored, it just surfaces without normalization.

It produces one daily report with an AI-written verdict per framework, mapped to SOC 2 CC6/CC7, HIPAA 164.312(c)(1), PCI DSS 10.5.5 and 11.5, and NIST SP 800-53 SI-7 — the evidence an auditor asks for, without a rule file anyone has to own. There is a full sample report here.

Side by side

That table is deliberately narrow — it covers where the two differ on file integrity monitoring specifically. Wazuh is a considerably broader product, it is free, and it is far more widely deployed than we are. See below for where it is the better choice.

Which one you should use

Wazuh, if you want one platform covering SIEM, log analysis, vulnerability detection, active response and FIM together; if you have someone who can own the ruleset; or if you need Windows and macOS coverage as well as Linux. It does considerably more than we do.

kaimon, if your problem is specifically Linux file integrity evidence for an audit, and the thing standing in your way is that nobody has time to author and maintain suppression rules.

If that is the position you are in, the sample report is the fastest way to judge whether the output is what your auditor wants. The trial is 14 days, no credit card — though it is worth knowing the baseline needs seven of those days before the output means much.