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 capacitor backwards is similar to a programmer neglecting to check a return code or being off by one in a length calculation.
In both disciplines, to increase quality you could say "don't do that", you could add a quality process that tests for the correct implementation, or best, you could make it impossible for the mistake to happen. So I guess I see a lot of similarities between the manufacturing process and the software implementation process. Sure its not a perfect analogy. Nothing seems to be between the physical and digital worlds. As you say, many of the flaws created during what is traditionally known as implementation are low-level design errors but at the very end of the continuum they are simply mistakes. -Chris On Thu, 2 Feb 2006, David Crocker wrote: > 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 the problems of defective materials, > difficulties in keeping dimensions within a precise tolerance, or wear > and tear. > > If some small bolt in my car fails because the bolt met its > manufacturer's specification but was not strong enough to withstand the > loads it was subjected to, that is a low-level design error, not a > manufacturing error. Similarly, I view coding errors as low-level design > errors. > > David Crocker, Escher Technologies Ltd. > Consultancy, contracting and tools for dependable software development > www.eschertech.com > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Chris Wysopal > Sent: 02 February 2006 21:35 > To: Gary McGraw > Cc: William Kruse; Wall, Kevin; Secure Coding Mailing List > Subject: RE: [SC-L] Bugs and flaws > > > > 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 > the > term for manufacturing software is "implementation". > > So why do we need to change the terms for the software world? Wouldn't > "design > defect" and "implementation defect" be clearer and more in line with the > manufacturing quality discipline, which the software quality discipline should > be working towards emulating. (When do we get to Six > Sigma?) > > I just don't see the usefulness of calling a "design defect" a "flaw". "Flaw" > by > itself is overloaded. And in the software world, "bug" can mean an > implementation or design problem, so "bug" alone is overloaded for describing > an > implementation defect. > > At @stake the Application Center of Excellence used the terminology "design > flaw" and "implementation flaw". It well understood by our customers. > > As Crispin said in an earlier post on the subject, the line is sometimes > blurry. > I am sure this is the case in manufacturing too. Architecture flaws can be > folded into the design flaw category for simplicity. > > My vote is for a less overloaded and clearer terminology. > > -Chris > > P.S. My father managed a non-destructive test lab at a jet engine > manufacturer. > They had about the highest quality requirements in the world. So for many > hours > I was regaled with tales about the benefits of performing static analysis on > individual components early in the manufacturing cycle. > > They would dip cast parts in a fluorescent liquid and look at them under > ultraviolet light to illuminate cracks caused during casting process. For > critical parts which would receive more stress, such as the fan blades, they > would x-ray each part to inspect for internal cracks. A more expensive process > but warranted due to the increased risk of total system failure for a defect > in > those parts. > > The static testing was obviously much cheaper and delivered better quality > than > just bolting the parts together and doing dynamic testing in a test cell. > It's > a wonder that it has taken the software security world so long to catch onto > the > benefits of static testing of implementation. I think we can learn a lot more > from the manufacturing world. > > On Thu, 2 Feb 2006, Gary McGraw wrote: > > > 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 Mead and I queried the SWEBOK and looked around to see if the > > new usage caused collision. It did not. The reason I think it is > > important to distinguish the two ends of the rather slippery range > > (crispy is right about that) is that software security as a field is > > not paying enough attention to architecture. By identifying flaws as > > a subcategory of defects (according the the SWEBOK), we can focus some > > attention on the problem. > > > > >>From the small glossary in "Software Security" (my new book out > > tomorrow): > > > > Bug-A bug is an implementation-level software problem. Bugs may exist > > in code but never be executed. Though the term bug is applied quite > > generally by many software practitioners, I reserve use of the term to > > encompass fairly > > simple implementation errors. Bugs are implementation-level problems > > that > > can be easily discovered and remedied. See Chapter 1. > > > > Flaw-A design-level or architectural software defect. High-level > > defects cause 50% of software security problems. See Chapter 1. > > > > In any case, I intend to still use these terms like this, and I would > > be very pleased if you would all join me. > > > > gem > > > > > > > > ---------------------------------------------------------------------- > > ------ > > This electronic message transmission contains information that may be > > confidential or privileged. The information contained herein is intended > > solely for the recipient and use by any other party is not authorized. If > > you are not the intended recipient (or otherwise authorized to receive this > > message by the intended recipient), any disclosure, copying, distribution or > > use of the contents of the information is prohibited. If you have received > > this electronic message transmission in error, please contact the sender by > > reply email and delete all copies of this message. Cigital, Inc. accepts no > > responsibility for any loss or damage resulting directly or indirectly from > > the use of this email or its contents. > > Thank You. > > ---------------------------------------------------------------------------- > > > > _______________________________________________ > > Secure Coding mailing list (SC-L) > > SC-L@securecoding.org > > List information, subscriptions, etc - > > http://krvw.com/mailman/listinfo/sc-l > > List charter available at - http://www.securecoding.org/list/charter.php > > > _______________________________________________ > Secure Coding mailing list (SC-L) > SC-L@securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > > > _______________________________________________ > Secure Coding mailing list (SC-L) > SC-L@securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
