This new book is another meaningful contribution to the problem of developing secure software. As with his other books, McGraw's expertise shows through clearly. This book is considered a unification, or maybe an intersection, of his other two books, one for black hats and one for white hats.

I think of black hats more as being similar to quality assurance engineers and whistle blowers. I still can not figure out why problems with automobiles are public, government regulated and attractive to lawyers, yet the software industry still gets to demonize anyone who points out flaws. This is not to say that I believe using flaws to attack a site is a good idea, and I do not support criminals who use such knowledge to commit crimes.

No business or discipline can make progress without some attention paid to truth. In this case we are looking at the academic discipline of software engineering and the business of producing software. Our world is extremely dependent on software, from embedded systems to enterprise systems. You can count on it being more so for a very long time. McGraw is bearing down on the business end in this book without sacrificing the technical side. It is not easy to make changes which affect the underlying structure of something, even if it is necessary.

I am always distressed to hear someone, manager or otherwise, say that a perceived problem does not matter unless it has an impact on a schedule or some cost number. If a problem in design or construction of something exists, then the only issue is the size of the problem. I can imagine a a bridge construction site when an engineer realizes that inferior cement has been used. In the conversation with the manager, the replacement time and cost comes up, leading the manager to dismiss the problem because the schedule wins over all else.

McGraw spends a goodly number of pages on topics like risk management, as he should. He does point out that in the business world, you need to not only say "There is a security problem in this software," but also add in "There will be a cost associated with it later if it is not fixed now." This is a helpful suggestion when communicating with non-technical bosses.

This book would be good to give a boss up the food chain where software and security expertise go below 20% because there is enough in for such managers to be very useful. It is also a good book for those still designing, writing or reviewing software since there is enough helpful technical material to be meaningful. If you are one those software folk, you could learn more about how to talk to that 20% boss in a way that will be good for both of you.

The problem today is still about writing good, secure software. If you are in doubt about just how much of it bad, check out vulnwatch, neohapsis and the rest, or just read CNN regularly. McGraw and others have done a good job of backfilling the literature with philosophy, methodology, techniques and so on, but there has not been enough traction in the cubicle to put it all into practice. Until the software folks put security into the design, we well continue to enjoy those "zero days" and the ensuing deluge of reports. On the other hand, if management does not support and fund security as a priority in software development, then the cube dwellers have a serious obstacle.

This is highly recommended book for anyone involved or interested in secure software development, but anyone who cares about security should pay attention to this fundamental problem because it contributes to all the rest of the security problems we face. I look forward to new work from McGraw and the rest.