As vulnerability management workloads explode in the era of increased software supply chain security risks, research published today suggests that only around 3% of current vulnerabilities are actually accessible to attackers. The data implies that if application security (appsec) professionals and developers focus on fixing and mitigating what is truly attackable, they could significantly reduce the strain on their teams.
The new study from ShiftLeft, the AppSec 2022 Progress Report, suggests that appsec and development teams can more effectively sift through vulnerabilities by focusing on “attackable” ones. Data from the report shows that developers saw a 97% reduction in false-positive library upgrade tickets once they factored in the attack when reviewing used packages with critical vulnerabilities.
If true, that would be a welcome relief to many. Managing vulnerabilities was hard enough as it is, but the added complication of third-party vulnerabilities – especially the magnitude of the impact of these vulnerabilities that reverberate across a lot of software – creates an even tougher workload that can only be managed through effective prioritization. Security and developers can only access so many vulnerabilities in so many applications in a given time period. They need to ensure that the ones they fix or mitigate with compensating controls are the ones that matter.
What does “attackability” mean for security vulnerabilities?
Determining what is attackable requires looking beyond the presence of open source dependencies with known vulnerabilities and examining how they are actually being used, says Manish Gupta, CEO of ShiftLeft.
“There are many tools that can easily find and report these vulnerabilities. However, there is a lot of noise in these results,” says Gupta. “For example, they don’t consider how the dependency is used in the application; they don’t even consider whether the application even uses the dependency.”
The idea of analyzing attackability also involves evaluating additional factors like whether the package that contains the CVE is loaded by the application, whether it is used by the application, whether the package is in a path controlled by the attacker and whether it is accessible. through data streams. In essence, this means adopting a simplified approach to threat modeling for open source vulnerabilities, with the goal of significantly reducing fire drills.
CISOs are already all too familiar with these exercises. When a new, high-profile supply chain vulnerability like Log4Shell or Spring4Shell hits industry side channels and then hits the headlines, their teams are called upon to spend long days and nights figuring out where those flaws are affecting their application portfolios, and even longer hours applying patches and mitigations to minimize risk exposure.
At this point: the report noted that 96% of Log4J’s vulnerable dependencies were not attackable.
Foreground software dependencies
Reliance on open source dependencies – both first-hand and via third-party dependencies – is increasing in modern development stacks.
“For any major application that uses a large number of dependencies, it’s common to have new CVEs several times a month,” says Gupta. “Multiply that by all the apps in the organization, you can imagine it’s not easy to keep up with all the upgrades.”
While updating a package can be easy, he says the development work associated with such a change can often be significant. Often a single library upgrade can precipitate a battery of new tests, not only for security, but also for functionality and quality, and this can potentially require code refactoring.
“Any organization serious about product quality will not ship a product without thorough testing,” he explains. “Also, library upgrades aren’t always foolproof; there is no guarantee that new versions of open source libraries will be fully backwards compatible. So sometimes teams also need to change how their app works before upgrading a library. »
Is the determination of attackability possible?
According to Mark Curphey, OWASP founder and longtime appsec advocate, the search for a prioritization model like this is nothing new. However, he says choosing the dimensions of analysis to determine what is risky or attackable can be more complicated in today’s application environment than what ShiftLeft offers.
“It is true and fair to say that the vast majority of vulnerable methods in open source libraries cannot be reached and are therefore not exploitable, but we are now in a world where open source libraries are like elaborate storefronts offering all kinds of tidbits for developers to eat,” Curphey told Dark Reading. “As an industry, we’ve recently learned from the Log4J saga that when a problem is something like a JNDI interface that not many people used actually, there were still avenues of exploitation, and so we all had to deal with the problem.”
He’s currently on a listening tour for his latest appsec startup, Crash Override, to ask what the biggest appsec issues are for CSOs today, and nearly everyone says prioritization is their #1 issue. He thinks this might just be the next big problem for appsec.
“So the fundamental premise of the report makes perfect sense, but what we also learned from the interviews is that answering this question is very difficult and more complex than ‘do I use a piece of peculiar code,” Curphey says. “These are things like business criticality, which includes how many users the system has, how much money is going through it, its public profile, what kind of data it’s processing, where it’s physically located. , and so what laws are applicable. It’s technical things like how it’s connected to other systems and what controls and monitoring and alerts are in place, and the list goes on.”
The other issue with using “attackability” or “accessibility” as a prioritization filter is understanding the underlying technical data used to determine what is accessible by an attacker, says Stephen Magill, vice president of product innovation for Sonatype.
“Attackability and ‘accessibility’ can be useful ways to prioritize vulnerabilities when the underlying vulnerability data is good. What isn’t helpful is to rely on attackability or accessibility as a way to compensate for bad vulnerability data,” says Magill. “Too often, this is what we see the industry doing: using inaccurate methods of identifying dependencies, pairing them with noisy data about which versions have vulnerable dependencies, and then using prioritization based on accessibility to filter the long list of vulnerabilities that results in something manageable.”
In other words, an attackability prioritization is only as good as the vulnerability data that feeds it, so it’s imperative that security teams really look at how they source their vulnerability data.
“Does this come from public feeds only, or is it the result of extensive research by a dedicated security team? Also investigate how dependencies are tracked,” Magill says. “Is it just the dependencies declared in the manifests or does the tool support scanning of binary artifacts, archives, JARs, etc. These questions will help you determine the quality of the prioritized results As they say, ‘garbage in, garbage out.'”
Finally, according to Magill, security managers should remember that many threats exist to software supply chains beyond the normal rolling of bugs that are accidentally discovered in open source projects.
“The biggest threats to our software supply chains are malicious and deliberate attacks on open source,” he says. “It’s a much bigger issue that we should be focusing on that has nothing to do with attackability.”