Keelix vs Lynis

Lynis answers: “Is this Linux host hardened?” It runs on the host itself, performs hundreds of individual tests across SSH configuration, kernel parameters, package management, authentication controls, file permissions, and logging — and outputs a prose log of warnings and suggestions alongside a hardening index. It is GPL-3.0, free, and has been the go-to host auditor since 2007. It belongs in your toolkit.

Keelix answers: “Is this deployed box fit to ship — host, containers, exposure, and AI agents included?” It scans from outside the box in, checks which ports are actually reachable from the internet (accounting for Docker's iptables rules that silently bypass UFW), inspects running containers, and grades every AI agent and MCP server on the machine for auto-approval, plaintext secrets, and the lethal trifecta. The result is a 0–100 posture score mapped to CIS Docker Benchmark, SOC 2, and ISO 27001 — exportable as audit evidence.

Where Lynis is deep on the host layer, Keelix is wide across the whole deployed stack. Neither does the other's job. A Lynis scan tells you nothing about whether your Redis container is reachable from the open internet, whether a running MCP server auto-approves all tool calls, or whether a plaintext Anthropic API key is sitting in a .mcp.json config file. A Keelix scan does not replace Lynis's SSH hardening depth or its extensive host checks.

After a Lynis scan completes, you know the state of your Linux host — SSH, kernel, packages, auth. What you still do not know:

• Whether Docker's iptables rules have bypassed your firewall and exposed a container port to the open internet — Lynis does not perform outside-in network checks.
• Whether a running MCP server on the box auto-approves every tool call — turning any prompt injection into a full agent takeover without requiring a vulnerability.
• Whether your Claude Code, Cursor, or Windsurf config has a plaintext API key or database password stored in a plaintext MCP config file.
• Whether a deployed AI agent has all three legs of the lethal trifecta simultaneously active.

These are not host-layer issues. They emerge at the intersection of the container runtime, the network, and the AI agent configuration — the surface that appeared in deployed stacks only after 2024. Lynis predates it. Keelix was built for it.

Both Lynis and Keelix distill their findings into a single numeric score — but they measure different things and serve different audiences.

Lynis's hardening index is an indicator of the hardening measures Lynis detected on the host. The Lynis documentation is explicit: it is “just an indicator on taken measures — one should not confuse it with a percentage of how safe a system might be.” It is generated from the warnings and suggestions in the prose report, and it lives in the scan log. There is no structured export, no compliance mapping, and no persistent history without running your own tooling.

Keelix's posture score is computed from 93 deterministic checks, each explicitly mapped to a CIS, SOC 2, or ISO 27001 control. The score is designed to gate CI — a deployment below a threshold fails the pipeline. It also generates a structured evidence bundle you can attach to an audit rather than a log file you must interpret manually.

Neither score is a definitive “safe” signal in isolation. Used together, they cover more ground: Lynis's host depth + Keelix's container, exposure, and AI/MCP width.

A practical hardening workflow for a self-hosted Docker server looks like this: run Lynis periodically (weekly cron or on OS-change events) for deep host-layer auditing — SSH, kernel, packages, auth. Integrate Keelix into your CI/CD deploy pipeline as a posture gate before every production promotion, catching container, exposure, and AI/MCP findings that only appear at deployment time.