Introduction

Throughout this book, you've seen time after time where bugs were easily found via fuzzing. In many cases, these bugs could have easily been found by software vendors prior to releasing their software with a little bit of due diligence. This chapter is written from the perspective of how vendors would go about integrating fuzzing into their software development lifecycle.

First, fuzzing needs to be a subset of an overall security plan. Two of the more prominent software security development processes are "The Security Development Lifecycle" from Microsoft (www.microsoft.com/mspress/books/8753.aspx), and "Comprehensive, Lightweight Application Security Process," or CLASP (www.owasp.org/index.php/Category:OWASP_CLASP_Project), sponsored by the Open Web Application Security Project (OWASP). Using either of these processes will help in getting your security effort off on the right foot. Fuzzing simply fits into these broader plans as a component of more robust security testing.

The popularity of fuzzing among security researchers, large corporate customers, and those with malicious intent is growing rapidly. Not performing fuzz testing on your software will leave you open to others finding these software flaws for you. Anyone who has had to respond to externally found and publicly known security vulnerability knows this is not a good thing. The Month of Browser Bugs (MoBB http://browserfun.blogspot.com/) was eye opening to many as to the number of flaws that could be found via fuzzing. Those familiar with the complexity of the parsers involved with Internet browsers should not be too surprised that these types of bugs exist.

Some software vendors are already...