Thou shalt have no other gods before the ANSI C standard 1607

Trevor L. Jackson, III

Agreed.

Why do we need to know whether our development methodology is good enough (absolute criteria) to eliminate all buffer overruns? Because if our development process is not good enough, then we ought to be taking other steps to prevent or mitigate against such risks. For instance, until we have a development process that is demonstrably "good enough" to remove all buffer overrun defects, we should strive to use runtime "hardening" techniques (such as memory-safe languages, automatic bounds checking, StackGuard, non-executable stack and heap, sandboxing, program shepherding, etc.) as well as architectural and design methods (privilege separation, least privilege, decomposition according to security concerns, etc.) chosen to limit the impact of such bugs. We may wish to use many of these techniques anyway, but if we aren't sure that our development process is good enough to remove all buffer overruns, that is an additional motivation.

I guess it depends. Generally speaking, a good rule of thumb in security is to be conservative. As Gwyn once put it (and I probably will get the quote at least a little bit wrong), we should evaluate our systems according to the worst failure mode that is at all plausible under circumstances favorable to the attacker. Sometimes there is an attack that we think probably is unlikely to be feasible (maybe it requires a conjunction of the moon and stars), though we're not sure. In such a case, it is often a good idea to fix the software to provably eliminate the attack, even though we're not sure whether it would be a real threat in practice.