It's not just reading the code -- static analysis tools can provide some guarantees that the software isn't exfiltrating information from your box, making unsolicited connections, or leaving unexpected ports open.
In theory, we can perform the same analysis on the compiled program's bytecode. As the decompilation ecosystem gets better, we may view machine code or bytecode as transparently as source code.
Of course, your apple EULA may bind you against decompiling the machine code -- but it can be argued that you're not 'reverse engineering', you're just doing a virus scan.
Static analysis tools are very useful for identifying accidental security defects, however they really don't guarantee the absence of a deliberate security flaw or back door. You have to assume that the attacker has access to the same static analysis tools, and can thus find tricky ways to cause false negative scan results. Or perhaps the static analysis tool itself has been compromised?
All fair points -- nothing is guaranteed, but sooner or later you have to trust your tools. Like, maybe there's a backdoor in your compiler so certain lines of code are compiled so that they notify chairman mao when you shop for red notebooks ... .
The repeatable builds projects go a long way towards preventing this by producing identical bytes from different compilation chains. Ultimately it's good to have a combination of static analysis, multiple toolchains & 'many eyes' providing checks and balances for each other.
In theory, we can perform the same analysis on the compiled program's bytecode. As the decompilation ecosystem gets better, we may view machine code or bytecode as transparently as source code.
Of course, your apple EULA may bind you against decompiling the machine code -- but it can be argued that you're not 'reverse engineering', you're just doing a virus scan.