Is open source software inherently less secure than closed-source code?

Which special security precautions should you take with open source?

Keep reading for a primer on open source software security.

When it comes to open source, one of the longest-standing debates is whether code that is open is inherently less secure.

There are two main schools of thought:

·       First, there is the school that says open source code is less secure because anyone can examine it. In theory, the ability of hackers to look deep under the hood of a software program by inspecting the source code could help them find security vulnerabilities to exploit.

·       Second, open source advocates tend to point out that making source code publicly available can increase security because it allows anyone to review the code for security purposes. Rather than relying only on in-house developers to find security flaws, anyone in the open source community can help find and patch security issues.

Both talking points have their merits. 

Personally, I think the second one makes more sense, however.

After all, inspecting source code is not the only way that an attacker could discover a security vulnerability in a program.

There are plenty of vulnerability analysis tools out there that work against closed-source software.

Plus, if you subscribe to the idea that closed-source software is more secure because no one besides the developers can access the source code, then the implication is that the developers of closed-source software can always be trusted not to insert backdoors into their programs deliberately.

I'm sure most closed-source developers are good people.

But I wouldn't necessarily trust them all.

For that reason, I'd rather use an open source program that anyone can study than blindly place my trust in a closed-source program.

Securing Open Source

No matter what you believe about the security merits of open source code, there are things you can do to improve the security of the open source software you use.

Consider the following:

·       Make sure you get your code from a trusted source. This is especially important when it comes to open source software, which in most cases can be redistributed by anyone who wants to redistribute it. Don't download an open source program from the first website or repository you find offering it. Instead, grab the program directly from the original developers — in most cases, you'll be able to find their source code on GitHub — or from a download center that you trust, such as the official open source software repositories maintained by the major Linux distributions.

·       Keep open source code up-to-date. Depending on how you obtain open source software, and which kind of platform you run it on, it may or may not automatically update itself when security patches are released. If your operating system doesn't update the software automatically for you, make sure to do it yourself, or install an update mechanism that can automate the task.

·       Secure all the pieces of your software stack. Closed-source programs tend to come in big, monolithic bundles, and they handle security and updates in a uniform way for the entire bundle. When you use open source, however, you often build software stacks using many different components from different places. For example, if you run Docker containers, your container runtime comes from one source, your orchestrator might come from somewhere else, your container registry could be from a different source and so on. To keep your system secure, you need to lock down and update each layer of your open source software stack.

·       Remember that not all open source code is fully open. In certain cases, open source platforms may contain bits of closed-source code. This is the case with most Linux distributions, for example. They use "binary blobs," or bits of proprietary firmware, to power certain hardware devices. This means that, while the vast majority of code in these systems is open, small parts of it are not. You can't place the same level of trust in the closed parts as you can in the open ones. In an ideal world, you'd be able to work around this issue by avoiding binary blogs altogether. But if you can't do that, at least keep in mind that they exist, and that no one except their original developers knows exactly what code is running inside of them.