Industry experts acknowledge that while the perception exists that open source software is less secure than its proprietary counterparts, it’s only a myth that one is less robust than the other.
There is a degree of apprehension at first, said Jeff Williams, CEO of Columbia, Md.-based application security services provider Aspect Security, and volunteer chair of Open Web Application Security Project (OWASP), a free application security community. “But if you get a closed source application from some small fly-by-night company, how is that different from getting some open source application from some fly-by-night developers?”
Howard Schmidt, former White House cyber security advisor, agreed the perception exists that open source is more vulnerable to hackers who may insert malicious code. “All of a sudden, you have a new file with modifications to it and some people say, ‘I don’t know what’s in there, I’m concerned about it.’”
On the other hand, there is a certain level of trust surrounding proprietary software, in that people are more confident that it won’t harbour malignant code, he said. “It’s almost as difficult to deal with as which political party is right. The bottom line is that perceptions don’t match reality,” said Schmidt. “There’s tremendous debate.”
Due diligence
The issue of security whittles down to due diligence at the development stage, rather than with issues in the code itself, said Williams. “It shouldn’t be a requirement of security that the source code be secret. That’s really just security by obscurity.”
He said both camps run the gamut from poorly-organized to well-run development teams.
Software stemming from open or closed source is subject to the same level of scrutiny. However, the motive is different, said Ronald O’Brien, senior security analyst with Burlington, Mass.-based security software provider Sophos.
“By having it open to as many users as possible, you get the benefit of the community looking at it,” he said, adding that Microsoft Corp., for instance, gets scrutinized as well, but by those seeking to prove its vulnerability.
Despite having a community that bands together to ensure open source remains stable, Schmidt said, seeking vulnerabilities requires a particular skill that a group of many eyes may not necessarily possess. “Just by virtue of the fact that there are literally thousands and thousands of people looking over the code on open source doesn’t mean that they have the capability of identifying vulnerabilities.”
But there do exist established processes solely for the purpose of allowing the public to find flaws in software, be it open or closed source, said O’Brien.
Not just freeware
Furthermore, he said although big proprietary software vendors like Microsoft invest more heavily in development, open source isn’t exactly the freeware it’s often made out to be, he said. “There’s still a company responsible for marketing and selling so it’s somewhat a misconception that the open source software is free because there are costs associated with acquiring and managing open source applications.”
If a company does have issues with open source applications, these concerns won’t take root in security, but rather with support and the open source licensing model, said David Senf, director of Canadian security and software research with Toronto, Ont.-based analyst firm IDC Canada.
However, Senf noted support issues have dramatically waned over the last two years with the emergence of industry heavyweights Novell, Sun Microsystems and IBM into the field.
Internal affairs
According to O’Brien, the security risks heighten when applications — regardless of the code — are developed internally for internal purposes. With internally-developed software, the issue of security very often stems from developers who don’t possess the skills to properly code software, than it does from open source itself, said Senf.
He said there is ample literature out there that can provide in-house developers with techniques for building secure code, including threat modeling to assess, in advance of coding, the potential threats that could affect users of the software. “It’s knowing first what are things that can compromise a piece of software.”
Threat modeling is especially vital if the software is intended, for instance, to tap into databases housing customer information, he said. “Do I want to expose that to potential data leakage? Well, probably not.”
The industry should look to new tools that can scan, analyze and reduce vulnerabilities while code is being written, regardless of open source or commercial, agreed Schmidt. “That’s where we need to be moving and not saying one’s better than the other because they both have their own number of flaws in it.”