Disclaimer This is still a draft, and I’m planning to revise and edit it, such as changing some of the first person phrasing in places. (Or I might not and just remove this disclaimer) It depends When a security researcher or engineer discovers a new vulnerability, what should they do about it? Should we prove exploitability, go part of the way there, or just fix the bug? As with so many things, the answer is “it depends”.

There are many things that go into good security engineering work. One of these is gaining a deep understanding of how things work. In other words, “asking why”, rather than taking an answer and accepting it. Before you read this, watch this 7.5 minute clip of an interview with Richard Feynman. My natural tendency, and I suspect this is true of many others working in security, is to want to delve deeply into understanding how things work.

Contextual bloat Background Bert Hubert recently wrote an excellent piece on software bloat and related this to downstream effects on security. Why Bloat Is Still Software’s Biggest Vulnerability - IEEE Spectrum I suggest reading that first, as well as Niklaus Wirth’s 1995 article “A Plea for Lean Software”. This post is mostly an attempt at delineating a strategy to improve the situation in the short term. One of the examples given in Hubert’s original post is a garage door opener that uses 50 million lines of code.