All it means that the audit is superficial and doesn't catch the error category, just famous examples within that category. That kind of superficial sanning may be worth something when unleashed on security-naive developers or even as optional input for more experienced ones. But "hard compliance rules" and "superficial scans" combine to create a lot of busywork which makes people less motivated to work with auditors instead of against them.

The resulting situation might of course not be a net benefit though :/

Absolutely :)

The fact is that if you have experienced engineers a security audit is rarely able to find anything. You would basically have to do code reviews, and this is hard / expensive, and even then rarely fruitful.

So, superficial scans, hardening, checking for obvious mistakes is really all you can do. Making hard rules is unproductive, but then again, migrating from md5 to crc32 hopefully isn't very expensive.

IMO, crc32 is a better choice for testing for changes, and has the benefit of removing any doubt that the hash has any security properties.

(Unless the person looking over your shoulder has a really good memory and can remember the Base64, or decode it in their head. Or they have a camera.)

It's game over anyway if someone has a shell on your server but at least it complicates their life a bit.

    // We use MD5 to check if config files are changed. This is not used anywhere else.
    typedef DigestMD5 ConfigFileHasher;

I always assume that people from the future who are going to touch my code are really dumb people, so I try to have as few traps as possible for them.