With vulnerability-management workloads increasing in an era of increased software supply chain security risks, a new study suggests that only about 3% of today’s flaws are actually reachable by attackers. According to the data, if application security (appsec) professionals and developers work together to fix and mitigate what is truly attackable, they can drastically reduce the strain on their teams.
The 2022 AppSec Progress Report from ShiftLeft suggests that appsec and development teams can more effectively sift through vulnerabilities by focusing on the “attackable” ones. According to the report’s findings, developers saw a 97 percent reduction in false-positive library upgrade tickets after taking attackability into account when examining packages in use with critically rated vulnerabilities.
Many people would be relieved if this were true. Vulnerability management is difficult enough as it is, but the addition of third-party flaws — particularly the scale of impact of these vulnerabilities reverberating across multiple pieces of software — creates an even more daunting workload that can only be managed through effective prioritisation. Security and developers can only address so many vulnerabilities in so many applications in such a short period of time. They must ensure that the ones they repair or mitigate with compensating controls are the ones that matter.
According to Manish Gupta, CEO of ShiftLeft, determining what’s attackable requires looking beyond the presence of open source dependencies with known vulnerabilities and examining how they’re actually used.
“There are many tools out there that can easily find and report on these vulnerabilities. However, there is a lot of noise in these findings,” Gupta says. “For example, they do not consider how the dependency is used in the application; they don’t even consider whether the app even uses the dependency.”
Analyzing for attackability also entails determining whether the CVE-containing package is loaded by the application, whether it is in use by the application, whether the package is in an attacker-controlled path, and whether it is reachable via data flows. In essence, it means approaching open source vulnerabilities with a simplified threat modelling approach, with the goal of drastically reducing fire drills.
These drills are already all too familiar to CISOs. When a new high-profile supply chain vulnerability, such as Log4Shell or Spring4Shell, hits the industry back channels and then makes headlines, their teams are called to work long days and nights determining how these flaws affect their application portfolios, and even longer hours applying fixes and mitigations to minimise risk exposures.
Modern development stacks are increasingly reliant on open source dependencies, both directly and through third-party dependencies. While updating a package may be simple, the associated development work can often be significant, according to him. A single library upgrade can frequently trigger a slew of new tests, not just for security but also for functionality and quality, and it may necessitate code refactoring.
Seeking a prioritisation model like this, according to Mark Curphey, founder of OWASP and a longtime appsec advocate, is nothing new. However, he claims that in today’s application environment, selecting the dimensions of analysis to determine what’s risky or attackable can be more difficult than ShiftLeft proposes.
Another issue with using “attackability” or “reachability” as a prioritisation filter is understanding the underlying technical data that is used to determine what is reachable by an attacker, according to Stephen Magill, Sonatype’s vice president of product innovation. In other words, an attackability prioritisation is only as good as the vulnerability data that feeds into it, so security teams must exercise caution when sourcing vulnerability data.
“Does it only come from public feeds, or is it the result of in-depth research by a dedicated security team? Also investigate how dependencies are tracked,” Magill says. “Are they just the declared dependencies in manifest files or does the tool support analysis of binary artifacts, archives, JARs, etc. These questions will help you determine the quality of the findings being prioritized. As they say ‘garbage in, garbage out.'”
