Study: More than 50% of Global 500 use vulnerable open source components

Study: More than 50% of Global 500 use vulnerable open source components

Summary: A joint study conducted by Sonatype and Aspect Security found that many open source components, security libraries and web frameworks contain vulnerabilities, and that many Fortune 500 companies have downloaded and built applications based on these components.


More than 50 percent of the world's largest corporations have open source applications with security vulnerabilities.

That's because more than 80 percent of software applications built in-house by enterprise developers incorporate open source components and frameworks that may be vulnerable.

Those are data points that most open source backers might dismiss. Still, one joint research report issued today by Silver Spring, MD-based Sonatype and Aspect Security say they're true.

Sonatype CEO Jackson

Sonatype CEO Jackson

The report -- based on a survey of 2,550 developers, architects and analysts -- maintains that the widely held view that open source software is consistenly high quality "overlooks ecosystem flaws," chiefly that lack of a notification system alerting developers about vulnerabilities and new versions with fixes."

"80% of the code in today’s applications comes from libraries and frameworks. The risk of vulnerabilities in these components is widely ignored and underappreciated," wrote Jeff Williams, CEO and Arshan Dabirsiaghi, Director of Research at Aspect Security, a Columbia, MD-based  application security consulting firm.

Aspect CEO

Aspect CEO

The report claims, for example, that there have been 46 million downloads of insecure versions of  the most popular open source libraries and frameworks, including Google Web Toolkit, Spring MVC, Struts 1.X. and Hibernate.

The report found that Struts 2  -- which was reportedly downloaded more than one million times by 18,000 corporations -- contained a critical vulnerability.

The survey results also maintains that 37 percent of all versions of 31 top components tested contained a CVE or OSVDB vulnerability, and that popular components are only 10 percent less likely to have vulnerabilities than less popular ones, the study found.

The report also claims that only 32 percent of organizations "maintain an inventory of the dependencies in their production applications, complicating issue resolution when a new vulnerability is discovered."

"With more than 80 percent of typical software applications using open-source components and frameworks consumed in binary form, the results of this research are a wake-up call to nearly every organization developing software to run business-critical functions," according to a statement issued by Aspect Security, a firm with application security expertise and a founding member of the Open Web Application Security Project.

Sonatype, which markets its Nexus Intelligent Repository Manager to improve the quality of software component development, is led by CEO Wayne Jackson, the former CEO of open source network security firm Sourcefire. The company was founded in 2008 by Jason van Zyl, creator of the Apache Maven build system.

The conclusion? That enterprises should maintain and strictly manage inventories of software components.

Some top open source developers had a different take on key findings of the report.

Rene GielenChair of the Apache Struts Project Management Committee, did not dispute the findings but questioned whether the suggested solution is right in all cases.

"Open source software has flaws and will have flaws, as any other software product we know of today. While we will for sure not succeed in making our software products flawless, we can do our best to address such issues as soon as they are reported," wrote Gielen, on behalf of the entire project. "Most open source projects, Apache Struts included, have in general good track records in addressing security issues quickly and professionally and providing fixed versions as soon as possible."

"One thing we have to be clear about is that automated upgrade notifications and processes, as found in many desktop products, are not an option for the class of products we provide," the Struts developer said. "Where would an application server product, a web framework such as Struts or even a library provide such information in it's runtime context? How would the notification be sent out to the product installations, given that enterprise setups most likely will separate the installation from direct internet access?

A key member of the Apache Tomcat project offered this take:

"The numbers don't surprise me at all... It is certainly the case that there are organisations that continue to run vulnerable software (open and closed source) without realising what they are doing. I do not believe this is a problem unique to open source nor one that is particularly worse or better with open source compared to closed source," said Mark Thomas, a member of the Apache Tomcat Project Management Committee who is also on the Tomcat security team.

Thomas noted that many enterprises likely already have workarounds. Here are some possibilities that Thomas proposes:

1. The vulnerability applies to certain configurations and the organisation is not using a vulnerable configuration. 2. The vulnerability may be mitigated by another component in the stack. I can think of some Tomcat vulnerabilities that could not be exploited if Apache httpd was used as a reverse proxy in front of Tomcat. 3. The risk of continuing to use the vulnerable component is less than the risk of upgrading the component.

