Open source code, in the forms of frameworks and libraries, continues to be very popular in development. The reason why is simple: there are too many basic building blocks for common needs. Why re-invent the wheel? If you want to use a string copy command, a data exchange service, or a date picker a pop-up calendar, there’s no need to build it from scratch. If you’re dealing with a database, there’s no need to create what a database is from scratch – pick a database platform and use it. A 2018 Gartner survey on DBMS software revealed that open source utilization could cut the costs by up to 80%. However, like all software but often overlooked with Open Source, there are two main areas which can lead to complications: licensing concerns and security concerns.
You may have heard the saying, “The devil is in the details”. The licensing agreements for Open Source are varied. There are in excess of 2,400 different licenses and the rules can be unfamiliar for those more acquainted with proprietary software. The obligations can, and often, include requirements to “make an offer” for the availability of the source code or a requirement to distribute your final product under the same license.
Unfortunately, the widely held pre-conception of Open Source is that it’s all free and you can do whatever you want. Take a second, closer inspection and you will see that the range and complexity appears overwhelming. But the effort to embrace, understand and analyze has its rewards. A well-managed Open Source strategy, adopting good-management practices, will help avoid potential issues of software ownership – fines from regulators, bad publicity, copyright infringement and potential loss of product and company value. However, by mitigating these risks and being able to demonstrate the quality steps you have taken to prospective customers, a very positive outcome can emerge.
There are around 20-30 main licenses. Unlike proprietary software, they don’t vary widely for each piece of software. Popular licenses include: MIT license, GNU General Public License (GPL 2.0), Apache License, Artistic License, Microsoft Public License and ISC License. These licenses vary from “permissive”, where the software can be used in many forms and under other licenses, to “restrictive” (also known as “copyleft”) where the license terms and the software are intrinsically linked. In other words, if you want to use that software, the license terms go with it! The idea here being that whatever you do with the software – linking, distribution, modification, patent grants, etc. – the onward innovation remains Open Source. Licensing may be varied, but is it any more complex than the multi-page EULA’s to which we are accustomed?
A common risk with modern application development is the lack of attention to security vulnerability management, which includes operational management. With 95% of all software released incorporating Open Source code and potentially 90% of that code base being represented by Open Source components, time and effort is required to manage and patch those items, just as your own code requires attention. Equifax failed to include a security patch to the open source code for Apache Struts 2 and ended up exposing personal data on over 146 million people, and a Drupal defect called DrupalGeddon2 patched in March of 2018; both allowed remote hackers to execute their own commands. Security improvements often happen during newer code versions, but will you be checking for newer releases of the open source code after your software module gets released? And how will you deal with branching if you modify your copy of the open source code before the active community modifies the base open source code?
Without proper management, you could end up with different versions of the same piece of open source code, perhaps with different in-house modifications, in different modules that your company is all using for the same integrated component. Or perhaps you may incorporate open source code that never gets updated and therefore becomes abandonware for lack of an active community’s innovation and security enhancements. If OWASP added a new danger category, your lack of a community would mean that no good Samaritans would be checking your abandonware for this vulnerability. The worst-case scenario for security risks is accidentally creating the weakest link in the security chain which allows your application to get hacked, exposing personal information and/or allowing private records to be modified. The answer is to understand your Open Source components and manage them!
Let’s look at security vulnerabilities in open source frameworks, keeping in mind that the level of detail and required functions come from different security exposures. Also, not all vulnerabilities are of equal risk (in the chart below, the CVSS score is used, where 10 is the highest and worst score possible). The bar chart below shows the number of reported security vulnerabilities (as of June 12, 2018). On the fewer-risks-found side, we have Laravel, Spring and Symfony (3, 7, and 14 respectively with no 9-or-higher CVSS scores. On the more-risks-found side, we have Apache Struts, Ruby on Rails and Drupal with 72, 78 and 176 respectively. Node.js, Django, Ruby on Rails and Drupal all have 1 9-or-higher each, while Apache Struts has 15 (that’s 0.5% really bad for Drupal, and 21% really bad for Struts).
Some vulnerabilities have even taken on celebrity status with names like Backronym, DROWN, FREAK, Ghost, Heartbleed, Logjam, POODLE and Shellshock, with each news story potentially serving as a how-to announcement for any unethical hacker, seeking to see who has or has not upgraded their open source code.
While many shortcut solutions can be found through the use of open source code, one must be aware of the risks involved, which include operational maintenance based on external events. However, in the modern application development world with the time pressure on developers, the benefits of not having to create everything from scratch will continue to make the use of open source code commonplace. With large committed communities effectively crowd testing, the quality level is high in open source code, although, like all software, security requires constant management. Your first step is to understand the software you are using. The next step is to take responsibility for it and not simply live in hope that “bad things won’t happen”. As is true everywhere, let the buyer beware, whether you’re dealing with code that is open source, proprietary, or hybrid.
