Here at the beginning, we give you the link for the Synopsys' webinar.
As Dale Gardner pointed out in November of last year: "Open-source software is increasingly used by development teams to support their applications." Also, Gardner expressed later: "In most modern DevOps development projects, the majority of code used in an application is made up of open source —with the remaining code largely serving as 'glue' to assemble and invoke the various functions."
The presence of open source components in modern apps has grown enormously. Thus, the number of customers and the number of developers using Open Source Software (OSS) has increased. However, these increases have gone hand in hand with the growth of certain concerns. The more OSS is used, the more vulnerabilities are discovered and reported.
The reported vulnerabilities, as Jeff Michael told us, have increased dramatically, especially in the last three years. As Shandra Gemmiti, also from Synopsys, share with us, there are "more than 16,000 open source vulnerabilities disclosed each year (that’s more than 40 per day!)."
There are hundreds of thousands of vulnerabilities, according to the authors of the webinar, which today constitute what they call a "Sea of Vulnerabilities."
It is in the face of this sea of vulnerabilities that many of us who are
OSS have to cope in the best possible way. It becomes
essential that we understand what open source components we are using in
our infrastructures and apps. It is crucial, therefore, that we are
clear about the potential risks with the vulnerabilities that are
present, and that we know how to manage them effectively.
A decisive aspect in the effective management of vulnerabilities is prioritization or triage —concept, the latter, borrowed from medicine. Thus, as with medical treatment of patients according to the severity of their condition, the promptness of remediation of vulnerabilities will depend on the severity of those vulnerabilities. Vulnerabilities have to be rated and classified, or instead defined as more or less important.
Thus, many can be guided by the methodology of focusing first on vulnerabilities classified as critical. This method can sometimes be an effective way of handling the situation. But as the authors of the webinar suggest, the act of understanding vulnerabilities and their different attributes and impact is fundamental.
The severity of software vulnerabilities is usually calculated with the
Common Vulnerability Scoring System
CVSS is an international
standard that delivers quantitative measures from 0 to 10
according to the qualitative characteristics of the vulnerabilities.
0 corresponds to the lowest level of severity and risk while 10
is the highest and most critical level. The latest version of the
is 3.1, which does not introduce major changes in relation to the
The open framework
CVSS contains three specific metric groups that
build an overall or complete severity report: Base, Temporal, and
When we visit the
NVD website (which we had
already mentioned within the Rules standards),
precisely where they talk about
CVSS, we find some relevant
information to deal with. It turns out that the score ranging from 0
to 10 produced by the Base metrics can be later modified by the
scores of the other metrics.
As they tell us right there,
CVSS scores for almost
all known vulnerabilities." And according to what we see in Figure
NVD delivers Base scores and not Temporal or Environmental
scores. The Temporal metrics are described as "metrics that change over
time due to events external to the vulnerability." The Environmental
metrics, meanwhile, are understood as "scores customized to reflect the
impact of the vulnerability on your organization."
As the authors share with us in the webinar, using only the Base metrics
NVD, as some vendors do, may not be the best, as only a small
portion of the entire framework is being used.
At Synopsys, specifically for Black Duck —their
SCA product—, they do
their scoring. That scoring is the
BDSA we see in Figure 2.
BDSA, which means Black Duck Security Advisories, delivers Temporal
metrics in addition to the Base metrics. These Temporal metrics
consider, for the vulnerability in analysis, for example, if this
vulnerability itself is confirmed, if an exploit is accessible, and if
there is an official fix available.
These are important additional data points that can modify the severity scores of the vulnerabilities. Jeff and Chris tell us that "BDSA Scoring is based on facts." Environmental metrics then add to those data points and provide some understanding of the apps in which the vulnerabilities are identified. They also offer comprehension about the contexts in which those apps are running.
CVSS can sometimes be quite controversial as it depends on the
analyst’s interpretations. Thus, at Black Duck, they report, they have
robust internal processes and manual checks of available information on
vulnerabilities. Their team conducts in-depth analysis and research for
the accurate representation of vulnerabilities, their attributes, and
their severity in certain apps.
In addition, their scoring decisions are supported by:
"Peer Review and comprehensive onboarding processes."
"Scoring policies that provide clarification where ambiguities exist in first.org guidelines."
"Decision-making flowcharts that assist with scoring common vulnerabilities."
Moreover, the customer has the possibility to create within Black Duck some "policy rules." These serve as a guide for her to define the specific conditions she wants to flag when there are particular vulnerabilities in certain apps. With all this, it is expected that the customer will have enough relevant information for the optimization of the remediation efforts.
The aforementioned is clear to us at Fluid Attacks. We use those same Temporal metrics of CVSSv3.1 in our company and present them in our platform (see Figure 4).
Figure 4. an example of (Base and Temporal) metrics in Integrates
If you want to know more about it, and how we check vulnerabilities in your software's open-source dependencies while you develop, helping you implement DevSecOps, we invite you to contact us.
Recommended blog posts
You might be interested in the following related posts.
Watch out for keylogging/keyloggers
There's not an only way but here's a good one
Benefits and risks of these increasingly used programs
A hacker's view of the performance of Researcher CNAs
Why so many are switching to Rust
Description and critique of CEH certifications
An OffSec Experienced Pentester review
Or what makes the ethical hacker