Following the White Rabbit - A Practical Security Blog
Welcome! Let's follow the White Rabbit down the Web Application Security rabbit-hole... This blog is less about awesome h@><0ring and more about practical, real-world web app security measure and counter-measures. If you're looking for a blog to relate to your day-job - this may just be it. As long as you're here, bookmark (Ctrl + D) it, drop it in your reader and leave a comment!

"Security Vulnerability" != "Defect" ; why?

It's one of those obvious things.  A defect is a defect, right?  Whether the airbag is faulty, or the gas cap doesn't hold pressure... a defect is a defect.  The strange thing is - it hasn't been that way, and still isn't that way, in most of the IT shops I've been in.  Why?

The reason is simple.  Historically, security vulnerabilities have been in a class all their own.  In an attempt to put some urgency to the matter, security professionals have labeled defects in the security of their projects (in this case I'm talking about web applications) as an entirely different thing than a functional defect.  What we didn't realize is that we were actually doing a dis-service to ourselves and the security cause.  You may not agree with me right now - but I'll explain this more clearly, and I think you'll be on board with my thought process.

Let's talk about defects, in general and then apply it to the matter at hand.  First, let's identify what a defect is...  A defect is, in the dictionary sense (cut from

de·fect       Pronunciation Key - Show IPA Pronunciation

1.a shortcoming, fault, or imperfection: a defect in an argument; a defect in a machine.
2.lack or want, esp. of something essential to perfection or completeness; deficiency: a defect in hearing.

OK, easy enough right?  So the first meaning is clear; a defect is a shortcoming, fault, or imperfection.  It is reasoned that a defect in a web-based application results when functionality X doesn't work as required.  Say you have a button, and the functional specification (we'll get back to this gem in a minute) calls for the button to perform some action, A.  During the testing phase of the application, before release to production, a tester or tool is utilized to test the functionality of that button, but instead of action A happening, some other action B happens.  This is a defect.  There is no doubt in anyone's mind that this immediately gets classified as a defect, put into the defect tracking system and sent back to the developer for remediation.  The defect is classified as a higher-priority defect if the function happens to be one that is showcased, or important to the overall functionality of the application.  Those of you that already use the HP Quality Center tools know exactly what I'm talking about, and know how this process works.  Here's the strange twist though - why is quality testing only done with good data?  I understand that you want to make sure that the test cases work properly - but why are the testing options limited?  The issue at hand here is a very narrow view of defects, and defect testing.

Back in college, I took very basic programming class and had to write a program that was a calculator.  It would ask for two inputs of numbers, and then give you an option to perform either an addition, subtraction, multiplication or division of the inputs.  Generally, it was assumed that these would be numbers, but what if they weren't numbers?  Most of the students in the class, myself included, never thought about ... "What if someone enters a letter or some other unexpected input?"  Well, luckily, the professor chose my application, put it up on the screen for the whole class to see, and promptly entered a and b for the two inputs and tried to add them.  When my application core dumped, he explained to the class why I had gotten my first F on a project.  I learned a very valuable lesson that day - developers must brace their applications for unexpected input.  "Why would anyone want to enter something other than numbers?" wasn't a good enough answer to explain why my application failed.  Let's apply this lesson I learned back in college to today's application programmers and functional testers.

Here are the reasons why I think security vulnerabilities aren't seen as "defects" in general...

  1. Security professionals have insisted that a vulnerability is its own separate category - While it is true, some security vulnerabilities are a whole new level of "bad" they should be considered just like any other defect in the application for the sake of tracking and remediation.  Web platform managers are generally concerned with meeting the demands of their customers and producing code that is defect-free - and it's our own fault that "vulnerabilities" of the security variety have become some ethereal, magical issue for security nerds to worry about.  This matter can only be fixed by changing the naming back... a vulnerability is a defect, period.  Security vulnerabilities must be explained as "high-criticality defects" to developers, managers and customers otherwise this situation will never change.
  2. Functional specifications rarely, if ever - call for for security validation - Functional specifications aren't written by security professionals, generally.  At best, security professionals have a chance to review the functional specification way too late into the process, while the code is being written and readied for production.  This is, once again, our own fault most of the time.  The answer to this dilemma is a two-pronged attack.  We as security professionals must educate those that write functional specifications, and enlighten them to the need for security features.  At the same time, we must work hard to have an active input in the writing and release of functional specification documents.  These two vectors are critical to getting secure code as an end-product.
  3. Programmers don't typically think about malicious users - While it would be great to think that one day all developers will inherently write secure code because they will have "learned" what security is, and how important it is to the application - the fact is that it's a pipe dream.  Developers care about one thing... meeting functional specifications in the least amount of time possible, and moving on to the next project.  Developers like to write optimized code that accomplishes the required tasks in as little time as possible.  Solving #2 above will also partly solve this problem.  In addition, developers must be given the tools (such as static and dynamic code analysis tools as plug-ins to their IDEs) to make their jobs easier.  It is not reasonable to expect developers to be security experts in all aspects, so we must arm them with the tools to be experts, without having to do too much extra work or they won't use those tools.

So what have we learned today?

  • Security vulnerabilities must be re-classified as easily-understandable "functional defects"
  • Funcitonal specifications must be written to include provisions for security validation
  • Quality professionals must be given the tools to test for "security defects" in web applications to close the loop in the lifecycle
  • Developers must be educated and also given the tools to write more secure code with minimal additional effort

-- I welcome your comments!

Anonymous | ‎04-02-2008 01:27 AM
You've been kicked (a good thing) - Trackback from
Anonymous | ‎04-08-2008 01:56 AM
Software products have a list of functional specifications and it is expected that they have no more functions/behaviors than what is specified.

For example: Should the system receive a "ping of death" it will blue screen right away.

This statement is most probably not in the specification of the good old XP however this behavior had been shown by the system.

As such I think that vulnerabilities are un-specified features of products, creating mostly un-desirable results.

It is my expectation that software products have no behavior other then the ones specified, so any non specified feature is a gap between specification and implementation and is a ... defect.

Looking at the problem in this way I come to the (natural) conclusion that vulnerabilities are defects.
Showing results for 
Search instead for 
Do you mean 
About the Author

Follow Us
Follow the White Rabbit on Twitter! Home
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.