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

Trevor L. Jackson, III

There is nothing special brought to the table with regard to "security" when it comes to avoiding buffer overrun bugs. It is a matter of software correctness, which has always been a goal of professional developers whether "security" is specifically involved or not. If the broken apps had been properly developed, they simply would not *have* any buffer overrun bugs, which perforce takes care of the security aspect we were discussing.

Actually De Marco and Yourdon were promoting essentially the same methodologies at the time. And the very problem we're addressing is that too much "real-life" software is not developed using a sufficiently good process. Trying to accommodate such "real-life" practice is in effect giving up in advance, since that is where the problems actually arise.

When "object-oriented" methods are being employed, some minor modifications to the "clbuttical" approach are needed, but the general procedural methods such as structured code walkthroughs apply to any project.

In fact I've used De Marco's methodology on a couple of large development projects, and it worked quite well.

Yes, that was my intent in mentioning the book.

A rule of thumb is that 90% of the development cycle should be spent on specification, analysis, design, and documentation, and 10% on coding and testing. Coding is easy when one starts with clear and complete specs.

Yes, and buffer overruns are even a "clbuttical" kind of bug.

Actually it is best for security to be part of the planning all along; in many cases if it isn't integral to the design then there is no feasible way to bolt it on afterwards.