I mentioned a couple of weeks ago Brian Chess and Jacob West's (of Fortify Software) new book Secure Programming with Static Analysis (Addison-Wesley Software Security Series). When I got home the day I mentioned it, I was giddy with excitement because I had just received my copy. I'm kinda' new to book reviews, so please bear with me.
The best and worst thing about this book is its scope. It's great because it covers static analysis from soup to nuts, including why an environment should adopt a static analysis program, how static analysis works, the types of flaws that static analysis finds, how to correct flaws found by static analysis, and how to implement static analysis in your environment. However, that's also the major shortcoming with it. Because it's so broad, it gets very technical in some points, and if you hand the book to an executive type hoping they read chapters 1, 2 and 3, you'd better hope they don't thumb to chapter 4 by accident or else they'll quickly dismiss the book. Note to publisher - make chapters 1, 2, and 3 a removable pamphlet.
Jacob and Brian were fortunate enough to have the foreward written by Gary McGraw, whom I have a great deal of respect for. However, his very first illustration is correct only up to a point:
By contrast, on the first day of software engineering class, budding developers are taught that they can build anything that they can dream of. They usually start with "hello world."The point of the paragraph (that engineering classes start with keeping people alive in mind, while development begins with features in mind) is spot-on and well taken. However, there's a very large segment of people writing code today who did not study software engineering, but started as hobbyists who learned HTML, then decided to pick up a PHP book - chock-full of really bad examples.
Part One of the book is an overview of static analysis - why you should do it, the different types of static analysis, and some really in-depth coverage of how static analyzers work - obviously they're experts on the matter, and the coverage is very good, but will be mind-numbing to those who don't actually study software. They make very compelling arguments for not only including static analysis as part of your development lifecycle, but also including it early in the lifecycle, and making sure that developers are performing the analysis as well.
Part Two covers some of the problems commonly uncovered by static analyzers. They have many examples of bad code, but thankfully, almost as many examples of specifically how to correct it (after all, I'm about solutions, not problems). They discuss input validation, buffer/integer overflow, and errors and exceptions. Brian and Jacob have some very good examples from open source software, and the fixes that were put into place, as well as some really good recommendations for additional libraries to use that will help alleviate some of the common mistakes that lead to buffer overflows.
Part Three covers environments or types of applications that are currently being written and some of the specific types of flaws that come up in those applications. They cover web applications, XML/web services, privacy, and privileged programs. The book does a really good job of covering the Struts Validator, but I see this section as needing a bit of work - while Struts is still probably the most widely used MVC architecture, the Commons Validator can be used in webapps that are not Struts, but there's no mention that you can actually use the validator outside of a Struts application, although using it within Struts makes it much simpler.
Part Four is Static Analysis in action. There are exercises to walk you through installing Fortify SCA (there's a demo edition included), performing the analysis scan, analyzing the results, and even writing your own rules. I've not walked through the examples, but anybody wishing to see what is involved will actually want to step through these processes.
I know that Brian and Jacob spent a great deal of time on the book. They bring a wealth of knowledge to something that just doesn't get covered much in books, yet it's a critical part of any mature security or development program. Static analysis does not cover every vulnerability possible, but the ones it does catch it catches earlier, and with greater depth, than other methods.
I certainly don't agree with Brian and Jacob on every one of their philosophies. I've had the pleasure of debating with them on some of those philosophies, and I'm convinced I'm still right. Fortunately, those issues don't come through in the book, and as a general reference for executives who need to be convinced of the need of static analysis in the lifecycle, to security practitioners who need to know how to write rules for their system (of course, there's a bent to Fortify SCA), to developers down in the trenches who need to understand what their tool is telling them, this book excels.
Additionally, of the technical books that I've read in first edition, this one is probably one of the best. I've seen very few grammatical flaws or even awkward sentences, and only a handful of code flaws. The writing, you can thank the editors for. The code example excellence, you can thank Brian and Jacob for - and yes, they still write code.