Binary and Runtime Scanning
Highlight
- Software binary and runtime scans unique to CodeLogic reveal connections source code scans miss.
- Binary scans let you see methods and dependencies injected by the compiler.
- Binary scans also reveal connections and dependencies imported from closed-source third-party libraries.
- Runtime scans reveal stored procedures in databases and scans the APIs actually used by your application.
How It Works
CodeLogic gathers application dependency data to provide core platform functionality such as 1-Click Change Impact Analysis, Application Overviews, Dashboards and Impact Scoring. To do this, CodeLogic uses a combination of binary scans and runtime profiling. Until now, every approach to analyze dependency relationships all but guaranteed blind spots. By combining binary and runtime scans, CodeLogic can minimize areas of missing data and form the most complete understanding of your software’s structure in real time.
Binary Scanning
Why scan the binaries instead of just the source code?
Scanning binaries rather than source code provides significant advantages:
- Discern the final results of code injection after compilation: Methods and dependencies introduced by the compiler or annotations are detected and analyzed
- See what external databases, servers and APIs your application is actually communicating with
- Third party libraries can be profiled, even if the third-party project is closed source
Runtime Scans
Some dependencies are difficult to identify through static scans, either of source code or compiled binaries. For example, many database queries are generated at runtime based on user input rather than simple linking through an Object Relational Mapping (ORM) layer. To capture these and other dynamically established relationships, CodeLogic provides runtime scanning.
Additionally, modern practices such as service registries mean REST endpoints are often looked up at runtime rather than hardcoded. Source scans struggle to guess what endpoints are used. By profiling the application at runtime, a system can see what APIs are called, and from where in your code.
Other Types of Dependency Scanning
While Binary and Runtime scans work well for code, additional approaches are used for other software that CodeLogic profiles.
- Relational Databases: Databases are scanned with a CodeLogic agent that assesses the database structure and retrieves stored procedures for profiling. These CodeLogic agents connect remotely using JDBC drivers and do not need to be installed on the database itself.
- API scans: CodeLogic REST APIs are used to connect to targets such as ServiceNow and AWS EC2 instances to detect structures in those environments and profile them.
Source code scans are not enough
Though a useful tool, source code scans miss the complete application picture. In many cases, closed-source third-party libraries are used to supplement a project, but the final impact on the application may not be understood until compilation. Compilers may inject their own code through plugins. In addition, stored procedures in attached relational databases are often missed by non-runtime scans. Structural dependencies called upon by the compiled app can also be problematic to pinpoint purely from the codebase alone.
Binary and Runtime scans permit a deeper—and complete—view of an application ecosystem. By looking at the compiled runtime and binary files, complications arising from closed-source projects are pinpointed by looking at their effects, since the code itself is unavailable. Stored procedures, structural dependencies, and compiler-injected code are observed through their functional consequences, rather than predicted consequences by code alone. Binary and runtime scans focus on the big functional picture.