Reachability Analysis

The primary advantage of Coana over other traditional vulnerability scanners is its reachability analysis that determines which vulnerabilities are actually reachable from the entry points of your project. This is important because in most projects, the majority of vulnerabilities (typically more than 80%) are not reachable and thus not exploitable.

The reachability analysis is based on advanced static analysis that scans both your application's source code and the code of your dependencies to build a model of how dependencies are used in your application. The analysis is built on top of decades of cutting-edge research in static analysis and is designed to reason well about complex language features such as reflection in Java and dynamic reads and writes in JavaScript. Coana's reachability analysis can also detect vulnerabilities that are reachable through indirect dependencies, also known as transitive dependencies. These are the dependencies of your dependencies, extending to arbitrarily deep levels—for example, the dependencies of your dependencies' dependencies, and so on

The advantages of the static reachability analysis used by Coana are:

• It takes place on-premise (on your machine) and does not share any source code with Coana.
• Unlike other vendors, you don't have to install disruptive runtime agents in your production environment to conduct reachability analysis.
• It's zero-configuration, making it extremely easy to adopt.
• It uses tailored static analysis for each programming language, making it extremely accurate and capable of reasoning about the reachability of vulnerabilities deep down in dependency trees.

There are some limitations and caveats to the reachability analysis:

• No reachability analysis is ever perfect, and there are unlikely scenarios where the analysis may report the reachability of vulnerabilities incorrectly. We try to minimize these cases by building static analyses that are tailored to specific programming languages, making it possible to analyze even complex language features such as reflection in Java and dynamic reads and writes in JavaScript. We also built the reachability analysis to be conservative, meaning that it will only report a vulnerability as unreachable if it has high confidence that it is indeed unreachable.
• Reachability analysis is computationally more expensive than traditional vulnerability scanning, and you may experience some long-running scans. We are currently working on various improvements to speed up the scanning, for example, by introducing caching of some results.

FAQ

How does Coana know which parts of a package are affected by a vulnerability?

To identify the parts of packages affected by vulnerabilities, we have a dedicated security team that works on answering exactly that question. Whenever a new vulnerability is discovered, the security team initiates a thorough investigation of all the various resources related to the vulnerability. The team typically installs the affected package, reads the documentation, and builds a detailed understanding of how the package works. Once the functions, methods, properties, etc., responsible for the vulnerability have been identified, the team writes a specification that captures exactly these parts of the package. This specification is then used by the static analysis when it performs a reachability analysis on your code.

As a bonus, the team also writes an informal, human-readable version of this specification, which users of Coana can use to better understand the vulnerability.

What happens if Coana's analysis doesn't yet have a specification for a vulnerability?

In that case the vulnerability is still included in the report, but it is marked with an "unknown" reachability status. We strive to add support for all new vulnerabilities within 24 hours of their public disclosure.

What if a vulnerability cannot be tied to a specific part of a package?

At Coana, we employ a fallback mechanism to address cases where a vulnerability cannot be tied to a specific part of a package. This category includes malware packages and vulnerabilities in packages used as Command Line Interface (CLI) tools rather than libraries. We classify these vulnerabilities as 'always affected' and categorize them as reachable. Many of these vulnerabilities are safe to ignore in many scenarios; for example, if the vulnerability is in a package typically used only during the application build phase, which is often the case with vulnerabilities like CVE-2023-45133 (opens in a new tab). We recommend using the dismissal feature to ignore vulnerabilities in this category if your manual assessment determines they are irrelevant to your context.