Introducing “Attacker Reachability”: Reduce open-source vulnerability tickets by 90% or more.

Introducing “Attacker Reachability”: Reducing open-source vulnerability tickets by 90% or more.

Tl;dr; ShiftLeft is announcing Intelligent SCA that uses a four-step process to prioritize vulnerabilities that matter. ShiftLeft Intelligent SCA introduces the concept of “Attacker Reachability” to prioritize only a subset of OSS vulnerabilities for mitigation. Based on testing conducted against a commercial SCA solution, Intelligent SCA reduced open source vulnerability tickets by 93%. Intelligent SCA is available at no additional cost as part of ShiftLeft Code Security Platform — ShiftLeft CORE. You can try ShiftLeft CORE for free here.

Our customers have repeatedly communicated a desire to deliver secure software without compromising software delivery timelines.

However, they have frequently reported that traditional software composition analysis (SCA) tools create an overwhelming number of open source vulnerability tickets.

In a recent experiment that we carried out between Dec 2020 and March 2021 with some of our customers/users, we found that analysis of just 49 apps resulted in the discovery of 2761 OSS vulnerabilities spread across 718 vulnerable packages.

These were 2761 potential tickets for developers to mitigate. Most were eventually found to have no impact and therefore should be a low priority!

By any measure, rather than helping developers, these solutions are slowing them down.“ShiftLeft Intelligent SCA” changes this by delivering on security AND productivity.

Intelligent Software Composition Analysis

ShiftLeft CORE platform introduces a new offering aptly named Intelligent SCA

ShiftLeft’s Intelligent Software Composition Analysis

ShiftLeft Intelligent SCA uses a four-step process to prioritize an open source vulnerabilities

ShiftLeft Intelligent SCA

This reverse funnel filters out vulnerabilities that do not matter.

What is “Attacker Reachability”?

If an attacker-controlled path exists that connects an insecure application input to a CVE in a third-party library/package contained in the same application, then this CVE (open source vulnerability) will have “Attacker Reachability” in that app.

In turn, an attacker-controlled path is determined by tracing an application’s public inputs (or sources) to sensitive sinks (db, log, http, etc.), lacking any validation or sanitization routine between these sources, sinks. The analysis of the application is critical to identify Attacker Reachability. Any SCA solution that does not analyze the application and limits its analysis to merely the list of dependencies used by the application cannot conduct this analysis

Attacker Reachability powered through Code Property Graph

ShiftLeft’s core innovation of Code Property Graph powers this concept of “Attacker Reachability”!

How does Code Property Graph determine “Attacker Reachability”?

ShiftLeft CORE delivers all of its constituent analysis through the same Code Property Graph whether it is identifying code vulnerabilities, OSS vulnerabilities, secrets, or security insights.

How does the ShiftLeft CORE platform works?

However, the analysis always starts with the construction of the Code Property Graph.

Code Property Graph has an innate understanding of code components and their inter-relationships. This Code Property Graph contains all the information it needs to identify “Attacker Reachability.” It knows the call graphs that connect application inputs to its sensitive sinks. It also has graphed relationships of dependent components and their relationship to application code.

However, there is something more fundamental to all of this. What makes Code Property Graph more powerful than any other rudimentary call graphing technology, that it is a singular representation of multiple constructs stitched into one whole.

A Graph of Graphs

E.g., Code Property Graph can not only determine the simple call graph relationships between parts of code, but it can also combine it with the power of control and data flow analysis to avoid the most common false negative scenarios.

Reachability analysis in action — as Code Property Graph sees it.

Let us take an example of a simple program call sequence for an application.

PS:- This example uses a simplified example to illustrate the concept.

Sample call sequence

In the above example, we have a call sequence from an unsecured public input A. It further goes from A → B, does a data transform at B, branches at C with the conditional flow (C →D, C →E, C →F), with C → F being a package control condition. D and E’s path passes through OSS with CVE/s and from F through OSS without CVE, and all paths ending at G.

Basic call graph

Now for a basic call graph analysis (something used by a couple of open-source vulnerability vendors), its visibility for this call sequence will be limited (A →B) on account of their blindness to data transformations happening in step 2, which is a very likely under-estimation case where a likely attacker’s reachable path was discarded.

Now let us see a case with data transformation visibility but without control flow awareness.

Call graph with data transformation visibility but without control flow awareness

In the case above, we have a taint-aware call graph (basic data flow visibility), so it is able to trace out all of the potential paths from A to open-source packages. However, it is not aware that a condition at C provides F as a safe call path to reach G. Neither is it aware of a sanitization function at D making a path through D non-viable for an attacker. In this case, it makes both errors — over-estimation and under-estimation of attacker reachable paths.

Now, let us see how Code Property Graph will visualize this.

How CPG visualizes all of this?

With Code Property Graph and its full power on display, it will have no problem figuring out the entire code path sequence and the fact that path C → D and C → F are non-viable on account of data sanitization route and safe package control flow conditions.

It will have a higher fidelity in identifying “attacker reachable” paths as A → B →C→E and avoid both over-estimating and under-estimating “attacker reachable” paths.

Evaluating ShiftLeft Intelligent SCA with real-world applications

As discussed earlier in the blog, we subjected 49 customer/users’ apps using a commercial SCA solution, and we identified 2761 potential OSS vulnerability tickets across 718 vulnerable packages.

As a follow-up step, we subjected these same apps now through ShiftLeft’s Intelligent software composition analysis. Here is what we found.

Introducing a new OSS vulnerability mitigation option — “Eliminate Reachability”

ShiftLeft Intelligent SCA introduces a new option for mitigating OSS vulnerabilities.

For OSS vulnerabilities that are “attacker reachable”, a developer could either upgrade the package in question OR simply mute the impact of this vulnerability by eliminating reachable paths.

This option is specifically very useful if 1) there is no available upgrade package and 2) if it is not easily possible to change the current version of the package.

TL/DR: Why ShiftLeft for prioritizing open-source vulnerabilities?

ShiftLeft has many distinct advantages over any other vendor technologies to solve open-source vulnerabilities issues.

Of foremost importance is the ShiftLeft’s Code Property Graph and its maturity in discovering critical paths achieved over many years of refinement, as demonstrated by its high level of accuracy in the OWASP Benchmark.

ShiftLeft CORE has a free version for you to try out here:

Introducing “Attacker Reachability”: Reduce open-source vulnerability tickets by 90% or more. was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog – Medium authored by Alok Shukla. Read the original post at:—-86a4f941c7da—4