Since last night I finally finished reading Secure Programming with Static Analysis by Brian Chess and Jacob West, I thought it would have been a good idea to write some words about the book itself.
The reading is not bad at all, although I guess it’s oriented more toward people who don’t have much real-world experience of handling security in software; while I’m definitely not a security expert myself, I’ve been interacting with them on a stable basis for years now, and most of what Chess and West wrote was already well-known for me.
As for the details the book gets into, on the whole, it seemed to me much more oriented toward Java-based Web Applications rather than actual code; I guess this might be because, on the whole, where Security is paid more attention to is in “enterprisey” situations which seem to be where JSP is used most nowadays. There is no lack of C/C++ examples in the book, and I guess for Free Software developers who (hopefully for them) have no contact with Microsoft environment, the description of Microsoft’s “safe” variants of classical C functions might be interesting, at least as a way to understand their design, and eventually take the same considerations into account when developing Free Software for Linux.
The one thing that I think the book is seriously lacking for what concerns modern security risks is Ruby: with all the software that is currently being developed “agile”, I’d be expecting more coverage about that, as I’d expect it would have a non-trivial influence with the security landscape in the future (and this is not saying that it hasn’t shown its security problems already). I guess that having Rails as the main, central interface to all the web applications is both a good and bad thing: bad because every vulnerability in Rails is a possible vulnerability for a long list of applications, good because it centralises enough of the tasks to avoid re-implementation mistakes.
I sincerely hoped it went to show more in details how to implement static analysis in practice, but given the authors work for a company selling a static analysis tool they only show how it works in the last two chapters of the book (once for Java and once for C/C++). It includes a CD with a demonstration version of the Fortify SCA software itself.
That I could see, there are no factual mistakes in the book but one (assigning W^X implementation to FreeBSD rather than OpenBSD, oops!), and the reading is quite nice, some of the examples are also not that obvious so it’s still mind-clearing for those who have a bit of security background already.
Unfortunately, there is one thing from the book that I didn’t like too much, and is the “security over everything else” approach they suggest to take many times during the course of the book. While I can see – and agree to some extent to – its importance, it is also true that the success of modern software is always accompanied to some kind of moderation. When they tell you not to give the user any information about a failure to avoid an attacker from understanding which tripwires they touched, they are reducing user-friendliness; when they suggest to ignore robustness in favour of security, they are reducing solidity. And it’s not the over-secure UNIX systems that got the top desktop market share, but rather the objectively insecure and unsafe Windows — and you can see how the tightening of the security on the desktop, through Vista and “7” (even though debatable) is causing headaches to developers, system administrators, and users alike.
What it really does teach is some very convincing arguments to prod the management with, to get your security budget and time allocated properly, though. And it’s not really debatable that it’s something our category always need to learn from.
For the next read, I’m going to check out the opposite approach to static analysis: Fuzzing — knowing both areas is probably the best choice.