News & blog
BLOG | Don’t re-invent the wheel – But beware of the risks using Open Source

Don’t re-invent the wheel

But beware of the risks using Open Source

Author | Bryan de Vries

My previous blog (‘Low-code’ doesn’t mean ‘no-code’) discussed how low-code developers sometimes revert to using pieces of ‘regular-code’ in their apps in order to create functionality that otherwise would not be available in low-code apps. This is perfectly fine, as long as you keep an eye on the quality of this regular-code as well.

In some cases however, it may even make sense to use an existing Open Source component instead of re-inventing something yourself, regardless if you are using low-code or regular-code. The use of Open Source components can save you a lot of time and effort but, and for those of you who have read my previous blogs already know what’s coming next: beware of the risks involved!


Back to basics – What is Open Source

Open Source components are software components whose code is publicly available. Pretty much anyone is allowed to inspect, modify or enhance this code. On top, these components can be used freely by anyone as well, which obviously has numerous advantages.

As a result Open Source components are used very frequently, including in low-code environments. Some research suggests that approximately 90% of all software products contain at least one Open Source component, even if the owners aren’t aware of it. On itself, the latter is risk #1 already. Using Open Source components can be done risk-free, but the first step is to actually know what you are using in your own software products.

So, using Open Source components can have advantages. But they can also pose serious risks for anyone using them.


What are the risks?

First of all, any security vulnerabilities are public knowledge. In other words, if an Open Source component contains any security vulnerabilities, it is only a matter of time before these are known throughout the software development community. This poses a real threat as cyber criminals can exploit these vulnerabilities relatively easily.

Secondly, using Open Source components may pose a threat for your intellectual property. Open Source components can be used according to a variety of licenses. There are over 2,000 different open source license types. Examples are Apache, GPL and MIT. Some of these licenses contain so called ‘copy left’ clauses which state that whenever you use an Open Source component with this type of license, you are pretty much required to release any of your software created with the Open Source component entirely. In other words, all your intellectual property suddenly becomes open source as well. Not so nice when you have spent thousands of hours and tons of money developing a commercial product now is it?


So, what exactly is the challenge?

It isn’t so much in ‘how to use Open Source components’ but ‘how to use them properly’. Making sure your components are up to date (as this limits the threat of security vulnerabilities) and making sure you only use components with ‘non-risky’ licenses actually doesn’t sound that hard now does it?

Well, honestly… no. It sounds pretty simple and straightforward and in fact it can be, as long as you know exactly which Open Source components, versions and licenses you are using! And this is the real challenge. How do you keep track of what your developers are using in an organization that develops and maintains dozens of applications? And to make things even harder, what if these applications are built using low-code platforms such as Mendix and OutSystems? These platforms allow you to use JAVA (Maven) and C# (Nuget) Open Source components, but actually keeping track of them turns out to be quite hard. Especially as analyzing the use of Open Source components is, in most cases, not standard issue code-review functionality.


The solution

The solution to the challenge is simply to find a way to keep track of which Open Source components, versions and licenses are being used in your organization. Some organizations will ask their development teams to keep Excel lists which are updated manually. Sure, that’s one possibility, but we all know that people aren’t as good at ‘maintaining lists’ as they might believe.

So, what to do? Code-review (by Omnext) comes to the rescue!


How Omnext keeps you safe

I just mentioned that analysing the use of Open Source components isn’t ‘standard issue code-review functionality’. So how can it come to the rescue? Easy, Omnext does offer this functionality in combination with your ‘regular low-code quality monitoring’. For example, the Omnext Fit Test platform can automatically analyse which Open Source components are being used in your Mendix project. It will provide you a full list and reports which Open Source components are outdated or contain risky licenses. Last but not least it will report which Open Source components contain known security vulnerabilities.

And we haven’t even mentioned the best part: it doesn’t require any manual ‘list keeping’ at all. Whenever a new Open Source component is added to your application, the Fit Test analysis will identify it and report on it together with any Best Practice violations found in one easy to interpret online portal.


#low-code #open-source #codereview #qualityassurance


Omnext is a solution of Valori company, the number one independent quality assurance and testing consultancy organization in The Netherlands.