Glossary

What is Reachability Analysis?

“Reachability analysis cuts through vulnerability noise, prioritizing exploitable vulnerabilities for faster & secure software development. By analyzing reachable code and exploit paths, reachability analysis saves resources and drives robust security.”

As software development scales, the need to secure code and ensure it is reliable and robust grows as well. One of the significant security risks is vulnerabilities, accidental weaknesses in software code or dependencies. SCA (Software Composition Analysis) is a valuable solution for identifying vulnerabilities. However, it can drown development and security teams in endless lists of issues, many of which pose no immediate threat. The result? Wasted time, diverted resources and a slower development cycle.

Reachability Analysis

This is where reachability analysis comes in. Reachability analysis focuses on vulnerabilities that are actively exploitable in real-world scenarios, allowing organizations to cut through the noise and focus on what truly matters. This helps build more secure applications, fosters DevSec trust and builds cyber resilience. Let’s dive into this topic.

What are Software Vulnerabilities?

Vulnerabilities are weaknesses or flaws in a system, application, network, or process that can potentially be exploited by attackers to compromise the system’s confidentiality, integrity, or availability. This is opposed to malware, which is a threat that attackers are intentionally using for malicious activity

Software vulnerabilities can arise from various sources, such as coding errors, misconfigurations, outdated software, vulnerable dependencies, or inherent design flaws. If and when exploited, vulnerabilities can lead to data breaches, system compromise, service disruption, reputational damage and financial loss.

What is SCA?

Software Composition Analysis (SCA) is a method used to identify, prioritize and mitigate risks associated with open-source components within software applications. These risks include security vulnerabilities, malicious code and licensing issues. By analyzing the composition of software, SCA helps organizations understand and manage the potential threats arising from the use of third-party and open-source libraries.

What is the Challenge of SCA?

The primary challenge of Software Composition Analysis (SCA) lies in effectively prioritizing vulnerabilities while minimizing developer noise. SCA tools often generate extensive lists of potential issues, many of which may not directly impact the application’s security or functionality. This can overwhelm development teams, diverting their focus from critical vulnerabilities to low-priority or non-exploitable issues.

This is where reachability analysis comes on. Let’s explore the reachability analysis definition and reachability analysis meaning.

Advanced Reachability Analysis | Exploitable Path Discovery

Cut through the alert noise, manage fewer tools, and speed up vulnerability fixes

Checkmarx’ game-changing capability, Exploitable Path, can enhance your security posture by analyzing the reachability of vulnerable code, ultimately cutting through the noise to deliver precise, actionable insights.

Discover more

What is Reachability Analysis?

Reachability analysis of vulnerabilities is a security method that identifies and prioritizes vulnerable code in an application’s code, including third-party dependencies (e.g., open-source packages) and container images, which can potentially be called (executed) when the application is running, thus exposing the application to possible cyberattacks.

Not all vulnerabilities in a system are equally exploitable. So reachability analysis’s sweet spot is by highlighting the vulnerabilities that are potentially exploitable when the application is published (versus other vulnerabilities that are not being currently called by the application and are thus not currently exploitable).

By understanding reachability analysis, organizations can focus remediation efforts and resources on vulnerabilities that are most likely to be used in an attack. This is the most cost-effective way to strengthen the security posture. This approach is aligned with agile and DevSecOps practices, by ensuring developers focus on vulnerabilities that risk the application, so they can maintain a high development velocity. In addition, reachability analysis can support incident response efforts and help meet compliance regulations. 

How Reachability Analysis Works

Step 1 – Identification of Vulnerabilities – The process starts by pinpointing known vulnerabilities in the system, often using vulnerability scanners or security assessments. This includes mapping vulnerabilities in the dependencies used by the system, like software libraries, modules, or services that are indirectly used by the system.

Step 2 – Evaluation of the Attack Surface – Mapping which parts of code are being called at runtime, whether they are vulnerable or not.

Step 3 – Exploit Path Analysis – Determining exploitability by understanding which vulnerable code (classes or functions), including dependency code or container images, may be called at runtime.

For example, which dependencies (third-party packages/libraries) in the application are being called at all. If code isn’t in use, or the code is in use but the vulnerable excerpt isn’t, it would be inefficient to fix these vulnerabilities from a resource perspective.

