Your Guide to Open Source vs. Proprietary Software Security
Table of Contents
In an age when software relies on open source for faster, more efficient development, the debate over whether or not to use it for building applications would appear to be long over. The use of open source components is an established fact, comprising 60-80% of the code base in modern applications. Now the question that organizations are asking themselves is not whether or not to use open source components, but how to use them securely. This challenge leads many to ask what they should be considering when it comes to their open source vs proprietary software security approaches.
Even as there are no fundamental differences in the content of the code, after all, code is code, there is a divergence in how we secure open source components as compared to our practices for proprietary.
The two types of code face different threats, operate in different environments, and require different toolsets in order to keep them secure.
The threats are different
Open source components and proprietary code face different kinds of primary threats.
The fearful buzzword of the proprietary world in recent years has been that of the 0-day. These vulnerabilities are so feared because they are unknown and organizations cannot defend against them since they have not yet been reported. Discovery and exploitation of a 0-day in a widely used commercial product like Windows or iOS can be valuable and a significant threat to those proprietary applications.
However, when it comes to open source components, 0-day vulnerabilities are in general a lower priority given our threat modeling when it comes to open source component security. This is because 0-days are fairly specific in what they affect, so discovering and exploiting a single 0-day in an organization’s application is not particularly scalable. They can take months to find and their ROI is highly questionable.
Instead, known vulnerabilities which have been published are considered to be a bigger source of concern. This is because a popular open source project can be used in thousands of software products, so a single vulnerability can be used to a much more significant payday at a lower cost.
Hackers are fond of known vulnerabilities, viewing them as a proverbial free lunch. A nice window shopping trip to the National Vulnerability Database will tell them which components are vulnerable and how to carry out the attack. Since they know that there are going to be those who are not staying up on the open source vulnerabilities impacting their products, even if some are fast to patch, they can still target the stragglers.
This is a successful strategy for attackers in part because the information on these vulnerabilities is readily available. However, this openness is not without its advantages.
The open book vs. the closed garden
Probably the first concern that comes to mind when thinking about the issue of open source versus proprietary software is the fact that open source is well, open.
Posted to repositories like GitHub for public consumption, open source lays bare its source code for all to see and examine, warts and all. Whereas some may see this as a weakness, it is arguably one of open source’s greatest strengths in that it allows security researchers and other members of the community to review the code and find the vulnerabilities. Think more eyeballs, the better chance that vulnerabilities will be found.
This theory is backed up by statistics as reported open source vulnerabilities have risen by 51%.
These issues are then reported to the project owner and end up on either large security databases like the National Vulnerability Database (NVD) or on a variety of issue trackers and security advisories, becoming a known vulnerability.
The idea here is to bring information about vulnerabilities to the public as fast as possible, hopefully once a fix has been issued of course, in forums that are easily accessible so that developers can be alerted to the need to patch their products. This is a good thing that should be encouraged.
From a risk perspective, our concern is that hackers might beat us to the punch and take advantage of the posted intelligence, including important details about which projects are vulnerable and how to exploit them. The challenge for organizations is that the distributed nature of the open source community which can post to many sites, as opposed to the more centralized version in the proprietary and commercial software spaces, denies developers a “one-stop-shop” that could serve as a comprehensive database of all open source vulnerabilities.
This is a point where we begin to see some significant differences in how open source vs closed source security approaches operate.
Proprietary software security, by contrast, depends more heavily on their vulnerabilities staying unknown, hoping to avoid prying eyes of hackers who may be targeting them specifically. Staying out of the public square has its up and downsides.
On the plus side, when you have a vulnerability in your code, chances are fairly good that it will stay unknown. In order to find and exploit said vulnerability in proprietary code, a hacker would have to take the time to specifically target your product. However, if your product has data worth stealing or otherwise manipulating, then someone may decide that it is worth their time to poke around for vulnerabilities.
Taken from the minus side, less eyeballs are examining your code, meaning that you are less likely to find said vulnerabilities. There are threat intelligence solutions that track exploitations of various products in the hopes of giving teams a heads up on exploit kits and other kinds of risks, but it will still be a challenge to stay clear of 0-days.
Proprietary software security versus open source security in many ways comes down to a question of scale. Your exposure may be lessened through anonymity by staying in your closed garden, but you will not benefit from the eyeballs and wisdom of the crowd either. In proprietary software, we look to the vendor for answers, hoping that they are on top of their game.
The cathedral vs. the bazaar
By now everyone is familiar with Patch Tuesday when Windows issues their updates, including patches for vulnerabilities. Similarly, apps on your phone are being constantly pushed to your device by the vendor, including new features but plenty of bug and security fixes as wells.
Because proprietary software is handled by the in-house team, they are responsible for the entirety of the lift when it comes to dealing with remediations. They are the centralized body, charged with giving their users the most up to date versions of their software.
Open source works differently in a more diffuse manner. The open source community has become very efficient at developing fixes for vulnerabilities, but it is still up to the users to know which components they are using and to keep their software up to date with the latest versions that have addressed newly discovered vulnerabilities.
Open source projects are consistently pushing new versions as the community finds issues and improves the code. However, they do not have an implicit obligation to ensure that users of the open source components have the latest version.
To be blunt, when it comes to free software, it is up to you the developer to make sure that you are using the most up to date software. Nobody is going to do the work for you.
If we are already being honest, many developers, especially if they are not monitoring their open source usage and do not know which components they are using, are probably not checking for the updated versions. Many may be avoiding it for fear that the new software might not be backward compatible and could cause their product to crash.
Vulnerability management tools
Even as the in-house written code traverses various testing stages, undergoing static and dynamic sorts of analysis that poke and prod the code to find potential vulnerabilities that will need to be investigated by developers, some vulnerabilities are still likely to slip through. The hope is that the team can catch and fix as many issues as possible before the code is deployed. Developers can take the alerts from their SAST, DAST, IAST, RASP, and other tools and painstakingly sort through their product to either confirm or reject the findings of the application security tools (ASTs).
We need to remember that the challenge of testing proprietary code is that we do not exactly know what it is that we are looking for, since again, the vulnerabilities here are not yet known.
Open source may have an advantage here in that when we are testing the code we are not scanning the code for vulnerabilities, but instead, are monitoring it for open source components with known vulnerabilities associated with them. Only Software Composition Analysis (SCA) tools are capable of identifying and managing open source component usage.
SCA solutions work with large comprehensive databases that include the NVD as well as other resources which are likely to provide indicators of newly discovered vulnerabilities before they appear on the NVD.
The SCA tools can identify which components are present in a product, block open source components with known vulnerabilities from being added to the product, and alert on newly discovered vulnerabilities that are reported post-deployment to allow for timely remediations. Advanced solutions can even provide a trace analysis to pinpoint the location of vulnerable components within the product, saving valuable time.
Keep calm and code securely, no matter what you use
In the past some organizations were skeptical of using open source in their development, viewing it as inherently more vulnerable than the code that they could write themselves.
Today, these concerns have either been allayed or simply pushed aside as the advantages of using open source components have won the debate.
There is an argument to be made that because open source components are used by a wider community of users, they are proven out under an impressive stress test that works to find and fix the flaws along the way.
That said, there are no indicators that open source code is inherently any more or less vulnerable than proprietary. The differences come down more to factors such as dependencies that most open source projects are built on top of, providing them with additional useful functions. These dependencies can present challenges to open source security as they can contain vulnerabilities and require additional tools for tracking them and providing visibility at scale.
For developers today, the choice is no longer a binary one when it comes to open source vs closed source security as both need to figure into your strategy for keeping your product secure.
What we can say is that so long as your organization is following best practices when it comes to updating to the latest versions, utilizing the right management tools, and test early and often, then it should not matter what kind of code you decide to use. Respect their differences and work with them accordingly to build innovative products that stand out to customers, meeting your deadlines while staying secure.
