Will Open Source Make Proprietary Software More Secure in 2024?

For many years, open source and proprietary represented different values. One was open, and the other closed. One was free, and the other cost money. One was secure, and the other invited catastrophe — a claim lobbed by both sides. Now, it's all so blurry.

It's not so much that open source is more secure than proprietary software — or vice versa. Open source projects benefit from strong contributor communities. Similarly, proprietary software benefits from good development practices and organizational resources.

The real question here: What happens to security when software are combined?

Open source has infiltrated more than half of closed-source software. Developers don't want to reinvent the wheel. But what's expedient isn't always secure.

Which is More Secure?

It's not fair to presuppose that either open-source or proprietary software is more secure than the other. That's been argued and disproven over the years, yet there are still tropes associated with each software framework.

Proprietary software operates on "security through obscurity," where only the developer organization's employees or privileged contractors create, access, and maintain the source code. In this model, a small team develops and tests the software. Following the organization's quality assurance (QA) process, the software is only seen by the outside world as binary code or web app pages.

Commercial priorities drive the developers of proprietary software. Financial imperatives (think constrained development costs) and the need for specific functionality guide their release timing. While they can detect bugs in proprietary software and develop and distribute patches, customer admins need to apply them to reduce vulnerabilities.

Open-source projects are less affected by these drivers. In practice, open-source projects have a much shorter interval between releases. They also have an extended community of developers and testers. Users can detect and report vulnerabilities in the open-source release and provide fixes that the project team can distribute to the entire project community.

The primary rationale for open source software (OSS) being more secure, is that code is open to review and testing by the entire community for the particular project. It's also available to anyone who wants to use it in full — or in part.

Proprietary isn't Proprietary Anymore

Odds are that you have open-source snippets in your code already — and it might make your software less secure. Back in the dark ages of coding, every line of code was the product of the development team that wrote it. Today, that's not the case. The development of open-source tech has generated enhancements that a lot of companies are using, whether they know it or not.

A 2023 Open Source Security and Risk Analysis (OSSRA) report stated that in an audit of 1,100 commercial applications, 96 percent contained elements of open-source software, with an average of 257 open-source components per application. The reasons behind this are evident, as open source generally costs less, speeds up time to market, and gives developers more room to be productive.

In terms of security, that's problematic.

Many open-source communities have many developers who undertake thorough reviews of the code base. Not all open-source projects have a large community of contributors, and they aren't all looking at the entirety of the code base. In that case, it's possible for problems to remain undetected until someone exploits them.

An example was the Heartbleed bug in the OpenSSL cryptography library, which came to the public's attention two years ago. In the interests of equal opportunity, we should also note that Apple, the 'poster child' for proprietary closed-source software, also had a critical security flaw in their SSL implementation before Heartbleed.

Once you take the code away from the "many eyes" of the open-source community, then the software developed around them becomes less secure.

Monitoring and Managing Your Open-Source Components

The prevalence of open source in homegrown applications leads to increased security exposure. This exposure is not because open-source software is less secure than homegrown code. It has to do with the legalities of embracing open source in applications.

Under the third version of the GNU General Public License (GPLv3), any application using code licensed as open source is required to make their source code open, as well. With the potential violation of IP at stake, you're left with little choice. And this opens up your code to more exposure, for better or worse.

Open source software's risk also has to do with adopting components without due regard for their management. Developers might not spend as much time reviewing or testing the open-source code they're using. If it behaves the way they expect, then they assume that it's going to work.

Once open-source components are living in a proprietary code base, they can become invisible. Cue a major security bug, and most companies struggling to assess whether they were exposed and through which applications.

The solution is not rocket science. Automated software composition analysis (SCA) tools available (even open-source ones) can search for and identify open-source components in a code base. Using a U.S. Government list of Common Vulnerabilities and Exposures (CVE), an SCA tool can identify any cybersecurity bugs reported for the components, together with their associated risk.

Check Your Development Processes

It's unlikely that we will ever be able to kill all bugs that lead to security vulnerabilities. It doesn't help if development shops are not following current best practices for the software development life cycle (SDLC).

For example, does your security team review the status of vendor or open-source project patches? The infamous Equifax hack exploited a known vulnerability to steal the personal data of 143 million consumers. Did you know there was a patch for that vulnerability? Have you applied them?

Researchers found that over 60 percent of the applications audited contained security vulnerabilities due to open-source components — with some flaws being over four years old.

Hackers are always on the lookout for new ways to attack systems and networks. There are also popular attack vectors like 'injection attacks' that have existed for many years. Having said that, how many development teams understand how to build code that's resistant to these attacks and test for them?

How many DevOps teams use static and dynamic application security testing tools — with their source code (static testing) and with their app in its running state (dynamic testing) — to ensure they cut known vulnerabilities from their apps?

Vigilance is Key in This Combined Terrain

It is good security practice to maintain attention toward both expecting and repelling security threats. It doesn't matter whether you have an open-source system, a proprietary system, or a bit of both. If you leave a "door unlocked," a bad guy is going to stroll in and steal your valuables.

Most common security breaches are due to the behavior of people or development, deployment, and operational processes. In light of that, it's fair to say that robust procedures and practices are essential to an organization's cybersecurity. As long as the entire organization is vigilant about security threats, there is every reason to believe open-source software can be as secure as its proprietary alternative.

When you mix the two software types, it opens your application up to the best of both worlds. You can pick and choose the elements that will make your product work best. But opening your application to either software type also opens your application to all risks associated with both types. This is why maintaining good security practices is key in this age where "proprietary software" doesn't necessarily mean what it used to.

If you're interested in IT security, consider starting with some White Hat Hacking. Our course introduces you to ethical hacking tools and techniques. If you're a DevOps professional interested in developing penetration testing skills, our Penetration Testing with Linux Tools course is worth checking out.