catatsuy

That’s a great real-world story. Exactly the kind of unexpected modification FIM can help surface—not only security incidents, but also operational surprises.

Compliance is definitely one use case, but not the only one. It’s also useful for catching unexpected local changes in real-world operations. The goal is to provide a lightweight FIM that can be added to existing apps without too much friction.

Conceptually it’s the same as sha256sum, but Kekkai automates the workflow:

hashes recorded automatically at deploy,

stored in S3 with write/read separation,

verification runs regularly. It saves you from scripting all of that by hand.

By fast I mean two things:

Files are hashed in parallel, so large sets can be processed quickly.

On repeated runs, unchanged files skip hashing with a default 90% probability using a cache. This keeps checks lightweight even at scale

You’re right that this doesn’t prevent compromise—it’s a detection control, not prevention. Things like read-only mounts or immutable bits are great, but in practice issues like command injection or misconfigured deployments still happen. FIM helps you know when files were changed and provides evidence for investigation or compliance.

AIDE is a solid and mature tool. Kekkai focuses on being lightweight:

content-only hashing to avoid false positives,

S3 integration with strict write/read separation,

a single Go binary with minimal dependencies. It’s designed to be easy to deploy and run in production.

Thank you for your reply.

I was thinking about whether to return an error. If we can’t find a UTF-8 start byte in the nearby 4 bytes, it’s unclear what to return. I thought maybe we could ignore this problem.

I don’t return the string itself because I don’t know if users want the start or the end of the string. Also, I want to avoid copying large strings. It’s up to the users how they use this function.

Since no one is using this package yet, we might consider changing the interface.