Certain vendors also scan and analyze the source code of dependencies of dependencies, to an unlimited traversal depth (this is called transitive dependency scanning), to identify any calls to vulnerable code.

Step 4 – Reporting – Presenting the results to users in a way that makes it easy for them to prioritize remediation efforts.

The Benefits of Reachability Analysis

  • Lets security teams and engineering teams concentrate their limited time, effort, and resources on addressing vulnerabilities that attackers are most likely to exploit.
  • Cuts through the overwhelming number of vulnerabilities identified by traditional scanners by highlighting only those that matter.
  • Minimizes the system’s exposure to potential attacks.
  • Allows organizations to identify and address gaps in security controls and add safeguards.
  • Helps identify attack pathways during a real incident, helping understand the attack and enabling quicker containment and remediation.
  • Supports regulatory frameworks that require organizations to assess and address vulnerabilities.
  • Helps demonstrate a measurable reduction in risk exposure to the board.
  • Drives collaboration between engineers, AppSec and IT, since everyone gets a shared understanding of critical risks, fostering better decision-making.
  • Helps organizations prepare for zero-day attacks.

Reachability Analysis Best Practices

  1. Leverage automations – Use automated vulnerability scanning tools (e.g. ASPMs) to identify potential issues across the application.
  2. Don’t neglect dependencies – Include third-party dependencies, APIs, and external integrations in the scanning process. Preferably, scan and prioritize dependencies of dependencies of dependencies (and so on) to ensure comprehensive protection.
  3. Ensure tools are up-to-date – Choose a vendor that has access to updated vulnerability databases and threat intelligence feeds and possesses internal research resources, to make sure as many vulnerabilities as possible are identified.
  4. Understand application context – Assess how vulnerabilities fit within the specific application’s architecture, including authentication and access controls, user input flows and dependency usage.
  5. Prioritize risks – Prioritize based on which vulnerabilities can be called at runtime, potential impact and feasibility. Ignore unused or dormant code that doesn’t affect the current application workflow.
  6. Developer feedback – Once a vulnerability has been identified and prioritized, provide developers with actionable feedback directly within their development environment.
  7. Continuously monitor and update – New deployments, configuration changes, or updates can alter the reachability of vulnerabilities. Regularly reassess exploitability, preferably with integrations into CI/CD pipelines.
  8. Foster collaboration between teams:
  • Developers: Use reachability insights to focus on high-priority fixes during development cycles.
  • Security Teams: Understand the application context to accurately assess and communicate risks.
  • Operations Teams: Adjust configurations or apply compensating controls (e.g., firewall rules) to mitigate reachable vulnerabilities.

Checkmarx Reachability Analysis

Checkmarx offers a comprehensive ASPM platform designed to provide end-to-end visibility into application security risks. By integrating automated scanning, dependency analysis and advanced vulnerability detection, Checkmarx empowers development and security teams to identify, prioritize and remediate vulnerabilities across the software supply chain. Its solutions combine SAST, SCA, container security and advanced techniques like reachability and exploitable path analysis. This ensures robust application security without slowing development velocity.

How Checkmarx reachability analysis works:

  1. Checkmarx identifies which dependencies (third-party packages/libraries) in the application are being called.
  1. Checkmarx’s exploitable path analysis scans the application’s source code, including the source code of included dependencies, to determine which specific vulnerable code (classes or functions) within third-party packages/libraries may be called at runtime.
  1. Exploitable path analysis scans the source code of dependencies of dependencies, to an unlimited traversal depth (this is called transitive dependency scanning), to identify any calls to vulnerable code.
  2. When calls to vulnerable code are identified, Checkmarx pinpoints the specific lines of code that are making the calls, and the entire call path down to the vulnerable code, to assist remediation efforts.
  3. Checkmarx presents these results to users in a way that makes it easy for you to prioritize remediation efforts around these exploitable vulnerabilities.

Here is an example showing where (file and line number) an application’s source code calls a dependency that, in turn, calls other dependencies that ultimately call a vulnerable method in a particular dependency.

Learn more by requesting a demo.

Mitigate Open Source Risk

Identify, prioritize, and remediate open source risk in your applications, including vulnerabilities, malicious code, and license risks.