Joomla Development Blog

Opensource Security Risks Explained

by in Development

Heartbleed made national news recently. If you're not familiar with it, a vulnerability was found in an open-source software library used by most of the web to transmit information securely. This affected credit card transactions and usernames and passwords and had the potential for serious abuse. It has a lot of people wondering how good of an idea it is to use open source security and whether open source applications, like Joomla, are secure. In this post, we'll explore how the "openness" of an application affects its security.

Knowledge is Power

To understand the risks, you need to understand how applications become compromised. Many applications and libraries are closed source. This means that you have to be in specific circumstances in order to be able to see the code and how it works. For example, if the code is compiled, which is common for many desktop applications, you have to have access to the not compiled source code. This is not distributed with closed source applications and is similar to the blueprints to a house. Unless you're an employee of the company that builds the application, you don't have this access.

For open source applications, the source code is available to read, study, and modify for everyone. Hackers use this transparency to look for vulnerabilities to exploit. It's like a burglar studying the blueprint of your house in order to determine where you sleep and which windows don't have alarms on them.

On a closed source application, hackers don't have the benefit of being able to see how things work. Instead, they have to use alternate scenarios to get at source code (hack to hack) or conduct penetration tests to discover where weaknesses exist. This is like someone throwing pebbles against your window to see if you're home.

Strength in Numbers

You might think that, by not being able to see the underlying code, closed source is more secure than open source. This is called security by obscurity, and is looked down upon in the development community because relying on this type of security means that you're relying upon the illusion of safety. You don't actually know whether you're safe or whether you have a weakness the developers didn't notice. This is contrasted to open source, where literally anyone can review the application's design and examine it for problems. In a transparent environment you know whether you're safe or not, because the code is under constant testing and observation. The larger and more widespread an open-source application is, the more people are looking and the better its security.

To come back to our burglar analogy, open source applications are like having thousands of security experts examine your house for weaknesses. Sure, everyone knows the layout, but they also know that it is unbreakable. This comes with the caveat that only updated and current open source applications remain bulletproof. If the application isn't kept up to date when a security flaw is discovered, then it becomes much more vulnerable. All that public testing and review doesn't help if you do not apply the results, but the hackers do.

And the Results Are In

In the wake of Heartbleed, many well-known companies like HP, IBM, Red Hat, Intel, Oracle, Google, Cisco have contributed funding to continue the development and testing of the affected software library. These companies develop and use both open and closed source applications, but when it comes to security, they've shown with their financial support for a security specific library that they believe in the benefits of open source and the power of public review. And you should too.

Last modified on
John is the owner and lead developer of Blue Bridge.  He's contributed to the Joomla project as a JCM author, JUG team leader, and a bug squasher.  In his spare time, he loves to write and read, advance his development and business knowledge, play video games, boulder, and spend time with his girlfriend and their dog Sunny.
blog comments powered by Disqus

Archives

Joomla Developer Hiring Guide