What did you do before Diffblue?
I did a PhD in computer science at the University of Cambridge. While I joined the Systems Research Group under Steven Hand, of Xen fame, and pursued work improving I/O-bound processes’ performance, I found myself more interested in program-analysis based approaches than more “systems-y,” empirical methods, and so drifted in the direction of the department’s Programming Research Group under Alan Mycroft. My thesis was about LLPE, an LLVM-based tool that deeply specialised binary programs based on their I/O operations, such as making a version of a web server specialized to one particular configuration, or even to serve one particular page.
After completing my doctorate I craved something directly practically applicable, and spent a couple of years acting as all-purpose software wrangler to Cancer Research UK’s Manchester lab. This meant digging deep into performance problems with their software, bringing data-structure and algorithmic improvements to open source code often written by academics with much stronger biology than coding abilities.
My batteries recharged by some cold hard pragmatism, I joined Diffblue to combine the ambitious program analysis I studied at Cambridge with the immediacy and practicality that comes in a startup.
What’s your role at Diffblue?
I lead the security team, which tries to discover security issues (SQL injection vulnerabilities and the like) in customers’ code. We’re shooting for accuracy in a way not seen before in the field.
Part of leading a team means spending time helping to teach and develop team members, but I have time for coding myself, too. In practice that means making improvements to the open-source CBMC tool that underlies much of Diffblue’s technology—improving our program analysis to better understand which code paths in the user’s code may be vulnerable, and which of those are practically reachable.
What do you think makes Diffblue unique?
Diffblue has a great combination of deep, challenging research problems which really push the boundaries of the possible, but which are also deeply practical and directed at immediate use to save real developers valuable time, and to save companies and their users from the chaos and disruption that results when a critical vulnerability is found in the wild.