Keelix vs Trivy

Trivy answers: “Does this image contain known CVEs?” It is exceptionally good at it. Run trivy image nginx:latest and you get a complete CVE report across OS packages and language dependencies, an SBOM, and misconfiguration findings in Dockerfiles and Kubernetes manifests. It is fast, local, and Apache-2.0. It belongs in your pipeline.

Keelix answers: “Is this deployed box fit to ship — including the AI agents and MCP servers running on it?” It scans from outside the box in, checks what ports are actually reachable from the internet, audits host config against 93 CIS/SOC 2/ISO 27001 controls, and grades every AI agent and MCP server on the machine for auto-approval, plaintext secrets, and the lethal trifecta. The result is a single 0–100 score you can gate CI on.

Neither tool does the other's job. Trivy cannot tell you whether your Claude Code config is storing a plaintext Anthropic API key, or whether port 2375 is reachable from the open internet because Docker silently bypassed UFW. Keelix does not produce CVE-by-CVE image reports. Together they cover the whole attack surface.

When you run Trivy, you know whether your container image has a critical CVE. What you still don't know after the scan completes:

• Whether an MCP server running on that host auto-approves all tool calls — turning any prompt injection into full agent takeover.
• Whether your Claude Code or Cursor config file has a plaintext API key sitting beside a database password.
• Whether the port your Redis instance is bound to is actually reachable from the open internet because Docker bypassed UFW.
• Whether a deployed AI agent has all three legs of the lethal trifecta — private data access, untrusted input, and an exfiltration channel — simultaneously in play.

None of these are image-layer issues. All of them are deployment-context issues. They show up at runtime, on the box, in the config that was provisioned after the image was built. That is exactly what Keelix scans.

Both tools run locally and are Apache-2.0. For Keelix, local-first is non-negotiable by design: secrets are redacted at the scan boundary, and nothing — not a host config value, not an API key Keelix detected and flagged — ever leaves your machine. The posture score is computed on-box.

That design choice became a sharper selling point in March 2026, when a supply chain attack on Trivy's GitHub Actions infrastructure compromised 76 of 77 release tags in aquasecurity/trivy-action. CI pipelines running pinned version tags executed a multi-stage credential stealer before the legitimate scan ran — silently, with normal scan output. The exposure window for users running pinned trivy-action tags was approximately twelve hours before safe versions were available. No commercial Aqua products were affected.

The lesson isn't “stop using Trivy.” The lesson is: pin your Actions to full immutable commit SHAs, not mutable version tags — and know exactly what each scanner can and cannot see in your pipeline.

A practical CI pipeline for a self-hosted Docker deployment looks like this: Trivy scans the image in the build stage for CVEs and IaC misconfigurations, gates on CRITICAL findings, and outputs an SBOM. Keelix runs in the deploy-to-staging stage, scans the live box for host config, exposure, and AI/MCP posture, and gates on a posture score below your threshold before promote-to-production.