I agree with a previous reviewer that the title is misleading - it should emphasize that this is primarily a book about not writing non-secure code on a Windows platform.

There are many good tips in the book (which is why it didn't get one star), but for those of us who write code for other platforms (there are other platforms, BTW) it's not nearly as useful.

The final example of non-usefulness are the sample code files. To get them you must download a Windows executable which requires that you click on a button accepting a license agreement; the download will then begin. If you don't happen to be running on a Windows box, no download, no code examples, no nothing. Makes the book way less useful and much more annoying to me.

This is a good book as it does a good job covering the different sources of software insecurities:

- The classical buffer overflows on the stack and on the heap
- Canonical issues on input
- The least privilege principle
- There is a brief overview on how store a secret

On the last point, the authors know well the topic. If you are using cryptography to protect something in your software but just store the private key in a global variable then you are helping tremendously the job of hackers as all they will have to do is look into your executable binary to search for something that looks like a key. A security measure is as strong as its weakest element and no hacker is foolish enough to attack a cryptographic algorithm that is proven strong. Even if you store the key in a secure place, all that is needed to retrieve the key is to perform a memory dump at the right time just before the software use the key. At least, you can make hackers job harder as there is nothing you can do to make your software 100% safe against hacker if the software is valuable enough to motivate them to hack your software. All you can do by improving your software security is to buy you some time before your software is hacked. All that to say that there is not bullet proof solution against hackers but the book gives solid leads to improve software security in that aspect.

In this book, there is a strong emphasis on Microsoft security technologies. The Windows Crypto API and the Microsoft OSes privileges API are described in length. If you develop on Windows and want to make your software more secure then this is an excellent book for you. If you develop on another platform, there is still something for you in this book as there are a lot of code snippets that are platform independent to improve software security such as input validation for file names to protect yourself against canonization bugs.

This is a very good book about software security but I do not recommend it simply because there is a new edition of itWriting Secure Code, Second Edition.

This book concentrates on a very important subject - writing secure code for Windows. In particular it focuses on two aspects: (a) correct coding techniques and how to avoid security pitfalls, and (b) the particular Windows security API and its usage.
For the above reason I will rate this book with 2.5 stars.
Why not 5 stars?
I found the text well padded with the author opinions, stories, and samples, which in many cases I felt where unneeded for me.
I also found it very exhausting trying to fish-out from all the text, the knowledge that I felt I needed.
Some of the motives kept on coming up. I will try to summon here few, using my words:
1. This book is extremely important thus you must read it.
2. This book is extremely important thus you must read it.
3. Some developers don't understand anything about security.
4. You cannot believe how ignorant or lazy developers can be.
5. Most developers will give wrong answer for my next question.
And so on...
Many of the examples in the book show 'what NOT to do' and common mistakes rather then what to do.
I must admit that somewhere around the middle of the book I started to read it in a selective way, trying to avoid redundant text.

Okay overview. Not many details good for beginning programmers who are learning how to code right. Not really for understanding windows security or architecture, but then that is not the intention of the book.

I read six books on software security recently, namely "Writing Secure Code, 2nd Ed" by Michael Howard and David LeBlanc; "19 Deadly Sins of Software Security" by Michael Howard, David LeBlanc, and John Viega; "Software Security" by Gary McGraw; "The Security Development Lifecycle" by Michael Howard and Steve Lipner; "High-Assurance Design" by Cliff Berg; and "Security Patterns" by Markus Schumacher, et al. Each book takes a different approach to the software security problem, although the first two focus on coding bugs and flaws; the second two examine development processes; and the last two discuss practices or patterns for improved design and implementation. My favorite of the six is Gary McGraw's, thanks to his clear thinking and logical analysis. The other five are still noteworthy books. All six will contribute to the
production of more security software.

If "Building Secure Software" by Gary McGraw and John Viega was the Unix world's resource for secure coding, WSC2E is the Microsoft equivalent. Even as a Unix-deploying professional (who performs incident response on Windows compromises), I found plenty of OS-agnostic material to justify reading WSC2E. I especially like when the authors provide examples of what coders do wrong, followed by examples of what to do right. Remarkably for a book published in late 2002, WSC2E even explains cross-site scripting attacks afflicting major news organizations as recently as a few months ago! The rules for writing firewall-friendly applications in ch 15 were very welcome, and seldom seen elsewhere. The flaw-avoidance recommendations for technologies like RPC, SQL, and COM Internet Services were well-written.

The major problem with WSC2E, often shared by Microsoft titles, is the misuse of terms like "threat" and "risk." Unfortunately, the implied meanings of these terms varies depending on Microsoft's context, which is evidence the authors are using the words improperly. It also makes it difficult for me to provide simple substitution rules. Sometimes Microsoft uses "threat" when they really mean "vulnerability." For example, p 94 says "I always assume that a threat will be taken advantage of." Attackers don't take advantage of threats; they ARE threats. Attackers take advantage of vulnerabilities.

Sometimes Microsoft uses terms properly, like the discussion of denial of service as an "attack" in ch 17. Unfortunately, Microsoft's mislabeled STRIDE model supposedly outlines "threats" like "Denial of service." Argh -- STRIDE is just an inverted CIA AAA model, where STRIDE elements are attacks, not "threats." Microsoft also sometimes says "threat" when they mean "risk." The two are not synonyms. Consider this from p 87: "the only viable software solution is to reduce the overall threat probability or risk to an acceptable level, and that is the ultimate goal of 'threat analysis.'" Here we see confusing threat and risk, and calling what is really risk analysis a "threat analysis." Finally, whenever you read "threat trees," think "attack trees" -- and remember Bruce Schneier worked hard on these but is apparently ignored by Microsoft.

Overall, I thought WSC2E was very thorough and comprehensive, yet accessible and authoritative. The excuses in appendix B were priceless and almost enough to justify reading the whole book, along with the security principles in ch 3. I'm also remembering the great quote on p 55: "history is a vast early warning system." Just ignore the terminology in chapter 4 and elsewhere, and hope Microsoft uses Gary McGraw's "Software Security" to correct the vocabulary problems appearing in its developers.