September 15, 2005

Book Review - 19 Deadly Sins of Software Security

Back in July I posted that I couldn't wait to get my hands on a copy of "The 19 Deadly Sins of Software Security". The authors (Michael Howard, David LeBlanc and John Viega) have contributed to some of my favorite writings, and I just knew it had to be a good book.

It might be because I have read so many of their other books, that I didn't find this book as appealing to me. That's right, I didn't really enjoy this one. I am guessing its because I was spoiled by already reading Writing Secure Code, Secure Programming Cookbook, Building Secure Software etc. that I just didn't feel I got as much out of the book as I wanted.

More importantly, I think the guys missed a great opportunity. The format was excellent:

  • Overview of each Sin
  • Show which languages are effected
  • Explain the Sin
  • Show the Sin in various langauges
  • Show how to spot the Sin pattern during code review
  • Show testing techniques to find the Sin (when possible)
  • Show real world examples of the Sin
  • Show redemption steps

But while the format was great and to the point (which made for a more streamlined read) it was the last step that I was expecting more out of. Especially since "...and How to Fix Them" was in the title. This was the best place to REALLY show how to fix sinful code. As an example, in the Integer Overflow Sin they go into detail to show how a senior developer with lots of experience had a function checking for an overflow that was flawed. Near the end of the page they even show how to fix it. What they could have done was bring it full circle and rewrite the function showing the right way to do it, and then providing the "correct code" in the various languages. I was expecting that throughout the book, to no avail.

This is what I think is missing in all these books. I want a SHORT book I can give to a new developer joining the team so they can see how to write safe code correctly, even to the point they can almost cut-and-paste some of these techniques into their own code.

For a new developer coming in to secure software programming, I am not sure that this is the right book for them. It misses the background to explain WHY its such a problem. Writing Secure Code and Building Secure Systems were two books I rather enjoyed because of all the back story about it. And that made for a more enjoyable technical read of those books. However,I just felt this book was too dry as they tried to balance depth with bredth in 270 pages.

With that said, I think this would be a PERFECT book for a developer who wants a quick and dirty understanding of the Sins and how to fix them without really understanding WHY, and how deep the risks can go. More importantly, I think this is a good intro for code auditors and whitebox testers who don't have to have as much coding experience to know what to look for (at least in a first pass)

I am assuming that if I hadn't read the other books that I might have more enjoyed this one. It is jammed full of good technical information, but just didn't "turn my crank" so to speak compared to their other works. If you have read the other books, I am not sure how much more you would gain from this one.

What WOULD be interesting is if someone new to this read this book first and THEN read the other ones. I would bet it would be an eye opening experience as you dug deeper into "Alice's hole"... so to speak.

Posted by SilverStr at September 15, 2005 02:21 PM | TrackBack
Comments

I haven't read the Deadly Sins book yet, but according to your review, I won't read it at all - I don't think it's worth to get a book on blind fixing of typical software bugs.

While I enjoyed Writing Secure Code for the same reason as you did, I still think that a major chapter is missing, which would explain the security APIs and the whole subsystem in details. It is a book for programmers, who want to learn more about security, so this chapter would have been crucial.

Posted by: pb at September 16, 2005 12:49 AM