What do you think?
Rate this book
24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them
"What makes this book so important is that it reflects the experiences of two of the industry's most experienced hands at getting real-world engineers to understand just what they're being asked for when they're asked to write secure code. The book
432 pages, ebook
First published January 1, 2009
19 people are currently reading
181 people want to read
About the author
Michael Howard
17 books8 followersLibrarian Note: There is more than one author by this name in the Goodreads database.
software security expert from Microsoft
software security expert from Microsoft
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 4 of 4 reviews
March 21, 2012
A poor overview of practical security problems. Unclear and garbled explanations of how to prevent problems, along with pages and pages of useless code that does not server to illustrate the problem or show how to defend against it. Verbose, formulaic and annoying. Look for another book if you want something on practical application security.
October 17, 2018
Textbook for part of my Cybersecurity masters program, and it offered smart and thorough coverage.
Humorous interjections and examples in many different languages make this a joy to read.
Unfortunately things change a lot, and the 2010 addition doesn’t seem to have an update.
Also, it’s amazing that anything on the Internet works at all.
Humorous interjections and examples in many different languages make this a joy to read.
Unfortunately things change a lot, and the 2010 addition doesn’t seem to have an update.
Also, it’s amazing that anything on the Internet works at all.
May 24, 2016
If you know almost nothing about software security, need a quick, broad introduction, and have this book laying around, it won't be a complete waste of your time. Otherwise I'm guessing you'll do better elsewhere.
My notes:
The Foreword states it is rare that software can kill people. I'm not sure how the authors could be unaware or dismiss how our society relies on ubiquitous computing systems to keep us safe. A quick reflection on the embedded code running numerous vehicles, medical devices, and industrial machinery shows the danger incorrectly implemented system pose.
There seems to be a bias for Microsoft technologies throughout.
Java is knocked for lacking an unsigned int primitive. In cases where this could matter isn't it a trade off between simpler code or a simpler language? Either way it is nice to know you can't mix signed and unsigned with Java avoiding a whole host of squirrely problems.
Shorter and simpler seem to be conflate, several examples and explanations express a preference for more cryptic code over easier to understand but longer code.
I found the Chroot Jail section confusing, granted my personal state diagram has many transitions to this node.
A non-proofreading read found several typos in a book focused on details.
A filename string length check example required 3 or more characters but no rationale.
MS IIS not following line termination standard is claimed to not be wrong where following standards is a fairly consistent message otherwise.
Permission control in Java not mentioned in relevant sections.
Redemption example code for protecting stored data did not follow safe use of strlen as described in an earlier chapter.
14 pages into weak passwords before salt is mentioned and no explanation is given though the rest of the book seems to assume a fairly innocent reader.
Was anyone still using Palm Pilots in 2010? It seems to make a poor example.
Lots of recommendations on what not to log but very little on what is useful to log. To be fair it isn't easy to strike a good balance between hiding internal state and structure from malevolent actors and providing useful information to developers.
I am not a software security expert and apologize for any misstatements. Feel free to correct me with my thanks.
My notes:
The Foreword states it is rare that software can kill people. I'm not sure how the authors could be unaware or dismiss how our society relies on ubiquitous computing systems to keep us safe. A quick reflection on the embedded code running numerous vehicles, medical devices, and industrial machinery shows the danger incorrectly implemented system pose.
There seems to be a bias for Microsoft technologies throughout.
Java is knocked for lacking an unsigned int primitive. In cases where this could matter isn't it a trade off between simpler code or a simpler language? Either way it is nice to know you can't mix signed and unsigned with Java avoiding a whole host of squirrely problems.
Shorter and simpler seem to be conflate, several examples and explanations express a preference for more cryptic code over easier to understand but longer code.
I found the Chroot Jail section confusing, granted my personal state diagram has many transitions to this node.
A non-proofreading read found several typos in a book focused on details.
A filename string length check example required 3 or more characters but no rationale.
MS IIS not following line termination standard is claimed to not be wrong where following standards is a fairly consistent message otherwise.
Permission control in Java not mentioned in relevant sections.
Redemption example code for protecting stored data did not follow safe use of strlen as described in an earlier chapter.
14 pages into weak passwords before salt is mentioned and no explanation is given though the rest of the book seems to assume a fairly innocent reader.
Was anyone still using Palm Pilots in 2010? It seems to make a poor example.
Lots of recommendations on what not to log but very little on what is useful to log. To be fair it isn't easy to strike a good balance between hiding internal state and structure from malevolent actors and providing useful information to developers.
I am not a software security expert and apologize for any misstatements. Feel free to correct me with my thanks.
June 1, 2016
A must have for all developers. There are some special topics that is related to only C/C++ but the rest is really important to consider.
Displaying 1 - 4 of 4 reviews