Remix.run Logo
teraflop 3 days ago

I guess I can begrudgingly accept that this is an example of "defense in depth" but it doesn't seem like a very good one given how easily it can be bypassed. Like, you could equally well add "depth" by taking every password prompt and making it prompt for two different passwords, but of course that doesn't add any real security.

> 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't really buy that `mount -o ro` is inherently more prone to being misconfigured than `kekkai verify` or whatever.

> supply chain attacks

This wouldn't actually do anything to stop or detect supply chain attacks, right? Even if one of your dependencies is malicious, you're not going to be able to spot that by checking a hash against a deployment that was built with the same malicious code.

> 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't see how that raises the bar at all. The weakness is that it's easy for an attacker to bypass the verifier on the app server itself. Making the hashes read-only in whatever place they're stored isn't a barrier to that.

> 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't inherently any more secure.

catatsuy 2 days ago | parent [-]

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.