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

Brian Inglis

As far as I can tell, they are mostly guessing. They can't point to a large piece of software built with their favorite techniques, that was exposed to the Internet, and that was free of buffer overruns the first time. (That's because it is a hard problem, not because they are poor programmers -- but the very first step is to admit that it is a non-trivial problem.) At least, I have yet to hear anyone give empirical evidence for their claim that buffer overruns are easy to prevent if we only use their development process. Meanwhile, we have plenty of empirical evidence that buffer overruns are uniformly hard. for almost everyone in this business.

If you ask me why avoiding buffer overruns is non-trivial, I would be hard-pressed to give you a definitive answer. My best guess is that, if you're building a big piece of software, you have thousands of chances to make a mistake, thousands of opportunities where (in many languages) any error leads to a buffer overrun vulnerability. Even if your error rate is only a few defects per thousand (and this is an amazing accomplishment which probably requires major effort to achieve), that's still not good enough, because just one buffer overrun is enough to render your system insecure. That's only a conjecture, and I don't have hard evidence for this explanation. Nonetheless, even though my guess at the core cause of buffer overruns is conjectural, my claims about the difficulty of buffer overruns are not conjectural -- the empirical data we have available to us looks pretty much unequivocal at this point.