In April, the Heartbleed vulnerability was found in the popular OpenSSL software used for encryption. A few weeks later, the Cover Redirect vulnerability was discovered in OAuth 2.0 and OpenID. What do these vulnerabilities have in common? They were found in open-source software.
Open-source software and applications are popular with small and midsize businesses (SMBs), in part because they're free, which can save a small business on a tight budget thousands of dollars in software costs and licensing fees.
Traditionally, open-source software and applications have been known to be secure — more secure than many similar proprietary or closed-source applications and software offerings. The reason for that is simple: Open source is open.
"Anyone can view the source code of the application and potentially spot errors or malicious intent," said Jean Taggart, a security researcher for Malwarebytes. "Open-source projects, if they are active and well maintained, will receive patches and updates at a faster rate than closed-source proprietary software, where the end users are dependent on the time frame, diligence and willingness of the software vendor."
"As the source code is available to anyone, security researchers often investigate newly discovered exploits and vulnerabilities — sometimes, independent code reviews are performed," Taggart added. "Once the bugs are discovered, patches are issued that address these vulnerabilities.”
However, the recent and much-publicized vulnerabilities in open-source software have a number of users questioning whether open source is as secure as it's purported to be. Are these security researchers doing due diligence in looking for security flaws and fixing them? Is open source really worth the cost if a vulnerability like Heartbleed could result in breached data, a ruined reputation and the potential loss of business?
Before making judgments about open source, Steve Pate, chief architect at HyTrust, pointed out that most commercial software products contain open source as well as proprietary source. "For truly open-source products, such as Red Hat Linux, you have a commercial enterprise backing the software that they deliver. They are just as stringent about releasing secure, quality products as any commercial vendor," he said.
You are most likely to find problems when open-source applications are downloaded from a vendor you don't know and trust. "Don't tell your IT staff, developers and other personnel that they can't use open-source software," Pate said. "Tell them they can, as long as it's one of a set of approved applications."
IT staff at small businesses should take an active role in vetting open-source software, said Andy Chou, chief technology officer and co-founder of Coverity, which offers a scan service that provides free code analysis for open-source developers. "Many vulnerabilities and defects can be found in open-source code using static analysis," Chou said. Following this analysis, open-source users can discover information about the software, such as number of defects fixed, outstanding defects and defect density rate, he added.
For those who are already using open-source software of some kind, the best course of action is to keep their software up to date, Chou said. "Regularly review the versions of software being used, and allocate time to update it," he advised. "Failure to update promptly is a major cause of having vulnerable software in deployment at small businesses.”
Another key: Use a password manager to ensure unique passwords are used for each service. "In the case of Heartbleed, there was little SMBs could do before the vulnerability was revealed, but afterwards, updating software and changing passwords would be made much easier with these tools and practices in place,” Chou added.
Coding and using open source require trust, and that trust is relied on to make sure that open-source software is secure. There is also accountability involved, and that's one of the main reasons why the risks with open source appear to be lower than with closed-source software. Are there bad guys who will purposely code something malicious into the software? Perhaps, but it isn't easy, Taggart said. The transparency that the open-source model provides allows each code commit to be attributed to a specific developer — that way, each code change can be traced back to the person who performed it, Taggart added.
"As a developer, if you go in with malicious intent, you have to make it look like a mistake," he said. "The vulnerability you introduce has to be very subtle to slip by unnoticed. While there is always the possibility that it will happen, the chance that it will be noticed is far greater than [with] a closed-source application, where the source code isn't available for review."
The recent vulnerabilities in open-source applications have users questioning security, and that's not a bad thing, Taggart said.
"The Heartbleed bug has spurred efforts to perform code reviews of other widely used open-source [applications], and that is a good thing," he said.
Administrators should also avoid the "If it's not broken, don't fix it" mentality and instead keep up with patches and updates, he added. "While open source has many benefits — such as cost, rapid patch deployment and transparency — there is still a need to monitor updates to the open source you deploy and use," Taggart said.
Originally published on Business News Daily.