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.
Do you have a complete components inventory with all the 3rd party components being used by your software? |
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 .
Do you know the degree of security breaches introduced by using those 3rd party components? |
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.
Are those components obsolete? You might be using “outdated” components or, even worse, “dead” components.. |
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?
Are you aware of legal licensing implications of using those 3rd party components? |
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.
Kiuwan Insights comes to answer all these questions by providing:
|
At a glance, Kiuwan Insights provides 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:
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.
Kiuwan Insight analyzes your application software, discovering all external dependencies, and builds a Components Inventory that lets you track of any external piece of code that could be part of your application. |
Kiuwan Insights uses the following resources to extract information on 3rd party dependencies.
Supported languages | Supported repositories | Supported build systems |
Java |
|
|
Javascript |
|
|
.Net |
|
|
Python |
|
|
Swift |
|
|
Php |
|
|
From these sources, Kiuwan Insight builds the Components Inventory of your application.
Components Inventory is accessible trough Insights >> Components tab. |
Insight >> Components tab displays Components Inventory:
Kiuwan Insights provides a full listing of all those components being used by your application.
For every 3rd party component, you will have access to detailed component information such as:
A component’s Security Risk is based on CVSS v2 Base Scores (Severities) of its vulnerabilities:
|
Please visit XXXXXXXXXXXXXXXXX for further information on CVSS v2 Base Scores (Severities) of vulnerabilities.
A component’s Obsolescence Risk is a measure of the risk level relative to:
Both values are combined in the Obsolescence Risk to provide a value of the risk associated to using outdated or “dead” components. |
Please visit XXXXXXXXXXXXXXXXX for further information on Obsolescence.
A component’s License Risk is a measure of the risk level relative to legal implications of used components’ licenses. |
Please visit XXXXXXXXXXXXXXXXX for further information on Licenses.
By clicking on a component, you will have access to the following information:
With Kiuwan Insights you can identify different versions of the same component used by your application. |
Below example shows that the analyzed application is incorporating two different version of ZKoss common library: 8.0.1 and 6.0.0
Most probably, this component duplication is not intended, and it’s something that would produce maintainability headaches when upgrading to a newer version of the library.
Information on components’ Security is accessible through Insights >> Security tab.
Insights >> Security displays security information on vulnerabilities found in components.
With Kiuwan Insights you can easily detect those components that have well-known security vulnerabilities.
For every external component, Kiuwan Insights searches for vulnerabilities reported to NIST‘s National Vulnerability Database (NVD) (https://nvd.nist.gov/)
If Kiuwan finds any reported vulnerability of your component, it will display the details of the vulnerability and score the component in a Security Risk indicator.
A component’s Security Risk is based on CVSS v2 Base Scores (Severities) of its vulnerabilities:
For example, let’s suppose your app is using Struts TagLib 1.3.8. Kiuwan will display next information:
Struts TagLib 1.3.8 has 4 known vulnerabilities, three are considered as Medium and one as High. Therefore, Kiuwan will mark Struts TagLib 1.3.8 as High.
Security Risk indicator of a component is displayed as a label based on its numeric value (from 0 to 10):
Security Risk Indicator | |
Value | Label |
0 |  |
( 0 , 4 ] | |
( 4 , 7 ] |  |
( 7, 10 ] |  |
For every vulnerability, CVSS v2 provides an overall Base Score that “represents the intrinsic and fundamental characteristics of a vulnerability that are constant over time and user environments” (https://www.first.org/cvss/v2/guide) |
Base Score is based on two main characteristics (modeled as Subscores) of any vulnerability (with associated metrics):
Base Score, as well as Exploitability and Impact subscores, are displayed as a numeric range from 0 to 10, with associated color based on its importance ( “the higher, the worst” ) |
CVSS v2 Scores | |
Value | Label |
[ 0 , 4 ] |  |
( 4 , 7 ] |  |
( 7, 10 ] |  |
Kiuwan Insights provides a 2-axis figure that can help you to easily understand these two important characteristics of the vulnerability.
Base Score is calculated as a function of Exploitability and Impact Subscores. Exploitability and Impact subscores are calculated from their associated metrics. |
Kiuwan Insights displays the value for every subcore’s metric.
Below you can find the meaning for every metric but, as a rule of thumb, you can consider that the more left is the value of the metric, the more dangerous is the vulnerability.
Let’s understand the meaning of every metric.
Values of above metrics are combined to calculate CVSS v2 Base Score and Exploitability / Impact Subscores as described at https://nvd.nist.gov/vuln-metrics/cvss/v2-calculator
CVSS v2 has evolved to v3 (https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator) introducing changes to metrics (new metrics and different possible values).
However, not all vulnerabilities reported to NIST‘s National Vulnerability Database (NVD) have been scored according to v3 guidelines. Indeed, only a subset of them has been re-scored.
Because of this, although Kiuwan Insights displays v3 data (when available), only v2 data will be used when computing components’ Security Risk indicator.
NIST database is continuously being feed with new vulnerabilities.
What happens if, after the date you run the analysis, new vulnerabilities are found that affect some of your components?
Don’t care. Kiuwan Insights is continuously inspecting NIST database for new vulnerabilities. If there are new vulnerabilities that affect some of the components of your app, those components will display those new vulnerabilities (marked as New) without the need to run a new analysis.
Kiuwan will keep your components inventory up-to-date without the need to run new anlyses. |
