A Practical Guide for Reducing CVE Fatigue

Introduction

Prioritizing and mitigating software vulnerabilities is a formidable challenge for most organizations. Tens of thousands of new CVEs are discovered every year. But most organizations lack a clear understanding of which vulnerabilities are genuinely exploitable within their applications and runtime environments.

Developers waste time and effort addressing CVEs that don’t pose a legitimate threat to their applications - and their business at large. IT organizations waste time and effort patching vulnerabilities that pose no real-world risk.

Application security solutions can help organizations avoid wasted time and effort and reduce exposure by focusing on the CVEs that matter most. But not all application security solutions take the same approach to assessing risk and prioritizing CVEs.

This eBook explains the differences between traditional shift-left AppSec solutions that assess reachability and newer runtime AppSec solutions that assess exploitability.

What is Reachability Analysis?

Many “shift-left” application security solutions use reachability analysis to help security analysts and developers prioritize CVEs, improve productivity, and reduce exposure. This approach examines an application’s codebase, tracing function calls and dependencies to determine if vulnerable code is theoretically reachable (i.e., potentially called by the application.)

Reachability analysis helps developers save time and effort by deprioritizing CVEs associated with uncalled code or functions, but it is far from a perfect solution. Reachability analysis cannot conclusively determine if vulnerable code is ever called in a running application.

Developers are still overwhelmed by false positives. They still squander time and energy addressing CVEs that don’t present an actual risk to the business.

Even worse, the assessment is performed at a single point in time during development. A lot can change after that assessment is performed. Vulnerable code can be added during the build phase or even dynamically loaded during runtime, leaving applications exposed to exploitation.

Reachability Analysis Tradeoffs

What is Exploitability Analysis?

Exploitability analysis is the logical evolution of reachability analysis. Unlike reachability analysis, which is performed at a single point in time during development, exploitability analysis is performed continuously on running code during execution, typically during staging or in production. Exploitability analysis overcomes the inherent inefficiencies and constraints of reachability analysis by definitively determining whether specific functions within a library or codebase are actively invoked by an application.

Reachability analysis is performed on code repositories or within the CI/CD pipeline, but it often misses dynamically loaded code or changes during build and deployment. In contrast, exploitability analysis is performed at runtime, examining the actual running code, ensuring evidence is derived with certainty.

Modern runtime AppSec solutions leverage native kernel-level monitoring capabilities 
to assess exploitability, providing granular, real-time insights into application behavior without impairing application performance or operation.

Exploitability Analysis Tradeoffs

Reachability vs Exploitability Comparison

Best Practices for Strengthening
Your Application Security Posture

Software vulnerabilities can overwhelm development, security, and IT organizations and expose business-critical systems to attack.

Take Reachability to the Next Level
with Oligo Exploitability Analysis

Oligo goes beyond reachability, using exploitability analysis to definitively determine if a CVE presents an imminent threat to your running environment. Our innovative deep application inspection technology lets you observe the runtime behavior of every dependency in every application and system component you build, buy, or use.