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 externally.
-gp Quoting Gary McGraw <[EMAIL PROTECTED]>: > 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
