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

Trevor L. Jackson, III

Well, I only wish we had people like you managing more of our security-critical software projects, and I wish we had an industry that made it possible to manage software development projects in this way, and that rewarded such good stewardship.

Do you have any idea how the cost, and time-to-market, of this kind of approach, compared to how most commercial software is developed today? Is it 2x what we spend today?

Can you elaborate on 5. and 6.? One thing I didn't understand about the quality butturance phase is why these folks need to be articulate. Why do they need good English skills and ability to speak clearly about software? Who are they communicating with? Also, I wonder what the tradeoffs are on staffing the quality butturance phase. Today, most software development shops have one crew of developers, and another crew of testers. If quality butturance involves more than testing, who would you have doing the other quality butturance efforts?

Also, on 6., I'm not sure I understand what you mean. If we're talking about a security review, I'm convinced that it is critical to look at the whole system, not just the individual components. You need to understand the interactions between components. If you are familiar with the so-called "composition problem" in computer security, that is referring to the effect where you can take components which on their own are perfectly secure, and when you put them together into a system you get something that is, taken as a whole, insecure. And you probably need to look at the whole system to evaluate the threat model. Finally, pragmatically, as a security reviewer, I think it is important to look at the whole system so that one can understand which components are trusted for which purposes and so that one can prioritize the review task.