For many years, traditional Software Composition Analysis (SCA) tools have been the go-to for dealing with vulnerabilities in open source packages. They allow you to track and analyze the open source packages in your applications, their direct and indirect dependencies, and detect vulnerabilities. While that information is valuable, they cannot prioritize the vulnerabilities, because they have no real context. As a result, SCA tools cannot help you understand the relative severity of each open source package vulnerability they discover in your applications, so you may be presented with a long list of vulnerabilities, with no idea where to begin remediation. At the minimum, it’s annoying and time-consuming. At its worst, it could be downright crippling, even bordering on catastrophic.
The ‘Log4shell’ vulnerability in the commonly used log4j package was described as “the most serious vulnerability that I’ve seen in my decades-long career” by the director of the United States Cybersecurity and Infrastructure Security Agency (CISA), Jen Easterly. Its ubiquity represented a major challenge for organizations, but what posed an even greater challenge was the fact that the majority of the tens of thousands of Java artifacts (the Java ecosystem’s term for packages) that used the log4j library pulled it in as an indirect dependency - i.e. a dependency of one of its dependencies.
To compound matters, the majority of dependencies were 3 layers deep or more, with some as deep as 9 layers. This meant that organizations that originally thought that they either didn’t have any instance of log4j in their applications, or who thought that they had a good handle on all the instances of the vulnerability in their applications, later discovered that they had a lot more than they originally thought. This is because other packages that they used had an indirect dependency on log4j, sometimes multiple layers deep. A mad scramble ensued to patch these instances of the library, but everyone struggled to identify which ones to tackle first, as there was no easy way to determine what was most important. SCA tools fell short here, as they have no way of providing context on each instance of the vulnerability and what the relative risk of each instance was.
%201.png)
When we first set out to develop our cloud native application security platform, log4j was not yet in the public consciousness, and the White House Executive Order on Improving the Nation’s Cybersecurity, where the requirement for SBOMs for applications used by Federal agencies, had not yet been released. But we understood that the use of open source packages in applications was growing, and that there was a corresponding increase in the number of open source vulnerabilities, all of which contribute to supply chain risks, which have become a critical priority for organizations. These trends combined shone a spotlight on the need for a better way to identify and rank vulnerabilities in open source packages so that there’s a more data-driven approach to vulnerability remediation that would focus on the most critical severities first.
SCA tools identify vulnerabilities in open source packages using a two-step process:
Unfortunately, that is the extent of the meaningful information that SCA tools provide for remediation - a list of vulnerable packages in your code base.
When your appsec and development teams are faced with the need to find and patch open source vulnerabilities, it’s absolutely imperative that you prioritize the most critical ones. After all, your dev team's primary responsibility is to build products, and it shouldn’t be forced to spend valuable time triaging in search of the right vulnerabilities to patch. But the tools available to appsec teams haven’t been able to remove this burden from them, until now.
One of the benefits of Oxeye’s application security platform for cloud native applications is our ability to gather data that puts open source vulnerabilities into context. Since Oxeye’s platform analyzes code statically and at runtime, we know if an open source package is installed, is loaded into memory, and is used during runtime. Eventually, our analysis puts the packages in your applications into one of these three buckets:
This forms the first layer of our analysis, which we then combine with other factors such as infrastructure configuration data and applicative flow analysis to eventually provide a severity ranking, as shown in the screenshot of our dashboard below.
In this example, there are two instances of the vulnerable log4j package in this application. However, one is ranked with a severity level of ‘Critical’, while the other is ‘Low’. When we examine the details of each instance, we can see that this difference is due to the fact that the ‘Critical’ instance is loaded and in-use, is accessible from the Internet, sits within a privileged container (giving it access to all the capabilities on the host) and shares resources with the host.
%201.png)
When we examine the other instance of the same vulnerability, we can see that it’s not loaded into memory, and is not accessible from the Internet. While it remains a vulnerability, it’s not at the same level of severity as the previous instance.
When your team is allocating resources for remediation, it’s immediately clear what takes precedence in this example. To add richness to the analysis, we show you the path through which the package was accessed, as shown in the graphic below. For development teams, knowing what to prioritize allows you to focus on what requires remediation right away, while for security teams, seeing the full picture enables you to better assess the entire application’s risk.
With Oxeye’s cloud native application security solution, application security and R&D teams finally have a single, indisputable source of information that clearly shows what matters most when it comes to open source vulnerabilities. Your appsec and dev teams can now work more collaboratively and cohesively to tackle the task of remediating open source package vulnerabilities, instead of wasting time trying to figure out where to even begin.