Andrew Aitken, founder and managing partner of Olliance Group, which is now owned by Black Duck Software, took issue with the sentiment of the report.

"It’s unfortunate to see this and we disagree with the tone of the study inferring that open source is low quality and risky," said Aitken, Founder and Managing Partner of Olliance Group.

"All software has vulnerabilities, and this study doesn’t compare open source to other code. It just says open source has “x”,  and there have been many studies showing that OSS is higher quality than most other code," wrote Aitken, who cited key findings from a 2010 Coverity Open Source Integrity Report.

That report, based on Coverity's 2009 analysis of 280 open source projects including Linux, Apache, Firefox, Samba, PostgreSQL, OpenVPN and others, found that the open source software defect density is four times lower than the software industry average. Android's defect rate was said to be less than half the software industry average.

"It shows open source is generally higher quality," Aitken wrote, in response to the Sonatype-Aspect Executive Brief: Addressing Security Concerns in Open Source Components.

It's important to note that the Sonatype-Aspect study focuses on components, frameworks and libraries, as opposed to commercial open source applications or open source projects.

The Sonatype-Aspect execs -- who are major proponents of open source software -- were quick to respond to criticism with this lengthy e-mail explainer of its findings:

"At no point in the study do we say that Open Source is low quality.  Sonatype after all is a company of open source software developers, a key contributor to the open source community through support and contribution to projects including Apache Maven, M2Eclipse, Nexus, Tyco and firm believers in the superiority of open source software.

What we're attempting to point out by this study is that open source is great for development and there's lots of benefit, but there's also risks that organizations need to be aware of -- mainly the idea that the open source ecosystem has no notification infrastructure -- so to date, there's no good way for developers to know when flaws are found in the components they are using to build software. Imagine your PC without auto-update, having to dig through release notes, searching for security bulletins, tracking down critical fixes.

Sonatype is committed to changing that and we view the Central Repository, the software development industry’s canonical exchange for software components as a key Sonatype asset and vital to this mission. Central enables real-time visibility into the software development ecosystem.  Sonatype is uniquely able to know when any of the hundreds of thousands of components in Central are updated and who, among tens of thousands of organizations, are getting what components from Central every day. No other organization can provide this detail.

Our study simply brings to light the activity occurring in the Central Repository every day -- by thousands of development team around the world.  We are not comparing open source code to proprietary software as other studies have done.  We are examining how components (the building blocks of modern applications) are being used by organizations to build software, and bringing to the forefront of conversation, the need for better component intelligence and change awareness.

Apache Struts' Gielen said it's a reminder that all enterprises must incorporate security fixes and patch management systems for all applications -- open source or not.

"We as open source framework providers cannot overemphasize how important it is to keep up with latest security fixes and see it as part of the profession to develop and run business critical software," Gielen wrote. "While we all got used to frequent operating system and desktop application updates, we seem to fail sometimes to transfer this habit to our enterprise application projects where automatic patch provisioning is not an option."

