Today’s time-to-market imposes high pressure on releasing new versions of your application. Productivity becomes essential. And most of the times, you will incorporate external open source components that let you build new functionality very fast and with the minimum effort.
Open Source repositories provides huge amounts of software that lets you to build new applications very fast and robustly.
But not all are benefits; there might be also some drawbacks when using open source components.
First obvious question has to do with how much open source software is your application using.
If you are a developer you most probably know the answer to this question. But if you are in a position closer to management, it’s likely that you don’t know the answer.
Modern applications, in most of the cases, are using open source components and yours will not be an exception. And, although the benefits are clear, you might be thinking of some inherent risks .
You most probably are dedicating a lot of effort to remediate security vulnerabilities in your software, but those efforts are useless if 3rd components are vulnerable. As you know, any security vulnerability makes the whole application vulnerable.
What if you are using old versions of those components? Old versions might be introducing security breaches or bugs that are solved in newer versions.
Or even worse, what would happen if those buggy components are dead, i.e. are not being evolved?
There are many 3rd party components that are “Copyleft” licensed.
In a broad sense, this kind of licenses means that, although you are allowed to use that software in your application, once you have included in your application, the whole application becomes “Copyleft” licensed, i.e. you are implicitly giving every person who receives a copy of your software permissions to reproduce, adapt, or distribute it.
Is this your intention? If don’t, you should identify all Copyleft’d components you are using in your application and act accordingly.
These, and probably others, are common questions when using 3rd party components.
If you are a developer, you most probably will access to build systems where external components are “identified”.
But, are those 3rd party components part of a “controlled” inventory? Most probably, don’t.
Supported languages and resources
Kiuwan Insights uses the following resources to extract information on 3rd party dependencies.
Supported build systems
From these sources, Kiuwan Insight builds the Components Inventory of your application.
Security, Obsolescence and Licensing
At a glance, Kiuwan Insights provides detailed information and visual indicators that quickly let you to know the different levels of risk associated to every external component.
Every component is assigned a level (High, Medium, Low or None) on three different risk metrics:
- Security Risk (due to vulnerabilities introduced by components)
- Obsolescence Risk (due to using obsolete components)
- License Risk (due to legal implications of used components’ licenses)