6 Open Source Software Security Concerns Dispelled
Table of Contents
Used by developers around the world, open source components makes up 60%-80% of the codebase in modern applications. Open source components are downloaded thousands of times per day to create applications for organizations of varying sizes and across all industries.
But despite the continuously growing adoption there are still myths to dispel and concerns to mitigate around the usage of open source components in commercial software. The following is a list of the top concerns associated with open source usage and how to overcome each one of these stumbling blocks:
#1 Open Source is Not Secure
Though progressively less of a concern to software executives and developers, there are still those in the non-development space who fear open source’s lack of a strong central management leads to a less secure code. Those that worry about the way open source projects are managed, lack the tools to ensure proper vulnerabilities detection and concern themselves with ill managed processes of code reviewing. Some view the abundance of vulnerabilities that go unnoticed in open source projects as testament to the lack of a “mother and father” to bear responsibility for the code, which places too big of a burden on the shoulders of adopting organizations.
Mostly Fiction: Let’s be very clear here, open source code is as secure at least as proprietary. It’s all a matter of how it is used and managed.
The one valid concern about open source’s security issue is that once a vulnerability is found in an open source component it becomes public knowledge and at the fingertips of hackers to abuse. A proper monitoring system that notifies of vulnerabilities in real-time and allows for quick and effective remediation takes the sting right out of the “unsafe” claims and makes it much harder for hackers to attack.
Software composition analysis tools (SCA) are designed to answer this very concern, giving full range detection and remediation solutions for open source inventories.
#2 “Many Eyes” is a Double Edged Sword
Linus Torvalds famously said that “given enough eyeballs, all bugs are shallow”. That is certainly one of the purported benefits of open source projects. Yet there’s another way to interpret the “many eyes” metaphor, and its a real concern to some.
The more popular an open source project is the more likely you are to make use of it. But also the more likely ill intentioned hackers are to exploit it. Once a vulnerability in a popular open source component is made known, it becomes a prime target for exploitation. A vulnerability in a popular component serves hackers as a single point of entrance into a multitude of systems and databases to be hacked.
True But in a Good Way: Yes, popular open source components pose a problem for security teams who must detect and remediate vulnerabilities before hackers get to them. But remember hackers only exploit known vulnerabilities in open source. By known vulnerabilities, we mean publicly published ones to which developers, like hackers, have access to. This means that ongoing monitoring of your open source inventory against the NVD, vulnerability listings and issue trackers will allow you to detect vulnerabilities in your code and respond to them before hackers do.
A state of awareness and continuous monitoring of your open source components is critical to staying ahead of the game. For this reason many organization have taken to automated tools (Software Composition Analysis) to ensure real-time alerts of open source vulnerabilities.
#3 Licenses are a Legal Liability Waiting to Happen
There have been claims out there that the use of open source components may require you to expose your source code and put you at risk of intellectual property loss. Much of the hype surrounding such claims revolves around copyleft licenses which require turning over your entire code to the public domain.
Another source of concern has to do with the legal fine print of open source licenses and the fear that a license infringement is a slippery slope that quickly leads to legal action taken against you.
Mostly Fiction: This is a matter of open source license management pure and simple. Various open source licenses allow for the use of open source components without harming your own proprietary claims.
Other types of licenses require certain retributions for the use of of their code. That is fine, right? As long as you know what you are getting yourself into. The problem, therefore, is not the requirements attached to licenses but rather that developers are not aware of the license requirements attached to the components they use.
There seems to be an unfounded fear of copyleft licenses in the open source world which mostly goes back to a gross misunderstanding of this license. While it is true that copyleft license will require a company to release their entire product, this may be an acceptable requirement for a company that believes in the power of sharing and wants to actively contribute to the open source enterprise. It is therefore not automatically a “bad” license to be feared, but rather, one to consider with respect to the open source agenda of your company.
As to the matter of the legal fine print of all open source licenses and the fear of infringement, it is worthwhile taking short walk down memory lane and recalling that no license infringements have ever led to swift legal action and few have ever gone to court. Those that have, stayed in court for many years and after long negotiations were usually settled.
#4 Open Source is an Organically Evolving Creature- Can You Really Trust a “Shifting” Code?
Another concern executives have is that the open source projects are a living, breathing, organism. They are constantly worked on, often updated and in an ongoing state of evolution. These is of course positive aspects if you are concerned with the quality of the project and the functionality of the components. And who isn’t concerned with that, right? But it is also spells out more work for developers and a greater likelihood for problems if open source components need to be updated regularly and the code is touched over and over.
Exercise Caution and the Problem Becomes Mute: While open source components can rightly be likened to living organisms and there is truth to the idea that they can mess up the rest of the code if updated too often, there are effective workarounds for such issues. This is where technology is at your service and actionable insights tools are your friend.
Actionable insights tools pinpoint paths to vulnerable components in the code. This cuts out much of the time spent roaming around the code in search of the exact part that needs fixing, which significantly minimizes potential harm caused by touching the code unnecessarily.
Combined with software composition analysis tools (SCA) that offer remediation suggestions, developers are able to get razor sharp location accuracy of the affected components and can choose from a list of remediation options an effective fix that does “touch” the rest of the code.
#5 Code that Wasn’t Written In-House is Risky
A common concern for organizations is their lack of an organizational setting to accommodate code that was written by an anonymous author, not in-house, away from the company’s watchful eye and independent of its development standards.
This anonymous author has different standards to how they write and maintain their open source project, which may or may not comply with how things are done in your organization.
For the writers in the house, you may know this from having greater hardship fixing a text that you didn’t write than writing a text yourself from scratch? This conundrum can be likened to the developer’s plight when he comes to fix code he did not write.
Not True if You Just Handle it Differently: Open source is not proprietary code and should not be treated as such. If in the case of proprietary code the solution to avoiding costly fixes would be to write good code from the start, then in open source usage the solution to having to fix someone else’s code is to choose components well from the start.
Developers need to choose high quality components to begin with. Components produced by an active community. There are basic indicators to identify how active a community is like the number of commits it gets, its fix rate, and the number of contributors it gets. It would also be wise to determine the popularity of a component before you use it; how many times it has been downloaded, the number of forks it has, etc.
Having an open source policy in place that determines exactly which open source components can enter the code and which will be rejected due to security concerns is an excellent way to automatically ensure developers are choosing well.
#6 It’s Hard to Oversee Open Source Usage
Another common consideration is that developers and security teams will not follow open source policies lest they are forced upon them. In order for open source usage to be effective and safe, a consistent and uniform set of governance policies surrounding licensing management and vulnerability detection must be put in place.
Not True: SCA tools allow users to customize an open source acceptance policy, through which you determine what level of freedom you wish to give your developers in license and vulnerability selection.
It allows executives to make security decisions on a whole and have those implemented across the board so that vulnerabilities of a certain degree and upwards or downwards of its are simply banned from entering the build. Similarly, its takes the guessing out of the license management game, indicating exactly which open source licenses it allows developers to use and which not.
Concerns Will Always Exist and So Will Solutions
Open source’s advantages to agile work environments far outweigh its disadvantages. Having become a mainstay of code development, companies in this day and age have no choice but to use open source to meet market demands.
So the concerns are there, and they may even be valid at times, but the need to overcome them is much stronger than the concerns themselves. Thankfully the tools to resolve them are available and accessible to all.
If there is one word of wisdom to impart it is that organizations are better off harnessing the power of open source and mitigating the concerns outlined above than turning a blind eye to these issues until something goes expectedly wrong.
