Effective Vulnerability Triage
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!).”
Figure 1. taken from the
webinar slides
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
interested in 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). 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 CVSS
is 3.1, which does not introduce major changes in relation to the
previous version.
The open framework CVSS contains three specific metric groups that
build an overall or complete severity report: Base, Temporal, and
Environmental.
Figure 2. taken from the
webinar slides
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, NVD “provides CVSS scores for almost
all known vulnerabilities.” And according to what we see in Figure
2, 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
of 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.
Figure 3. taken from 1zoom.me
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 ofCVSSv3.1 in our company
and present them in our Attack Resistance Management 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.
*** This is a Security Bloggers Network syndicated blog from Fluid Attacks RSS Feed authored by Felipe Ruiz. Read the original post at: https://fluidattacks.com/blog/vulns-triage-synopsys/
