Choosing between source code and bytecode/compiled scanning

When creating a new project, you have the option of choosing source code-only scanning or bytecode scanning, depending on the project.

Understanding the different methods of scanning is critical to the success of your project. Each has specific uses, requirements, and results differ.

Source code-only scanning

Early in the software development lifecycle, source code-only scanning of uncompiled code can be a helpful tool to head off issues and confirm programmatic approach before the project is too far along.

Generally performed by developers, and requiring access to source files, source code-only scans are fast but not necessarily as accurate as scans of compiled code. Results of source code-only scans pinpoint vulnerabilities in specific lines of code; they do not show trace data.

Bytecode/compiled scanning

When accuracy is preferred over speed of a scan, bytecode scanning can help you understand not just where in an application a vulnerability exists, but also the impact of that vulnerability. Bytecode scanning is sometimes referred to as "dataflow" scanning.

Bytecode scans require access to the fully built application. Scan results display "traces" showing the flow of tainted data through the application, from the point it enters the application to the point at which the data is used (called the "sink"). The trace shows the line of code and the tainted variable at each point in the trace; its appearance is similar to an exception stack trace.

Bytecode scanning may have additional requirements, depending on the project type:
  • Application dependencies should be available for the most complete and accurate results.
  • For Java and .NET bytecode is required, so the application needs to be built before running the scan.
  • For C/C++, a Visual Studio solution is required.