[nonameiguess]

It flags that because it could indicate someone got onto your system and injected their own code or changed machine instructions at the binary level, which is a pretty common way to get a remote shell.

It is annoying to have to mark false positives, but that's just the nature of the beast when it comes to being thorough about security. More annoying with this check than when you update packages in a container image instead of starting clean is that this same technique is often used to compare hashes of packages managed by an installer versus what is actually on disk, and thus flags every single package in a JIT-compiled language that caches byte code on disk as altered.

[acdha]

It’s because they’re implementing the feature so they can show a CISO a big scary report and say “good thing you paid us - otherwise you wouldn’t have known!”

If they were serious about build errors they could use the built-in features of APT, YUM, etc. to only report binaries which don’t match the canonical distribution’s hashes, as has been standard sysadmin practice for aeons.

[CameronNemo]

I have used Prisma Cloud / twistlock. The tampering detection is only useful for detecting changes to running containers, not for changes to binaries between layers. The latter is just dumb and causes anti-productive false positives like above.