Ever wonder how secure your open source web application really is? Security company Qualys has a tool called BlindElephant that can tell you, and they have run some tests.

What A BlindElephant Can Tell You

Qualys has offered its BlindElephant software as an open source tool to help you get all the details on your web applications (called fingerprinting), right down to what version of software you are using. It can help you learn a lot about your application (or someone else's if you the curious type).

To show what its tool can do, the company used BlindElephant on a number of well known open source applications running on over 1 million hosts (Note that this tool can be used on both open source and commercial applications).

The result? Qualys said it found "extensive vulnerabilities" on many sites. Some of the numbers:

  • 77% of Movable Type sites
  • 91% of Joomla Web CMS-based sites
  • 95% running MediaWiki 
  • 69% Drupal based sites

Qualys points out that WordPress only had 4% critical vulnerabilities and 21.5% medium:

Editor's Note: The BlindElephant tool does not explicitly identify vulnerabilities. What it does is tell you if the software versions you are running have known security issues. What is does not do is take into consideration if you have already found these and fixed them. Read the whitepaper to understand exactly how the tool works

BlindElephant Web Application Survey Report - WordPress Results

There is a whitepaper outlining how BlindElephant works and the results of the testing they did. If the BlindElephant tool interests you, download it here.

Fortify, another software company has identified similar concerns towards open source in recent research they did several years ago. This company did a survey and found that most OSS development communities do not have a secure development process and "often leave dangerous vulnerabilities unaddressed".

Mozilla is pointed to as an example of a company that has taken security to heart by hiring Rich Mogull as security chief.   Sorry all, this is not true at all, it was taken from a very old article, consider my fingers slapped for not checking the date before I referenced it.

Fortify identifies three ways to improve security in open source projects:

  1. Hire a real security expert
  2. Build security processes into the SDLC
  3. Use the correct tools to test the security procedures

Is Open Source Really Less Secure?

Not exactly. Microsoft is the perfect example of how commercial solutions are equally vulnerable. Seth Gottlieb, founder of Content Here and author of Drupal for Publishers, agrees:

All software (no matter what the license is) has vulnerabilities and there is a constant battle between hackers and developers over them. A hacker (or developer) finds a vulnerability, the development community responds with a patch that closes it. Much of the development on any software platform is closing up holes."

Gottlieb does acknowledge there are differences:

  • Because the source code is open, the cycle of identification and resolution of security vulnerabilities happens a lot faster than with closed source code.
  • Open source software has lead the way in social software. Social functionality has the potential to be more vulnerable than read-only functionality. Anything that a user submits can be malicious and needs to be filtered for potential exploits. A static website with no user-inputs has less to worry about.  
  • Open source software tends to be more modular. The modules that you use may be less secure than the core application.

Keep Your App Safe

Gottlieb offers some advice for those using open source technologies (some this even applies to commercial software):

  1. Keep your software up to date. The ease of upgrade should be an important selection criterion.
  2. Look for open source software with attention to security built into the culture of the development community. The number of vulnerabilities discovered alone is not a good metric. A security-conscientious community will be proactive about finding and fixing even borderline vulnerabilities. More important is the type and frequency that vulnerabilities are introduced. If every new release is followed by a flurry of security advisories that take a long time to resolve, you should be concerned.
  3. Pay as much attention to the security of the modules as the core software. Popular modules that are submitted by highly regarded developers tend to have a better track record than random submissions.