Topics: Apps, Open Source, Security

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • In other news : 500 of Global 500 use vulnerable closed-source components

    Microsoft software has many verified flaws, and is regularly used in mission-critical parts of all these companies. But, by all means, try and discredit open source software...
    • did you read...

      the whole article?

      The point is more that a lot of large companies end up with this OSS software creeping into projects, undocumented. The project goes live and nobody worries about it again.

      Most OSS projects I've worked on / with have had security bulletin newsletters, which detail vulnerabilities and inform the recipient on how to fix the problem or that a patch is available.

      The problem is, a lot of devs download the code chunks or products and don't bother to sign up for the security newsletter - or they move onto another project and the people doing the maintenance don't know anything / enough about the components used to realise they have a security vulnerability sitting there, waiting to be exploited.

      With closed source software, somebody, somewhere had to register it, usually centrally and through newsletters, upgrade offers or automated update reminders, the company is at least informed of problems. Likewise, because of the licensing, the closed source products are usually well documented within the project and the licence handed over to support.

      My big take-away from this report is that companies implementing OSS projects, components and frameworks in their internal products need to fully document their usage and have a central administration for those projects, just like they do for closed source products. They need to register for the security bulletin newsletters and perform due dilligence, when a vulnerability is reported.

      The ease with which OSS software can be used within a project is also its greatest drawback - there are no external controls in place, like there are with closed source products, to ensure that it is properly licenced and maintained.
      • What to take out is...

        You need to know all libraries used and stay on top of any patches.

        Be particularly careful of orphaned projects.
        Richard Flude
      • memento conficker

        >>With closed source software, somebody, somewhere had to register it, usually centrally and through newsletters, upgrade offers or automated update reminders...

        And where was this system when an alleged patch did not have any affect on the millions of infected by conficker servers?
      • @eulampius

        The people were informed of the patches, whether they decide to install them or not is another problem.

        With OSS, the point is most companies aren't even aware that they are using the software, because it wasn't purchased and maintained centrally, but slipped in the "backdoor" during the project and not properly documented in the support handover.
      • vice-versa, @wright_is

        >>The people were informed of the patches, whether they decide to install them or not is another problem.
        Do bear in mind, that it is much much easier to maintain a complete Linux distro, say Debian, where you get all the security notifications and updates in one chunk. Compare it with the Windows where the "1st,2nd, third parties" are independent of MS and each other -- you get tired of monitoring all of those.
        >>With OSS, the point is most companies aren't even aware that they are using the software, because it wasn't purchased and maintained centrally, but slipped in the "backdoor" during the project and not properly documented in the support handover.

        The history and statistics are in contradiction with your theory. You might be getting it all upside-down. The ignorant must be those that buy stuff from M$ and like. If you chose free (as in "freedom") alternatives, you tend to be somewhat more informant. At least, for 8 million conficker infections vs. ??? Linux/BSD infections, while the latter (with Apache and nginx) comprise more than 75% of the publicly available web and mail servers.
    • Well, yes but wait, there's more!

      If you're going to bag on Microsoft, don't forget to include IBM, Oracle, in fact any big software creating entity as punching bags too. Big software (deployment, machine sizem which does matter!) generally causes big effects. Just ask the LSE.
  • RE: Study: More than 50% of Global 500 use vulnerable open source component

    [i]The risk of continuing to use the vulnerable component is less than the risk of upgrading the component.[/i]

    This is also a common excuse for failing to patch SCADA systems.

    All music to the ears of the malware miscreants.
    Rabid Howler Monkey
    • Have you ever worked in a real SCADA system

      10,000 or 20,000 data points and corresponding measurement devices? You know, systems that control hazardous waste and people are maimed or die when they fail?

      Let???s just update without regardless of difficulties, incompatibilities, and who knows what the patches will do to the custom written, incredibly difficult to test code?

      Ever thought about getting a job in a plant that uses SCADA equipment and trying to force the engineers to upgrade just ???cause the latest patch came out?

      Good luck.
      • RE: Have you ever worked in a real SCADA system

        Not all patches are created equal, meaning that some are more important than others. In addition, sometime workarounds can be applied in lieu of patching. Thus, the "latest patch" might be critical or it might not be (with or without applying a workaround).

        Most of us [i][b]depend[/b][/i] on SCADA systems employed at oil & gas fields, natural gas pipelines & compressor stations, power plants, railways, chemical plants, etc.

        I sincerely hope that [i][b]your[/b][/i] SCADA system is not accessible via the internet. Not that it mattered for the Natanz uranium enrichment facility in Iran (think centrifuges) or the U.S. Air Force drone system, neither of which were accessible via the internet.

        How many would die if electrical power was down for a few days in Phoenix, AZ, during July or August? Or if the natural gas supply was cut off for a few days to Chicago, IL, or Minneapolis, MN, during January or February? Or if a commuter train were taken over during rush hour and crashed? Or if a chemical plant were taken over resulting in a leak or an explosion and fire?
        Rabid Howler Monkey
      • At least get them of the internet

        While DoD proved that even airgapped systems can get infected, it is at least better than nothing. Avoid huge centralized systems with direct internet access and no firewalls. But I guess that would take a couple of decades to just fix the basic architecture, though...
      • So you are saying update even when the vendor says NO!

        Rabig Howler -
        So you are saying even when the vendor says DO NOT UPGRADE because they won't support the SCADA system at that point you should upgrade anyway?

        While all patches are not equal, seems safer to pay attention to the vendors to ensure that they function properly. I must wonder if you've ever even been in a control room where SCADA systems are used. Yes, I have and I have worked on said systems in the Natural Gas industry.

        We get pretty touchy about SCADA systems because things go boom and people die when something goes wrong.

        Since everyone here seems to know what is higher risk, being un-patched and vulnerable or plowing ahead without proper testing, I'll leave your lives in your hands. As for me, I'll work with the vendors and take my personal safety first.

        Seems a much higher risk to patch without testing than to be vulnerable. While being vulnerable may not result in an incident, patching without testing nearly always leads to incidents.

        Where do you get your information?
  • Transparency

    I would mention that on average if you apply maximum entropy to your statistic, there are as many programming bugs randomly occurring everywhere.

    Some yield exploits, some are merely vulnerabilities.

    What you cannot measure is where in the bell curve does Microsoft's proprietary software fit and what is their standard deviation--because the GP does not have access to their source code for peer review purposes.

    Transparency is a cornerstone of Open Source. The quality of Open Source code is enhanced by peer review coming from all corners of the Globe, unlike exploitative Proprietary methods.

    Let's bear that in mind here and take this story with a large 'grain of salt'.
    Dietrich T. Schmitz *Your
    • DTS - this must sting...

      a little or maybe a lot.
      • I am doing fine. Why?

        Dietrich T. Schmitz *Your
    • Transparancy does not equal Quality

      QA is far more important to security than transparancy. The simple fact of the matter is that sourceforge is littered with dead projects and projects that have only one or two developers with no real QA.

      And again, your tirade against Microsoft is based on fallacious information. Microsoft code is peer-reviewed, as well as undergoes vigorous QA. With tens of millions of lines of code, the defect rate is significantly better than say - Sendmail. Microsoft code is not hidden. Many organizations have access to it. That the code is not available to you personally is secondary.

      Let's bear that in mind and take your comments iwth a large grain fo salt.
      Your Non Advocate
    • Transparency, an example

      Google's Android is considered an open-source OS by many open-source fans, whereas iOS, despite its FreeBSD roots, is a proprietary OS. Let's look at the current rates for exploits involving these two mobile OSs:

      Android: $30,000-$60,000
      iOS: $100,000-$250,000

      For more information, see the ZDNet Zero Day article dated March 25, 2012, entitled, "US government pays $250,000 for iOS exploit" or the original Forbes article dated March 23, 2012, entitled, " Shopping For Zero-Days: A Price List For Hackers' Secret Software Exploits".

      By your line of reasoning, Android should have both fewer and less serious vulnerabilities than iOS because of the transparency associated with open-source software. The prices for exploits based on vulnerabilities should also reflect this transparency. However, iOS exploits sell for more than 3, and sometimes 4, times the price of Android exploits. Or are Android vulnerabilities simply more exploitable than iOS vulnerabilities?
      Rabid Howler Monkey
  • Why does every item of software have to be vulnerability-free?

    I'm totally ignorant of the technicalities, but understand that nowadays nearly all software is in constant need of patching and updating. Ordinary end-users may install Secunia, but if they're like me it just drives them mad to the point where they turn it off.

    If the problem is general, why isn't there a general solution that protects your computer even from the little bits of code you wrote when you were a teenager?

    It's important to remember that most scientific, technical (and I aassume business) users are running software that's ancient, and that they can't replace, even if the supplier hasn't disappeared or been taken over.

    It may simply be a question of habit and of not being able to afford two computers. Basically, you should not be connected to the web when your application doesn't need that for the moment, but unfortunately modern life also requires instant access to email and online applications.
    Daddy Tadpole
    • HIPS and sandboxing

      Host Intrusion Prevention Systems and sandboxes should be used everywhere. Minimal permissions by default, full "reversibility" if something goes bad (using snapshots in the sandboxes or even in the filesystem, like with ZFS) and you're pretty safe. Comodo CIS is a good free HIPS-style AV for home users (Windows only, for now). But ideally, I would want one to be built in into the OS.
  • Study: More than 50% of Global 500 use vulnerable open source components

    All the more reason not to use linux since it is the most vulnerable open source software.
    Loverock Davidson-