Static security analysis is the process of finding errors and security weaknesses in software through detailed analysis of source code. Static security analysis requires the full Intel® Parallel Studio XE product. The analysis itself is performed by the compiler; the results are viewed with the Intel® Inspector XE GUI. Analysis can be performed on one machine and the results viewed on another. In this case, only the compiler need be installed on the analysis machine. Both the compiler and Intel® Inspector XE must be installed, along with a valid Intel® Parallel Studio XE license, on the viewing machine.
Static security analysis finds a wide range of errors that could potentially be exploited by an attacker to defeat application security or cause the application to malfunction. Detected errors include buffer overflow, misuse of pointers and heap storage, unsafe or incorrect use of C/C++ or Fortran language features and libraries, and misuse of OpenMP* parallell programming constructs.
See the documentation for Intel® Inspector XE to learn more about the kinds of analysis performed by static security analysis and for details about how to use it.
Static security analysis requires that your code compile without serious errors using the Intel® Compiler.
Static security analysis is not supported on Mac OS* X systems.
Note
You can use source code analysis even if you do not plan to use the Intel compiler to build your production binaries. Similarly, you can use source code analysis for programs that will be run on a processor type not supported by the Intel Compiler.
How Static Security Analysis Works
The Compiler performs the requested analysis by operating in a special mode. In this mode, the compiler dedicates more time to analysis and bypasses the instruction generation process entirely. This allows it to find errors that go undetected during ordinary compilation.
Static security analysis first processes each source file individually, producing a pseudo object module. To avoid destroying your real object modules, keep the pseudo object modules generated during static analysis separate from the real object modules.
The analysis results are produced in the link step. This is similar to how Inter Procedural Optimization (IPO) operates, where the final instructions are generated only at the link step. This allows static security analysis to find errors that span procedure and file boundaries. This implies that you have to invoke the link step with the compiler, not by invoking the linker directly.
Static Security Analysis Recommendations
Static security analysis is most effective on a complete program; this is because some problems can only be detected by analyzing interactions across source files. You can perform static security analysis on partial programs or even on single files simply by linking fewer modules. However, doing this may hide some problems that would be uncovered on whole program analysis.
If you use static security analysis on projects that build and link against libraries, analyze a library before analyzing projects that link against that library. When you analyze a project that links against an analyzed library, the modules of the library participate fully in the analysis, as if the library sources were part of the application.
Analyzing a library by itself diagnoses problems only within that library. The pseudo object modules produced during the compilation step can be combined into a static link library using the standard librarian utility. When you analyze a dynamic library, a static library is produced during the link step in place of the usual export library. Linking against an unanalyzed library is permitted; however, the sources of an unanalyzed library do not participate in the analysis.