Following the Wh1t3 Rabbit - Practical Enterprise Security


Rafal (Principal, Strategic Security Services)

QA Lesson - Defect vs. Vulnerability

 Back in April 2008 one of my very first posts to this blog was titled "Security Vulnerability != Defect; Why?" and it stirred some discussion.  Over the past year I've spoken to more QA teams than I can probably remember, and the message has been carried through - but a recent article by Robert Auger at CGI Security gave me a mental nudge and got me to think this through again.  As I sat and wrote a reply to Robert's article, I was once again reminded of the example I use; I will share it here for everyone's comment.

  Consider the following example of defect versus vulnerability usage... and perhaps you'll be able to use it in your next discussion.

 The context for this is a conversation I had with the an IT leader at a very large auto manufacturer, sitting around a conference room table just after I had presented to them some security concepts and why security testing was a critical component to their organization.  After I was done, the IT Lead in the room (who won't be named here) looked at me and shook his head.  Curious, I couldn't help myself but to ask why he was spending so much money on quality-assurance, but not a penny on security; more importantly why I had not convinced him to spend security dollars.  This was his answer, and I think this perfectly illustrates my point, and why I now use defect instead of vulnerability when speaking to QA groups.

paraphrasing... "Vulnerabilities and defects are not the same thing, in fact, vulnerabilities aren't, in my opinion, anywhere near as important as quality defects.  In this industry, a defect is illustrated by a brake pedal that goes to the floor as your brakes fail when you mash them to stop in case of an emergency.  The brake failure is a defect which can lead to the loss of human life.  Defects are taken very seriously, and we do everything we can to avoid them.  A vulnerability is much different.  A vulnerability is likened to a car that is not theft-resilient.  A thief being able to easily break into the car, hot-wire it bypassing the starter-kill mechanisms (obviously without the keys) and drive away is a vulnerability.  Which do you suppose you would focus on if you were faced with both in front of you?"

 That struck me, and stuck with me.  While this IT Lead's analogy was spot-on for the automobile industry... unfortunately it didn't quite hold for the software development organization.  A defect was, in most cases, arguably not quite as critical as s security vulnerability - but neither will likely cause a loss of life (one would hope).  Anyway... I thought I would share this story so that the next time you're talking QA... remember to use the correct terminology... it makes the point that much more... understandable.

Labels: QA| terminology
About the Author(s)
Follow Us
Twitter Stream

Community Announcements
HP Blog

Technical Support Services Blog
