Re: [SC-L] Bugs and flaws

2006-02-02 Thread John Steven
Kevin, Jeff Payne and I were talking about this last night. Jeff's position was, ...Or, you could just use the existing quality assurance terminology and avoid the problem altogether. I agree with you and him; standardizing terminology is a great start to obviating confusing discussions about

RE: [SC-L] Bugs and flaws

2006-02-02 Thread Gary McGraw
Hi all, When I introduced the bugs and flaws nomenclature into the literature, I did so in an article about the software security workshop I chaired in 2003 (see http://www.cigital.com/ssw/). This was ultimately written up in an On the Horizon paper published by IEEE Security Privacy. Nancy

RE: [SC-L] Bugs and flaws

2006-02-02 Thread Chris Wysopal
In the manufacturing world, which is far more mature than the software development world, they use the terminology of design defect and manufacturing defect. So this distinction is useful and has stood the test of time. Flaw and defect are synonymous. We should just pick one. You could say that

RE: [SC-L] Bugs and flaws

2006-02-02 Thread Gary McGraw
Hi Weld, You make a very good point. I think we have lots to learn from manufacturing. As a matter of practice, I usually use the terms that you suggested as modifiers and say: implementation bug design flaw software defect As long as there is a clear way to separate the two ends of the

RE: [SC-L] Bugs and flaws

2006-02-02 Thread Gavin, Michael
Architecture is also an overloaded term, often meaning either a design (the output of architects) or the implementation of certain types of design (the output of engineers). Hoping to clarify Chris's comment on architecture flaws: architecture defects as in the defects in the output produced by

Re: [SC-L] Bugs and flaws

2006-02-02 Thread Crispin Cowan
John Steven wrote: Re-reading my post, I realize that it came off as heavy support for additional terminology. Truth is, we've found that the easiest way to communicate this concept to our Consultants and Clients here at Cigital has been to build the two buckets (flaws and bugs). My main

[SC-L] Administrative: whitelisting on SC-L

2006-02-02 Thread Kenneth R. van Wyk
Hi SC-L folks: I don't mean to intrude in the bug and flaw debate, but I do want to make sure that you're all aware of the whitelisting that I'm doing on the list these days, since I switched the list management from Majordomo to Mailman. Specifically, in order to cut down on spam, I have

RE: [SC-L] Bugs and flaws

2006-02-02 Thread Jeff Williams
At the risk of piling on here, there's no question that it's critical to consider security problems across the continuum. While we're at it, the analysis should start back even further with the requirements or even the whole system concept. All of the representations across the continuum (rqmts,

RE: [SC-L] Bugs and flaws

2006-02-02 Thread Brian Chess
I spent Phase One of both my academic and professional careers working on hardware fault models and design for testability. In fact, the first static analysis tool I wrote was for hardware: it analyzed Verilog looking for design mistakes that would make it difficult or impossible to perform design

RE: [SC-L] Bugs and flaws

2006-02-02 Thread Gary McGraw
I'm sorry, but it is just not possible to find design flaws by staring at code. gem -Original Message- From: Jeff Williams [mailto:[EMAIL PROTECTED] Sent: Thu Feb 02 20:32:29 2006 To: 'Secure Coding Mailing List' Subject:RE: [SC-L] Bugs and flaws At the risk of piling

RE: [SC-L] Bugs and flaws

2006-02-02 Thread Jeff Williams
Um, so if there is no documentation you can't find design flaws? --Jeff -Original Message- From: Gary McGraw [mailto:[EMAIL PROTECTED] Sent: Thursday, February 02, 2006 8:50 PM To: Jeff Williams; Secure Coding Mailing List Subject: RE: [SC-L] Bugs and flaws I'm sorry, but it is just

RE: [SC-L] Bugs and flaws

2006-02-02 Thread Gary McGraw
Not unless you talk to the designer. You might get lucky and find a design problem or two by looking at code, but that usually doesn't work. That's not to say that all systems have adequate documentation about design (not to mention requirements that you correctly cited before)! They don't.

RE: [SC-L] Bugs and flaws

2006-02-02 Thread Jeff Williams
That's not my experience. I believe there are many design problems you can find more quickly and, more importantly, accurately by using the code. I find this to be true even when there is a documented design -- but there's no question in the case where all you have is code. In fact, if the design

RE: [SC-L] Bugs and flaws

2006-02-02 Thread Chris Wysopal
In the manufacturing world, manufacturing defects are defects that were not intended by the design. With software, an implementation defect is a defect that is not indended by the design. That is where I see the analogy. A factory worker forgetting to put on a washer or installing a polarized