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
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
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
You make a very good point. I think we have lots to learn from
As a matter of practice, I usually use the terms that you suggested as
modifiers and say:
As long as there is a clear way to separate the two ends of the
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
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).
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
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,
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
I'm sorry, but it is just not possible to find design flaws by staring at code.
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
Um, so if there is no documentation you can't find design flaws?
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
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.
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
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
Mail list logo