In the Software Security Horserace, How Does Open Source Fare?
Today my newsfeed brought me Microsoft’s announcement that they had launched a security bounty program for Windows 8.1 and IE 11. Hold your snickers you Microsoft bashers. Security bounties, I learned with a little research, are not uncommon. My cursory search revealed that vendor bounty programs have been around as a trend since 2004 when the Mozilla Foundation sought to engage bug detectives for its Firefox browser – and can even be traced back to Netscape (remember them?) in 1995.
But the effort to attract and engage paid security pros to help discover vulnerabilities in software made me again consider the distinctions between open source software and proprietary software. At the risk of over-simplifying a complex issue, permit me to keep this high level and somewhat general while still making my point.
Building secure software is tough. One need only note the current conflagration between the US & China regarding who is stealing what from whom online. No doubt if either or all could stop the invasions with tech solutions they would. But clearly they can’t. But they try. There are a number of conceptual approaches to developing secure software environments. Curiously they rhyme:
Security by Obscurity
As a rule, proprietary software with its inaccessible source code relies on being hidden and impenetrable to provide security. To be fair and clear, most good proprietary software is genuinely also secure by design. That is, security features are built into the product with the implicit assumption that there will be malicious efforts to exploit vulnerability. So, basically, design it secure then hide it.
Security by Transparency
At the other end of the spectrum is security embraced by open source software. By its very nature open source cannot be secure by being obscure – anyone has access to the code. It must be secure by design. This has the advantage that anyone can look at the code to examine how the security was developed. Think of it as having a lock that you know how it's built but you still can't pick it.
Mercenaries & Volunteers
What it comes down to is this. Even a firm like Microsoft, which boasts the world’s largest installed base of users, is compelled to pay bounties to people outside its company to help test its software for security holes as well as methods to fix those problems. This firm, one of the best technology companies, must reach beyond its employee base of almost 100,000 people to find people to help them fix their software.
In contrast, open source software platforms employ no army of engineers – and few pay bounties. Instead, the hive effect of the community of thousands of developers swarms around the software discovering and fixing security vulnerabilities as they occur. It is not command and control. There is no bug-fix department. Rather it is the health and practices of good technology hygiene and a lot of eyes on the issues.
For the Drupal open source project, the community is well organized to address security challenges with the Drupal Security Team. Composed of a set of respected community volunteers, and one of the first dedicated security teams in an open source CMS project, the Drupal Security Team works to resolve reported security issues for contributed code to review code for vulnerabilities, and to provide security expertise and assistance to contributors. It doesn't so much solve the issues as it does organize the community and provide a forum for security issues.
No system of security protection, detection and correction is perfect. But if open source and proprietary were two horses in the Security Derby, my money would be on open source.
What’s your perspective on open source vs proprietary security measures. Can proprietary software keep up with the power of a community? Want to read more - and a different perspective - on open source security? Start here.