Writing code is hard. Writing secure code is harder—much harder. And before you get there, you need to think about design and architecture. When you're writing code to implement security functionality, it's often based on architectures and designs that have been pored over and examined in detail. They may even reflect standards that have gone through worldwide review processes and are generally considered perfect and unbreakable.*
However good those designs and architectures are, though, there's something about putting things into actual software that's, well, special. With the exception of software proven to be mathematically correct,** being able to write software that accurately implements the functionality you're trying to realize is somewhere between a science and an art. This is no surprise to anyone who's actually written any software, tried to debug software, or divine software's correctness by stepping through it; however, it's not the key point of this article.
Nobody*** actually believes that the software that comes out of this process is going to be perfect, but everybody agrees that software should be made as close to perfect and bug-free as possible. This is why code review is a core principle of software development. And luckily—in my view, at least—much of the code that we use in our day-to-day lives is open source, which means that anybody can look at it, and it's available for tens or hundreds of thousands of eyes to review.
And herein lies the problem: There is a view that because open source software is subject to review by many eyes, all the bugs will be ironed out of it. This is a myth. A dangerous myth. The problems with this view are at least twofold. The first is the "if you build it, they will come" fallacy. I remember when there was a list of all the websites in the world, and if you added your website to that list, people would visit it.**** In the same way, the number of open source projects was (maybe) once so small that there was a good chance that people might look at and review your code. Those days are past—long past. Second, for many areas of security functionality—crypto primitives implementation is a good example—the number of suitably qualified eyes is low.
Don't think that I am in any way suggesting that the problem is any less in proprietary code: quite the opposite. Not only are the designs and architectures in proprietary software often hidden from review, but you have fewer eyes available to look at the code, and the dangers of hierarchical pressure and groupthink are dramatically increased. "Proprietary code is more secure" is less myth, more fake news. I completely understand why companies like to keep their security software secret, and I'm afraid that the "it's to protect our intellectual property" line is too often a platitude they tell themselves when really, it's just unsafe to release it. So for me, it's open source all the way when we're looking at security software.
So, what can we do? Well, companies and other organizations that care about security functionality can—and have, I believe a responsibility to—expend resources on checking and reviewing the code that implements that functionality. Alongside that, the open source community, can—and is—finding ways to support critical projects and improve the amount of review that goes into that code.***** And we should encourage academic organizations to train students in the black art of security software writing and review, not to mention highlighting the importance of open source software.
We can do better—and we are doing better. Because what we need to realize is that the reason the "many eyes hypothesis" is a myth is not that many eyes won't improve code—they will—but that we don't have enough expert eyes looking. Yet.
* Yeah, really: "perfect and unbreakable." Let's just pretend that's true for the purposes of this discussion.
** …and that still relies on the design and architecture to actually do what you want—or think you want—of course, so good luck.
*** Nobody who's actually written more than about five lines of code (or more than six characters of Perl).
**** I added one. They came. It was like some sort of magic.
***** See, for instance, the Linux Foundation's Core Infrastructure Initiative.
This article originally appeared on Alice, Eve, and Bob – a security blog and is republished with permission.
Comments are closed.