Contextual Analysis of CVEs

When scanning for vulnerabilities, traditional tools often flag a large number of CVEs, most of them irrelevant. Sorting real risk from noise is slow and error-prone, and many of the reported vulnerabilities never affect the scanned artifact at all.

JFrog Vulnerability Contextual Analysis addresses this by flagging only CVEs that are actually exploitable in the scanned artifact. It runs a set of automated scanners, built and maintained by the JFrog Security Research team, that inspect multiple facets of your artifact to determine whether a CVE is truly exploitable: first-party code usage of the library, binary compilation, configuration, invocation, and runtime environment.

Approximately one-third of JFrog's contextual analysis scanners deliberately don't rely on reachability, because for many CVEs the evidence of exploitability never appears in source or binary code. It lives in configuration files, command-line flags, or properties of the host. The analysis produces a justification for every result, including which signals the scanner looked for, so you can learn and verify the finding against your code and environment.

JFrog Contextual Analysis coverage spans both source code and compiled binaries, including Docker/OCI images and Uber/Fat JARs. For more information, see Supported Technologies and Package Applications in Docker for Contextual Analysis.

Automated scanners are built by the JFrog Research group. With a JFrog Advanced Security subscription, you can request research from the dedicated team. If a CVE lacks a contextual analysis scanner, the team prioritizes building support for it.

What Applicability Analysis Checks

A single scanner may combine several of the following techniques to determine whether a CVE is truly exploitable in your context:

• Reachability: Whether the vulnerable function is called by the scanned source or binary. Example: CVE-2019-14892 (Jackson-Databind) is only exploitable if first-party code calls ObjectMapper.readValue and passes external input as its first argument.
• Binary symbols and strings: Whether the vulnerable binary was compiled with the vulnerable functionality enabled. Example: CVE-2018-1000500 (BusyBox wget) is only exploitable if BusyBox was compiled with the non-default FEATURE_WGET_OPENSSL flag.
• Configuration parsing: Whether the component’s textual or binary configuration enables the vulnerable code path. Example: CVE-2024-27316 (Apache HTTP Server) is only exploitable when HTTP/2 is enabled via LoadModule http2_module in httpd.conf.
• Command-line flags: Whether the component is invoked with flags that activate the vulnerable functionality. Example: CVE-2022-42915 (curl) is only exploitable when curl is run with --proxy and a scheme such as gopher://.
• Runtime environment: Whether the host’s OS, Linux distribution, CPU architecture, bitness, or file permissions match the conditions the CVE requires. Examples:
  • CVE-2024-3219 (Python) affects only Windows.
  • CVE-2020-1751 (glibc) affects only PowerPC.
  • CVE-2022-28321 (PAM) affects only openSUSE Tumbleweed.
  • CVE-2024-45492 (libExpat) affects only 32-bit binaries.
  • CVE-2022-4883 (libXpm) requires a SUID executable to call the vulnerable function.

Why this matters: for CVEs like CVE-2024-27316, no amount of source-code or binary reachability analysis can determine exploitability, because Apache exposes no API to enable HTTP/2. The switch exists only in httpd.conf or .htaccess. Scanners that combine reachability with configuration, binary, CLI, and environment analysis catch these cases while keeping false positives low.

Research Team’s Approach to CVE Prioritization

The JFrog Security Research group, which continuously performs CVE Research and Enrichment and Contextual Analysis features, considers several factors when deciding which CVEs to build a scanner for:

• Relevant technologies for JFrog clients: JFrog Security Research prioritizes CVEs affecting the technologies most commonly used by JFrog users.
• Severity: Research focuses mainly on “high” and “critical” severity CVEs (CVSS score >= 7.5), and also considers machine-learning-based severity prediction for CVEs without a CVSS score.
• Exploits in the wild: Vulnerabilities exploited in the wild or those with high media attention are prioritized, even if their public severity rating is lower (for example, “medium”).

