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. Importantly, Coana’s reachability analysis can identify vulnerabilities in indirect/transitive dependencies. These include the dependencies of your dependencies, extending to any depth — for instance, the dependencies of your dependencies’ dependencies, and beyond. (Read more about Coana's approach to reachability analysis in this blog post (opens in a new tab)).

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:

• We are dedicated to building highly accurate reachability analyses. However, no analysis is ever flawless, and under some very rare circumstances, vulnerabilities may incorrectly be reported as unreachable. To minimize these inaccuracies, we design language-specific static analyses, enabling them to handle complex language features like reflection in Java or dynamic reads and writes in JavaScript effectively. Additionally, our reachability analysis is intentionally conservative. It will only mark a vulnerability as unreachable if there is strong confidence that it truly cannot be exploited.

• Reachability analysis is computationally more expensive than traditional vulnerability scanning, which may result in long-running scans for certain types of projects.

Lightweight Reachability Analysis

Coana provides a lightweight reachability analysis that is optimized for speed and efficiency, making it significantly faster and less resource-intensive than a full reachability analysis. This mode can be enabled by using the --lightweight-reachability flag.

For the currently supported languages, JavaScript and TypeScript, the lightweight mode accelerates reachability analysis by:

• Skipping dependency installation: Avoids time-consuming dependency resolution and installation.
• Limiting scope to direct dependencies: Focuses only on direct dependencies, bypassing reachability checks for vulnerabilities in indirect dependencies.

We recommend using this mode primarily with Coana Guardrail, where minimizing analysis runtime is crucial.

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.