There was no avoiding the irony after it was recently discovered that a customised version of Google's open-source Chrome Web browser – designed for enhanced security, of all things – had introduced a major security flaw that sent security specialist firm Comodo scrambling for a fix.
The revelation – which spurred no less than Google to issue a stern warning for anyone trying to improve on Chrome's security – came just days before another serious flaw was found in Avast SafeZone, a separate browser also designed for security and based on the open-source Chromium platform upon which Chrome is based.
Open-source software has proved to be a boon to the security industry, allowing as it does for encryption, authentication, data-storage and other routines to be scrutinised much better than in closed proprietary systems. Yet as flaws in this code are discovered, their very existence serves as a reminder that the use of open-source code is not without its risks.
Overall exposure to those risks is increasing as open-source adoption continues to grow. The Future of Open Source Survey, run last year by open-source proponent Black Duck Software, found that 78 percent of respondents use open-source software, two-thirds build customer software using open-source components, and 55 percent see security as the most important reason to embrace open source.
Just 17 percent of those companies, however, said they actively monitor for open-source security vulnerabilities – which are discovered with some regularity. This lack of ongoing attention paves the way for vulnerabilities such as Heartbleed, a flaw in the widely-used OpenSSL open-source library that appeared almost overnight and sent vendors and customers into a worldwide panic as they reassessed the role of open-source software.
For most companies, that role has been one of convenience and accessibility, with strong open-source communities providing regularly updated software designed for open standards and extensibility in ways that commercial software so often has not been. Few companies care about actually viewing or doing anything with the source code behind increasingly user-friendly open-source tools – although this makes open source both a strength and a weakness, says Chris Rock, CEO of security specialist firm Kustodian.
Most companies “are looking for that end solution, don't care one bit about source code and wouldn't know what to do with source code if they saw it,” explains Rock, a banking-industry veteran who has run Kustodian for the past 10 years and last year – on the back of a hugely successful global open-source security operations centre (SOC) rollout at BlueScope Steel that was based on Elasticsearch's open-source ELK stack – decided to shift the company's focus to developing and supporting open-source tools exclusively.
“Some security architects might look at the source code to ask why we're using, say, one port rather than another port,” he says. “Big banks or some smaller companies might need transparency – but the average client is just after an end solution; they're saying that they just want to install the software, put an agent on their box, and get their security alerts as an email.”
While many open-source platforms have made big strides in usability in recent years, many others still struggle with the perception – often well-deserved – that doing anything more than a basic install is prohibitively complex and opens the doors for introducing new problems that may interrupt the business.
This problem is represented in microcosm on the mobile handset front, with a recent study finding that devices running Google's open-source Android operating system are patched just 1.26 times per year, and that over 87 percent of Android devices are vulnerable to at least one of 11 known critical bugs.
Security-monitoring company Secunia, which was recently acquired by Flexera Software, has been tracking patch status amongst its multinational user base and, in its latest Secunia Vulnerability Review, reported that vendors had taken up to 100 days to notify the public about vulnerabilities even after patches were available for major OpenSSL issues.
Heartbleed “caught vendors by surprise as the majority first had to identify which of their products had been made vulnerable before they could begin to issue fixes,” the company's analysis noted. “Organizations should not presume to be able to predict which vendors are dependable and quick to react, when vulnerabilities are discovered in products bundled with open source libraries.”
Reponsiveness has improved over time, the analysis notes, with 83 percent of vulnerabilities patched on the day of disclosure – up from just 49 percent in 2009. Yet response time varies significantly – meaning that the onus is on individual companies to be more proactive in both tracking their exposure to open-source and other vulnerabilities, and in remediating that exposure.
“The whole thing that makes open source special is the community working on a project for a long time,” says Brad Gaynor, CEO of vulnerability-scanning startup company Lexumo. The company's technology, which maintains a cloud-based database of vulnerabilities and scans business source and object code to pinpoint vulnerabilities, this month helped the company secure $US4.89m ($A6.73m) in equity financing to support planned business expansion.
“When security is concerned, you have a lot of eyes on a project over time,” Gaynor continues. “But there are a lot of developers writing with code that comes from a lot of places, and people just lose track of it. Some companies don't know what code is in their products, or which versions – so when something like Heartbleed comes out and the question is raised about whether they are vulnerable, that's often very hard to answer.”
Businesses need to do a better job, he said, of not only keeping track of what software they install and what open-source components it includes – which can be particularly tricky if those components were integrated years ago and have mixed freely with proprietary code over many versions.
In such cases, it can be extremely difficult not only to know what open-source components are running, but also to keep track of the vulnerabilities that have been identified within those components – and their constituent libraries. By Hoovering up as many versions of as much open-source code as it can find, Lexumo's strategy is to scan applications for known code – even old code – and pinpoint where subsequently-issued patches are to be applied.
“The dirty little secret with free, open-source software is that the moment you integrate it into your product, it stops being free,” Gaynor says. “You own the maintenance costs. And if you don't take steps to shore up the security, you're setting the stage for attackers to come in and find those holes, and exploit them.”