Katie Teitler-Santullo
In today’s cybersecurity landscape, managing vulnerabilities is more complex than ever. As the number of reported vulnerabilities continues to grow, it’s crucial to understand which vulnerabilities pose real threats and which are mere nuisances. This article explores several key concepts that impact software vulnerability management, from the importance of reachability analysis to the pros and cons of different security approaches.
The Challenge of Security Vulnerability Overload
Nearly 60% of all reported vulnerabilities are tagged as “high” or “critical,” leaving AppSec and DevOps teams overwhelmed. With the average organization dealing with nearly 120,00 alerts, how can teams even begin to address these “high-severity” vulnerabilities in any kind of systematic and business-impacting manner?
The bad news is that they can’t. The good news is that these ratings — often based on the National Vulnerability Database (NVD) scores — don’t necessarily reflect real-world risk or applicability. The NVD’s base score provides a starting point for assessing a vulnerability’s severity, but it’s not the whole picture. Unfortunately, many security tools are tuned to interpret CVE scores as definitive, which leads to an unnecessary focus on low-level issues and a backlog of vulnerabilities that may not actually be exploitable.
Why Common Vulnerability Scoring Models Fall Short
The Common Vulnerability Scoring System (CVSS) has become a go-to method for assigning severity to vulnerabilities. But CVSS was never intended to be the final word in software vulnerability analysis; the CVSS was always intended to be a starting point for organizations to dig deeper and determine their individual exposure to threats. However, with the unmanageable number of alerts and additional pressures put on security and development teams today, practitioners have had to resort to the simplest method of triaging alerts — using the CVSS as the basis for investigation.
Unfortunately, the simplest method is far from the best or most accurate method. Not all reported vulnerabilities are meaningful threats; some have almost zero likelihood of exploitation. What this means is that when security teams and developers are assigned to alert triage based on generic information (like the CVSS), they are doomed to waste inordinate amounts of time chasing irrelevant-to-them vulnerabilities, which only causes frustration and production delays.
As was the original intent of the CVSS, teams need to go further in their vulnerability analysis and incorporate:
- Reachability: Just because a vulnerability exists in a codebase doesn’t mean it can be exploited. For a vulnerability to pose a real risk, it must be reachable — accessible through the code, an API, or some other part of the exploitation chain. If the vulnerable code isn’t used in the application, the risk is minimal.
- Exploitability: Not all vulnerabilities in a module apply to every use case. Most vulnerabilities (especially those that are open-source) only affect specific parts of a module. If an application doesn’t use the affected part, the vulnerability isn’t a threat.
If you’re reading this blog and thinking, “Great, now I have to learn how to do a new type of analysis that will put me even farther behind,” don’t fear! Automation is your best friend when it comes to analyzing software vulnerabilities, and the right tools and processes already incorporate reachability and exploitability analyses.
Beyond CVSS: The Role of Reachability Analysis
Reachability analysis offers a more effective approach to software vulnerability prioritization by helping teams focus on whether a vulnerability is truly accessible in the context of specified code. This analysis goes beyond basic flagging of potential vulnerabilities based on known issues and assesses whether vulnerabilities can be triggered — not just if the vulnerability exists. Only when the condition for a trigger is met will the vulnerability be labeled as “high” or “critical,” allowing AppSec and DevOps teams to address genuine risks rather than theoretical ones. This approach substantively positively impacts risk posture since vulnerabilities of lesser importance are deprioritized in favor of more urgent risks.
Different tools and processes offer various ways to implement reachability analysis. Some use dynamic analysis, which involves monitoring the runtime environment to see whether vulnerabilities are accessed or exploited during execution. However, dynamic analysis requires an agent to be installed on the runtime environment, which can introduce its own risks and complexity.
On the other hand, static analysis involves examining the source code itself, providing a comprehensive snapshot of potential vulnerabilities before deployment. This method is simpler to deploy and doesn’t require additional runtime agents, but it can miss vulnerabilities introduced or triggered during runtime. This is why it’s important to incorporate both methods into the AppSec program
Choosing the Right Tools and Approaches
When it comes to software risk analysis, there is no one-size-fits-all solution. Adopting a comprehensive approach that focuses on vulnerabilities’ actual relevance and exploitability is the preferred way to manage real risk in software environments. Traditional tools and approaches to software analysis include:
- Static Analysis (SAST): Offers simplicity in deployment and provides a broad overview of potential vulnerabilities by scanning the entire source code. Ideal for pre-production environments but may miss runtime-specific vulnerabilities.
- Dynamic Analysis (DAST): Provides more granular insights by examining vulnerabilities as they occur in the runtime environment. However, it requires installing an agent, which could pose a security risk or impact performance.
At OX, we recommend going beyond traditional application security testing (AST) and using a combined approach that incorporates static analysis for comprehensive pre-production scanning and dynamic analysis to catch runtime-specific issues.
Yet, AST is only a small piece of the software security puzzle. Organizations will greatly benefit from holistic risk management across the software development lifecycle (SDLC). This requires building a program that connects multiple tools and processes that can help assess the security posture of applications throughout every stage, from build to runtime. Practically, this means connecting SAST and DAST (of course), and also including software composition analysis (SCA), SBOM, artifact and secret scanning, environmental analysis (Cloud, container, pipeline), infrastructure-as-code (IaC), and more to understand what vulnerabilities exist and where they exist throughout the pipeline.
Organizations should not simply stop at surfacing vulnerabilities, though (as is the purpose of this post). It is incredibly important — for the reasons stated above — to ensure that the chosen tools provide, or the organization using the tools can supplement with, reachability and exploitability analysis to layer on top of scanning to provide an accurate, actionable, and effective approach to software vulnerability management.
Conclusion: Evolving to Meet Current Software Security Challenges
As the software landscape becomes more complex, security teams must evolve their strategies to focus on what truly matters. AppSec and DevOps teams must understand the limitations of traditional scoring models and adopt reachability analysis to better prioritize vulnerabilities, reduce noise, and enhance overall security posture. Doing so will result in fewer hours wasted on low-impact issues and more focus on what matters — maintaining a strong application security posture and ensuring low organizational risk.
Try OX for free
