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 problem with this terminology is that I have only ever seen it coming from Cigital people. The rest of the world seems to treat "flaw" and "bug" as synonyms.
The distinction here is between "design flaw" and "implementation flaw". There doesn't seem to be anything in these words that suggest one is larger scale than the other. >From dictionary.com we have: flaw^1 <http://www.answers.com/flaw&r=67>(flô) pronunciation /n./ 1. An imperfection, often concealed, that impairs soundness: /a flaw in the crystal that caused it to shatter./ See synonyms at blemish <http://www.answers.com/main/ntquery;jsessionid=75e32c5vb2csr?method=4&dsid=1555&dekey=B0319900&gwp=8&curtab=1555_1&sbid=lc04b>. 2. A defect or shortcoming in something intangible: /They share the character flaw of arrogance./ 3. A defect in a legal document that can render it invalid. "Bug" <http://www.answers.com/bug&r=67> is a little more arcane, and the only relevant part is far down the document where it discusses the history with Grace Hopper: bug An unwanted and unintended property of a program or piece of hardware, esp. one that causes it to malfunction. Antonym of /feature/ <http://www.answers.com/main/ntquery?method=4&dsid=2291&dekey=%2FF%2Ffeature.html&gwp=8&curtab=2291_1>. Examples: “There's a bug in the editor: it writes things out backwards.” “The system crashed because of a hardware bug.” “Fred is a winner, but he has a few bugs” (i.e., Fred is a good guy, but he has a few personality problems). Historical note: Admiral Grace Hopper (an early computing pioneer better known for inventing /COBOL/ <http://www.answers.com/main/ntquery?method=4&dsid=2291&dekey=%2FC%2FCOBOL.html&gwp=8&curtab=2291_1>) liked to tell a story in which a technician solved a /glitch/ <http://www.answers.com/main/ntquery?method=4&dsid=2291&dekey=%2FG%2Fglitch.html&gwp=8&curtab=2291_1> in the Harvard Mark II machine by pulling an actual insect out from between the contacts of one of its relays, and she subsequently promulgated /bug/ <http://www.answers.com/main/ntquery?method=4&dsid=2291&dekey=%2FB%2Fbug.html&gwp=8&curtab=2291_1> in its hackish sense as a joke about the incident (though, as she was careful to admit, she was not there when it happened). For many years the logbook associated with the incident and the actual bug in question (a moth) sat in a display case at the Naval Surface Warfare Center (NSWC). The entire story, with a picture of the logbook and the moth taped into it, is recorded in the /Annals of the History of Computing/, Vol. 3, No. 3 (July 1981), pp. 285--286. > What I was really trying to present was that Security people could stand to > be a bit more thorough about how they synthesize the results of their > analysis before they communicate the vulnerabilities they've found, and what > mitigating strategies they suggest. > Definitely. I think there is a deep cultural problem that people who fix bugs or flaws tend to over-focus on the micro issue, fixing the specific coding vulnerability, and ignore the larger architectural error that allows the coding defect to be exploitable and cause damage. In the case at hand, the WMF bug would be much less dangerous if there were not so many ways to induce IE to invoke WMF decoding without asking the user. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com Olympic Games: The Bi-Annual Festival of Corruption _______________________________________________ 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