I'm far from an expert, but we know it takes a village.
As far as static analysis goes, I can think of something quite simple. Running strace on your processes to see what sort of syscall and filesystem access the process needs (in a trusted scenario - a maintainers burden). Once that analysis is done, applying proper security features (in unix - seccomp filtering (for syscalls) and landlock (for filesystem access)) could be done to minimize risk.
A caveat to this, however, can be seen in the xz attack. The attacker forced the landlock feature to not compile or link, which allowed it to have the attack surface needed. So they were practicing good security, however it means nothing if maintainers cannot audit their own commits. That is more of a general programming static analysis I believe you were going for. In which case, I believe many compilers come with verbose static analysis features. Clang-tidy is one, for example. Rust is already quite verbose. Perhaps with more rigid CI/CD restrictions enforced with these analysis tools, such commits would not be able to make it through?