Designing Secure Software Blog

I was surprised to see that my book, “Designing Secure Software: A Guide for Developers”, made it to BookAuthority’s Best Software Security Books of All Time … especially since the first copies are still being printed and not yet shipping! (The e-book is available from the publisher at nostarch.com so it is getting out there in that form.) https://bookauthority.org/books/best-software-security-books?t=2u40nr&s=award&book=1718501927

One big learning for me from writing a book on software security is realizing the importance of context to security. There was a constant challenge of discovering the right scope — what needs adding, and what can be cut to keep it concise. Each chapter of the book could well have been an entire book itself, but nobody is going to read what would consume a foot of shelf space. Software security can go wrong in so many ways that there is always more to say, different approaches to take, various pros and cons of different mitigations, further interesting details to consider. And of course new vulnerabilities keep popping up, offering more examples to learn from, and suggesting various new mitigation techniques that might have prevented the problem.

Each time a high-profile software security bug is reported, I wonder how this happened yet again. I don’t expect vulnerabilities to approach zero any time soon, but still I’d like to know how this keeps happening over and over, so we can do better. For example, was a developer unaware of the implications of their code change that broke security, or did they know but were just sloppy? How do these bugs get past a code reviewer, or was that considered unnecessary and skipped? Why weren’t there test cases to prevent such problems? And once we get a fix, how was it tested, and did anyone check for similar vulnerabilities that might exist elsewhere in the code? We can’t make much progress if we don’t know why well-known countermeasures aren’t working.

I believe that we can do so much better at delivering more secure software, and my book explains how we could do that. While there are a few new ideas in there, it’s mainly about covering well established methodology with focus on showing how to put it into practice. The book takes a different approach to the topic of software security to reach as broad an audience of software professionals as possible because I think there is often an over-reliance on “experts”.

I’m proud to announce my new software security book, Designing Secure Software: A Guide for Developers. I wanted to create something a little different: broadly readable rather than expert targeted, general approaches over specific details, all based on direct personal experience.

Awaiting the release of any book requires patience, but this year amidst numerous supply chain challenges it’s particularly uncertain.

The original October target date is almost here, but I can report that the publisher hopes to have copies of the print edition for sale in early November – about a month ahead of general release now set for December 2021.

In the book Project Hail Mary by Andy Weir, there is a short scene (on page 339) that features a very clear example of failure to implement Complete Mediation (one of the secure design patterns described in Chapter 4 of my book).