I guess I can begrudgingly accept that this is an example of &quot;defense in depth&quot; but it doesn&#x27;t seem like a very good one given how easily it can be bypassed. Like, you could equally well add &quot;depth&quot; by taking every password prompt and making it prompt for two different passwords, but of course that doesn&#x27;t add any real security.&gt; for example, through misconfigured deployments, command injection, [...] or overly broad privileges.Seems to me like it would be more useful to build something into your deployment process that verifies that permissions are set correctly.I don&#x27;t really buy that `mount -o ro` is inherently more prone to being misconfigured than `kekkai verify` or whatever.&gt; supply chain attacksThis wouldn&#x27;t actually do anything to stop or detect supply chain attacks, right? Even if one of your dependencies is malicious, you&#x27;re not going to be able to spot that by checking a hash against a deployment that was built with the same malicious code.&gt; good implementations isolate the baseline and reports (e.g. write-only to S3, read-only on app servers), which raises the bar considerably.I don&#x27;t see how that raises the bar at all. The weakness is that it&#x27;s easy for an attacker to bypass the verifier on the app server itself. Making the hashes read-only in whatever place they&#x27;re stored isn&#x27;t a barrier to that.&gt; For example, PCI DSS (Payment Card Industry Data Security Standard) explicitly requires this.This seems like the best actual reason for this software to exist. But if the point is just to check a compliance box, then I think it would make sense to point that out prominently in the README, so that people who actually have a need for it will know that it meets their needs. Similar to how FIPS-compliant crypto exists to check a box but everyone knows it isn&#x27;t inherently any more secure.

&gt; In practice, attackers often find ways around those measuresI really don&#x27;t see this as a good explanation. You can say that about any security measure, but we can&#x27;t keep slapping more layers that check the previous layer. At some point that action itself will cause issues.&gt; for example, through misconfigured deployments, command injection, supply chain attacks, or overly broad privileges.Those don&#x27;t apply if the file owner is not the app runner or the filesystem is read-only. If you can change the file in that case, you can disable the check. Same for misconfiguration and command injection.&gt; For example, PCI DSSAh, BS processes. Just say it&#x27;s about that up front.

You&#x27;re right that FIM assumes the possibility of compromise, but that&#x27;s exactly the point - it&#x27;s a detection control, not a prevention control. Prevention (read-only mounts, immutable bits, restrictive permissions, etc.) is necessary but not sufficient. In practice, attackers often find ways around those measures - for example, through misconfigured deployments, command injection, supply chain attacks, or overly broad privileges.File Integrity Monitoring gives you a way to prove whether critical code or configuration has been changed after deployment. That’s valuable not only for security investigations but also for compliance.For example, PCI DSS (Payment Card Industry Data Security Standard) explicitly requires this. Requirement 11.5.2 states:&quot;Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification of critical content files, configuration files, or system binaries.&quot;Sure, a &quot;sufficiently advanced&quot; attacker could try to tamper with the monitoring tool, but (1) defense in depth is about making that harder, and (2) good implementations isolate the baseline and reports (e.g. write-only to S3, read-only on app servers), which raises the bar considerably.

I don&#x27;t really understand the use case for this. Despite all the details in the README, there are only a couple sentences devoted to describing what it&#x27;s actually for, and they don&#x27;t make much sense to me.You&#x27;re assuming that an attacker already has access to your system, and you want to detect any changes they make to certain files.If you are dealing with a relatively unsophisticated attacker, surely it would be easier to just mount the data that shouldn&#x27;t be changed on a read-only filesystem, or set the immutable bit?And if the attacker is sophisticated, surely they could just disable the verifier? Or replace it with a no-op that doesn&#x27;t actually check hashes?&gt; Many web apps (PHP, Ruby, Python, etc.) on AWS EC2 need a lightweight way to confirm their code hasn’t been changed.I don&#x27;t think this is true, any more than the square-root function needs a way to confirm that its argument hasn&#x27;t been tampered with. You&#x27;re solving the problem in the wrong place. It seems like security theater.

AIDE is a solid and mature tool. Kekkai focuses on being lightweight:content-only hashing to avoid false positives,S3 integration with strict write&#x2F;read separation,a single Go binary with minimal dependencies.
It’s designed to be easy to deploy and run in production.

I posted about AIDE a few weeks ago. I have not checked how that compares to this submission:<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=44688636">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=44688636</a>

Conceptually it’s the same as sha256sum, but Kekkai automates the workflow:hashes recorded automatically at deploy,stored in S3 with write&#x2F;read separation,verification runs regularly.
It saves you from scripting all of that by hand.

How is this different from sha256sum (and variants)? Create, store and check file hashes?

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

&gt; a simple, fast ... toolWhat does &quot;fast&quot; mean here? Fast compared to what?

I built a tool called *Kekkai* for file integrity monitoring in production environments.
It records file hashes during deployment and later verifies them to detect unauthorized modifications (e.g. from OS command injection or tampering).Why it matters:* Many web apps (PHP, Ruby, Python, etc.) on AWS EC2 need a lightweight way to confirm their code hasn’t been changed.
* Traditional approaches that rely on metadata often create false positives.
* Kekkai checks only file content, so it reliably detects real changes.
* I’ve deployed it to an EC2 PHP application in production, and it’s working smoothly so far.Key points:* *Content-only hashing* (ignores timestamps&#x2F;metadata)
* *Symlink protection* (detects swaps&#x2F;changes)
* *Secure S3 storage* (deploy servers write-only, app servers read-only)
* *Single Go binary* with minimal dependenciesWould love feedback from others running apps on EC2 or managing file integrity in production.

Show HN: Kekkai – a simple, fast file integrity monitoring tool in Go