Decompile and read the resulting source code, then snuff the network traffic to make sure it’s matching what’s expected. Trusting the Hardware and OS is a larger issue.
People always take that lightly, as if it's trivial to read bytecode (tptacek takes that stance a lot if I recall correctly, and his being him, people take it for gospel). Just looking at the underhanded C (style) contests, it's not trivial to spot backdoors in the source code, let alone the code that a machine is meant to interpret after it ran through a compiler. If it were so trivial to find the flaws that allow attacks in the easiest-to-read of code (open source, docs available, mitigations applied, nice choice of language, everything), we would not have security issues in good software in the first place.
As I said reading the source code is only the first step, you also sniff network traffic. A program that’s only sending data you understand can’t also be sending data you don’t want it to send.
Of course this isn’t trivial, but the point of comparison was an open source application which has exactly the same underhanded C style risks. The hardest to evaluate risk is simply using a subtly flawed algorithm or source of entropy which looks secure in any language, but isn’t.
