Cut 80% of Your Vulnerability Workload

No, Coana doesn’t require access to your cloud environment, source control system, CI/CD system, or any other system in your SDLC.

The entire Coana reachability analysis is run as an offline task using Coana’s CLI. You can run it anywhere you like, whenever you want, but most users set it up to run regularly in their CI/CD system (see the documentation for more information).

One of the major advantages of Coana is that it doesn’t require any disruptive agents to run in your cloud environment. Coana can also scan code that’s never deployed to production, such as mobile apps, frontend web apps, and desktop applications

‍

Coana uses a static analysis known as a control-flow analysis to build a model of the analyzed program. This model, commonly known as a call graph, contains information about how the execution flows through the program. It allows us to answer questions like ‘from this specific place in my program to what other places in the program can the program execution go‘, where ‘this specific place’ could be any line in the analyzed program. Based on the call graph, Coana is able to tell which parts of the code are dead (unreachable) and which parts or live (reachable). You can learn more about how the static analysis works in the post What is SCA with reachability?

The reachability analysis is designed to over-approximate the actual runtime reachability of vulnerabilities. By over-approximating, the analysis will lean toward marking a vulnerability as reachable whenever it’s in doubt. By taking this approach, Coana allows you to safely ignore unreachable vulnerabilities without compromising on any real security. To learn more about Coana's approach to reachability analysis, consider reading our blog post on the topic.

At Coana, 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.