Is Transitive Contextual Analysis using call-flow analysis or data-flow analysis?

Is Transitive Contextual Analysis using call-flow analysis or data-flow analysis?

Products
JFrog_Xray
Content Type
Use_Case
AuthorFullName__c
Keren Israel Michaeli
articleNumber
000006645
FirstPublishedDate
2025-09-30T15:28:43Z
lastModifiedDate
2025-09-30
VersionNumber
1
Introduction 

This article addresses why JFrog Xray's Transitive Contextual Analysis (TCA) may show different transitive applicability results compared to other security tools that support transitive contextual analysis.
Specifically, it clarifies:
  1. Why a vulnerability might be flagged as applicable in a Java/Go project in Xray, while being flagged as non-applicable in a competing tool.
  2. Why a vulnerability might be flagged as non-applicable in a JavaScript project in Xray, while being flagged as applicable in a competing tool.
This article will help you understand the two primary methods Xray uses for performing Transitive contextual analysis: Call Flow Analysis and Data Flow Analysis. It aims to explain how these different approaches lead to more accurate,  applicability detection and can result in discrepancies when comparing scan results between other tools that perform reachability analysis.


Resolution 

At the heart of our Transitive Contextual Analysis (TCA) are two distinct, powerful techniques tailored to the specific languages we scan. Understanding the difference between them is key to interpreting your scan results accurately.
What is Call Flow Analysis? (Used for Java and Go)
Think of Call Flow Analysis like checking a map for roads. This method traces all the possible paths in your code to see if any of them lead to a known vulnerable function in a transitive dependency. If a "road" or a sequence of function calls exists between your code and the vulnerable code, Xray’s will flag it as ‘applicable’.
  • How it works: It identifies if a vulnerable function is callable from your proprietary code.
  • Result: This method is effective at mapping all potential risks. However, because it doesn't verify if exploitable data actually travels down that path, it can be more prone to flagging issues that are technically present but not practically exploitable in your specific implementation. This can lead to more false positives.
  • Common Question: "Why does Xray show vulnerability X in my Java/Go project when other tools don't, or when it seems unexploitable?"
    • Answer: Xray has identified a valid call path to the vulnerable function. While your current implementation might not pass harmful data through it, the path itself constitutes a potential risk that we believe is important to flag.

What is Data Flow Analysis? (Used for JavaScript)

Data Flow Analysis is a more advanced and precise method. It goes a step beyond just checking for a road; it checks if there's actual traffic on that road. This analysis verifies if untrusted user input (often called "tainted data") can actually flow through your application and reach the vulnerable function.
  • How it works: It tracks the flow of data through your application to confirm that a vulnerable function is not only called but is also reached by potentially malicious data.
  • Result: This approach is significantly more accurate and drastically reduces false positives. It focuses only on vulnerabilities that are demonstrably exploitable in your code's context.
  • Common Question: "Why is Xray not showing vulnerability Y in my JavaScript scan, even though another tool (which likely uses call flow analysis) says it's there?"
    • Answer: While a call path to the vulnerable code might exist, our Data Flow Analysis has determined that no tainted or untrusted data can actually reach it. Therefore, Xray correctly identifies that the vulnerability is not exploitable in your context and does not flag it, saving your team valuable time.
  • Common Question: “If Data Flow analysis is more accurate, why are you not using it across all languages for TCA?”
    • Answer: We are currently developing data-flow analysis for languages other than JavaScript as well. We are in the process of validating that data-flow analysis in other languages meets our performance and accuracy standards before enabling it for these languages”

In summary, the differences you may see in vulnerability reporting are by design and reflect our commitment to providing the most accurate results for each specific language.
  • For Java/Go, we use Call Flow Analysis to map all potential risk paths.
  • For JavaScript, we use the more precise Data Flow Analysis to identify truly exploitable vulnerabilities and eliminate noise from false positives.
This tailored approach ensures you get the most relevant security insights, allowing your team to focus on fixing the issues that matter most.