John Steven wrote:
...
> 2) Flaws are different in important ways bugs when it comes to presentation,
> prioritization, and mitigation. Let's explore by physical analog first.
Crispin Cowan responded:
> I disagree with the word usage. To me, "bug" and "flaw" are exactly
> synonyms. The distincti
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 wh
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.
Na
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
t
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 sli
"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).
>
My ma
So from a countermeasure standpoint, a bug can and should be fixed locally,
while a flaw may require that the countermeasure exists at a different level of
abstraction. For example, I assume no one thinks (in OO at least) that input
validation is resident in every method, but rather called external
I don't think this analogy between software development and manufacturing holds.
There are no "manufacturing defects" in software construction, unless one counts
a buggy chip (e.g. Pentium FPU or similar) or perhaps a buggy compiler. Software
instructions execute predictably and are not subject to
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 M
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, a
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.
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 on
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 not
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
polarized cap
17 matches
Mail list logo
