The Shellshock vulnerability, found last week, raised, once again, concerns regarding the robustness of open-source based solutions. Shellshock is the second major vulnerability discovered this year, in an open-source package. In April, OpenSSL Heartbleed bug was considered a devastating vulnerability and a game-changer in the info-security arena. Less than 6 months later, Shellshock, a security-vulnerability in the open-source Bourne Again Shell (BASH) was threatened to be “even bigger than Heartbleed”. These headlines, fueled with NIST declaring Shellshock’s risk score as 10/10 made some IT managers wonder if choosing an open-source solution was the right decision. The short answer is Yes. Open-source solutions are as robust as vendor proprietary solutions and sometimes even better.

First question that may be raised, is the issue of including security technologies (more specifically crypto algorithms) in source-files that can be viewed by potential malicious users. Back in 1883 (yes, we’re talking 19^th century, this is not a typo) Dutch cryptographer, Auguste Kerckhoffs stated that “A cryptosystem should be secure even if everything about the system, except the key, is public knowledge” (this is known as Kerckhoffs’s Principle). The assumption that the enemy knows  your system actually simplifies the crypto system, as developers need to assume that only very limited and specific information is needed to be secured (aka the crypto-system ‘s key), while the rest (the software and its design principles) is not.

Crypto algorithms, however, play only small portion in today’s security world. The latest vulnerabilities highlight this fact. The Heartbleed vulnerability was created because of poor memory-boundaries’ checks and managed to reveal arbitrary information that was kept in the OpenSSL memory space (this memory area is likely to contain sensitive information, passwords and cryptographic keys). Shellshock is a serious of vulnerabilities in the environment parameters export mechanism’s state-machine. Nothing to do with the accessibility to cryptographic algorithms’ code.

How can we make software packages more robust? The answer was given about 100 years ago. In 1914 USA Supreme Court Judge, Louis D. Brandeis, wrote “Sunlight is said to be the best of disinfectants”. In our case peer-code-reviews help to disinfectant code from its bugs and vulnerabilities. Open source solutions let numerous developers, with different skill-sets, knowledge levels and business-goals, to review the code and make sure that it is free of bugs, vulnerabilities and back doors.

Open source solutions are, generally speaking, more secure and more robust than their commercial equivalents. OpenSSL as well as the BASH code have no more vulnerabilities than any other software component with the same complexity, with two exceptions: a. it is easier to spot the vulnerabilities as their code is widely available, and b. as they offer good alternative to commercial packages at lower maintenance code they are usually much more popular, which creates the headlines that we saw last week (and in April) regarding the risk level of vulnerabilities’ found in them.