Security

Spilled coffee beans, breaking the sound barrier, and software security

The Right Stuff is Tom Wolfe’s popular history of the US astronaut program, and it begins by recounting the early effort to break the sound barrier which involved such frequent crashes that there were weekly funerals for test pilots. What’s most striking about the account of this early period in what would become the space program is how the pilots gathering to bury their comrades would invariably talk themselves into believing that they would never have crashed — it was always the other guy who messed up and sadly paid the price.

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”.

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).