No matter what wizardry your tools provide, it seems exceedingly unlikely that you're going to burn through the code at, say, 100 bytes per second without running the risk of missing something.

The fact that you are focused on insisting every byte of the code indicates that you are not yet familiar with the process of how this works.

By way of background, I have done security source code audits of systems on the order of 750,000 lines of code. This was done in a 12 week effort. The approach taken with source code review is possibly different than you think. One part of the approach is to look for patterns of code that are known vulnerability patterns, such as sql injection, or opening a socket. You then trace back to code paths that lead to that to determine how external input (that is user-controlled or attacker-controlled) can be use to trigger those vulnerable pieces of code. Another part of the approach is to look at each of the inputs (or interfaces) to the code to determine how those inputs can influence behavior of the program. One is likely to switch back and forth between these instances.

One key approach in looking at the code is to ask "can user input cause the program to choose one path of a branch or another." Another key approach is to ask "can the user's actions cause a change in one word of the programs memory." From that, an exploit can be crafted.

So you might well now ask "ok so that is source code. Object code is orders of magnitude more difficult." This is not really the case. The tools that 'tptacek mentioned take apparently impenetrable object code and transform it to assembly language (as well as to an intermediate language ESIL), and answer many questions about the static and dynamic nature of the code under inspection. Also, you can get differences of the call graphs from one version to the next. This trick was used to detect a vulnerability resolved by a Windows patch in a common library. It was noted through this tool that there was another use of this library elsewhere in the system that left the vulnerability in. This is without having source.

In fact, for the most serious level of analysis, one should go directly for the binary, as who knows how the source code actually corresponds with what binary actually gets shipped.

And it turns out one can effectively audit code for a language that one is not an expert in. The key elements are "where are the branches" and "what are the call graphs" and "what are the inputs and outputs".

In another thread, you note that you are an expert and that you are involved in the production of a security product. I am as well, having been in the software development business for 52 years, the last 10 in the security field, focusing on software security. And I can testify that these are two different fields of expertise. An expert in software development, even of security products, does not automatically mean that one is an expert in finding security flaws in code.

I've trained many software engineers in software security, and a key part of that training is to note that software engineering builds up programs and solutions by using previously developed abstractions, and making new abstractions that use existing ones. A penetration tester will develop skills in penetrating abstractions. It is a different way of thinking, a different kind of expertise. It is clear from your work that you are excellent at building up abstractions.

There are a couple of ideas that you are missing, I think. One is that evaluating the "rate of burn" through the bytes of a binary blob is a useful way to determine the difficulty of assessing the security. (Nor is it a useful way to evaluate software productivity) It is not necessary to look at every byte. Think of looking at every basic block. I suspect you will get a number that is different by two orders of magnitude than what you are currently thinking.