This is the story of a cloud and its silver lining.
First, the cloud: Numerous programming flaws in the Android kernel include 88 high-risk defects that could leave users’ sensitive information exposed, analysis firm Coverity announced today.
Specifically, in a study whose results are due to be published tomorrow, Coverity examined the code in version 2.6.32 of the open source Android kernel, which is used in phones including the HTC Droid Incredible. Some 359 software defects were revealed by Coverity’s analysis, and roughly 25 percent of those were considered high-risk, with the potential to cause security breaches and crashes, the firm reported.
The study is part of the 2010 edition of the Coverity Scan Open Source Integrity Report, which details the analysis of more than 61 million lines of open source code from 291 popular and widely used open source projects. Included among those projects analyzed were also Linux, Apache, Samba and PHP.
Coverity has notified both Google and HTC about the Android flaws. If verified, they could be fixed via a wireless update.
Discoveries such as this one might seem alarming for users under any circumstances, but they’re potentially even more troubling in this case given the increasing use of Android smartphones by business organizations.
Android now dominates the U.S. smartphone market with a 44 percent share, Canalys just reported today. Not only that, but much of the platform’s growth has come at the expense of Research in Motion, whose BlackBerry platform has long been a favorite among businesses. Specifically, Android grew from 33 percent of all smartphones purchased in the U.S. in Q2 to 44 percent in Q3, NPD Group reported this morning; RIM, on the other hand, declined from 28 percent to 22 percent during the same period.
Recognizing Android’s growing role in the enterprise, in fact, Google just last week introduced new administrative controls to help businesses manage Android-based devices.
The Silver Lining
Lest businesses begin to question Android’s suitability for enterprise use in light of Coverity’s new data, however, let’s turn now to the cloud’s silver lining. First is the fact that the code in the Froyo kernel Coverity studied actually had fewer flaws per thousand lines than most open source code does, the firm said. That’s not to say that open source code is buggier than closed source code, either–it’s just that closed source code isn’t available for analyses like these, so no such comparisons can be made.
Therein, in fact, lies the second, even more significant point to remember here: It is only by virtue of the fact that Android’s kernel is open source that these problems were even found. There’s an excellent chance that Apple’s iPhone, for instance, includes at least as many programming flaws, but the world will never know because that code is proprietary and visible only to Apple.
As with the Linux operating system it’s based on, one of the big security advantages of Android is that much of the code is open and thus visible to the world for inspection and testing. Apple’s products actually have more security flaws than any others, research firm Secunia recently declared. But because its code is closed, iOS will never benefit from tests such as Coverity’s.
The Open Advantage
So while it’s certain iPhone fans will jump on Coverity’s data as evidence for the superiority of their favorite platform, the reality is that this data proves why open code is more secure. When code is closed, the world depends on the company that made it to test it, find the problems and fix them quickly. That’s a lot to expect of any single entity with limited staff, competing pressures and a constrained timetable.
Open code such as that in the Android kernel, on the other hand, can be continuously scrutinized every day by interested developers and users around the world, as well as by analysis firms like Coverity. The result? Flaws are found and fixed more quickly, and the resulting code is better. Forget silver linings–this one just might be solid gold.
Follow Katherine Noyes on Twitter: @Noyesk.