Yesterday I had discussions with other IT security managers, and I made few references to this document : http://cm.bell-labs.com/who/ken/trust.html
Quote from the paper (here, "code" means "executable binaries") :
The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code.
In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect.
But please read the whole paper, it's really worth it !
So, you test your source code ? Good !
Is it enough ? Surely not !
What is really executed is what the processor really does. Not necessary what you asked in your high-level language. Not necessary what you wish it to do !
That's why, at Tetrane, we test ALL instructions the processor may execute, by analyzing the binaries of application, middleware it uses, parts of the kernel-drivers-firmware that are accessible by it.
Your application is not only composed by your application, but by every piece of code it will execute, including all dependencies and framework that will load and run it (your code, but also API libraries, Operating System (kernel, loader, linker, ...), firmware, etc. !
All this is what your software will actually do, all this is what the processor will really execute.