> If the government is worried about trojans, malware, etc., then they can easily hire an auditor to audit the code and vouch for its authenticity.
Not that I disagree with the general idea of democratizing this sort of big government contract, but, well, this is a much bigger hurdle than you are making it sound like. Audits can be good at finding unintentional flaws, but a skilled adversary can often create code that looks safe, but in fact, isn't. Consider the underhanded C contest: http://www.underhanded-c.org/
On a personal note: I once worked on a large research project for detecting malicious behavior on Android apps, where the idea was to produce tooling to find underhanded/undocumented behavior automatically. The project had a red team. By the final rounds, we were getting code from them where the malicious functionality was extremely hard to find via either tooling or manual inspection. Keep in mind these were simple programs, rarely over 10k lines of code, written in Java which is a remarkably transparent language to read, and that we were allowed to ban features like reflection or raise the alarm on anything that looked like intentionally obfuscated code. Additionally, we knew each of those programs had malware in them. Reporting 'clean' was often just saying 'you win, we give up, couldn't find it after staring at this 2k lines file for a week'.
In theory, when working with a large contractor, you can put controls on how the software is built, not just the final code, and you can hold them accountable for backdoors discovered long after the fact. Now, not saying this always works that way, but it might still be better than accepting a system built by someone you only know from their Github handle and who might or might not live within your jurisdiction. The state of the art in software verification would need to change a great deal before that is a good idea.