This helps you get timely and relevant protection against the most significant security risks, with already more than 1,600 high-profile CVEs.

Key Benefits

• Reduces false positives: Filters out vulnerabilities that don’t impact your software today.
• Detects exploitability that reachability alone would miss: For vulnerabilities gated by configuration files, command-line flags, compile-time options, or properties of the runtime host.
• Provides actionable insights: Highlights vulnerabilities with real-world impact. In the case of binary analysis, there is more context that allows for the analysis of the complete codebase from an attacker's perspective, identifying which issues are truly exploitable and what their potential impact is.
• Actionable remediation: Enables targeted mitigation based on the actual code, artifact, build, or Release Bundle.
• Seamless integration for developers: View results directly in your IDE, CLI, PR decoration (Frogbot), and the JFrog Platform.

Version-Specific Support

The list of supported technologies for CVEs Contextual Analysis in source code and in binaries is available in Supported Technologies.

Some binaries in Docker containers are only available from specific Xray versions:

• Rust binaries in Docker containers: Supported in Xray 3.79.x and later
• .NET binaries in Docker containers: Supported in Xray 3.95.4 and later. For more information, see Package Applications in Docker for Contextual Analysis.

Contextual Analysis Statuses and Results

Vulnerability Contextual Analysis Statuses

• Not Scanned: Initial state. The scan wasn't invoked for the CVE.
• Applicable: The vulnerability can be exploited in the context of the scanned code or artifact.
• Not Applicable: The vulnerability cannot be exploited in the context of the scanned code or artifact.
• Undetermined: The applicability cannot be determined by static analysis. For example, the exploitation requires user interaction.
• Rescan Required: A new scanner for this CVE is available. You need to rescan to retrieve applicability results.
• Not Covered: Scanner isn't available.
• Technology Unsupported: The vulnerability’s package type is currently not supported.
• Missing Context: Reachability analysis cannot determine the vulnerability’s applicability due to missing context. Applicability can be determined by scanning the artifact in a Docker repository in the JFrog Platform.
• Upgrade Required: For self-managed environments, the Xray version needs to be updated to receive a new scanner for this CVE. A rescan is required after the upgrade is complete. For SaaS, in rare cases you might see this status before the new scanner version is fully deployed. You don't need to take action. The scanner operates automatically once the update is available.

Vulnerability Contextual Analysis Results

CVE Contextual Analysis results are available in:

• Scans List in the JFrog Platform from Scans List.
• Inline in your IDE
• CLI for immediate feedback
• Pull Request Decoration with Frogbot

Transitive Dependency Analysis

The Transitive Dependency feature in JFrog Advanced Security enhances contextual analysis by identifying vulnerabilities that are not directly in your code but are introduced through transitive dependencies (dependencies of your dependencies).

For each CVE, the analysis shows:

• The call chain in your code that leads to the vulnerable function.
• Whether the call is direct (in your code) or transitive (through another dependency).
• A call graph button that visualizes the dependency path.
• Highlighted functions and file paths where the vulnerable function is used.
• A copy-to-clipboard option for evidence such as function names, file paths, and line numbers.

This helps you understand exactly why a CVE is applicable in your project and where it is triggered.

Viewing Transitive Dependency Analysis

1. Run a security scan on your repository or artifact.
2. In the Scan Results page, select a CVE from the list.
3. Open the Contextual Analysis tab.
4. Switch between Direct and Transitive views:
   • Direct shows direct calls in your code.
   • Transitive shows calls leading to the vulnerability through transitive dependencies.
5. Review the evidence:
   • Path, line, and function calls are highlighted.
   • Use the Call Graph button to view a visual graph of the dependency chain.
   • Use the Copy icon to copy evidence details to your clipboard.

Frequently Asked Questions

This section provides answers to frequently asked questions.

Related Topics

• Smart Remediation
• Contextual Analysis Policy