That's the point of a trusted build farm. Devs commit changes to git, and either request a build or the build farm polls for commits and builds the latest commit on trusted hardware+toolchain.
A malicious attack could change the code but it would be detectable because git would preserve the malicious parts in the repo, and further tie a specific malicious binary to a particular commit making it easy to find the malicious code itself.
As long as not all developers are compromised then whoever is doing the code review would see the malicious code when they pull the branch to review it.
> further tie a specific malicious binary to a particular commit
Git uses SHA1 for hashes, right? Aren't there demonstrations that SHA1 hashing is cracked, so you could craft a replacement commit that hashed to the same value, in theory.
SHA1 hash collisions are hard, especially when the data you can inject needs to look like code to a human and compile correctly. But the concern is valid so it's good that git is improving in this way.
A malicious attack could change the code but it would be detectable because git would preserve the malicious parts in the repo, and further tie a specific malicious binary to a particular commit making it easy to find the malicious code itself.
As long as not all developers are compromised then whoever is doing the code review would see the malicious code when they pull the branch to review it.