Choosing between source code and build output scanning

When creating a new project, you have the option of choosing source code-only scanning or build output (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.

Build output scanning

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

Build output 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.

Build output 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.