“The application security testing market is growing rapidly … This is the highest growth of all tracked information security segments, as well as the overall global information security market” – Gartner’s 2017 Magic Quadrant.
Within the broad and ever growing application security realm, code analysis has become a standard which is practiced by leading companies across markets and fields. This leads to a variety of Static Code Analysis solutions: the technique of automatically analyzing an application’s source and binary code to find security vulnerabilities.
Two main offerings exist within the Static Code Analysis sphere:
- Binary or Byte-code Analysis (BCA): Analyzing the binary\byte code created by the compiler.
- Source Code Analysis (SCA): Analyzing the original un-compiled code, as written by developers.
Both offerings promise to deliver security and answer the requirement of incorporating security into the software development life cycle (SDLC).
When faced with the BCA vs SCA dilemma, which should you choose?
On the one hand, BCA saves some of the code analysis efforts – the compiler automates parts of the work (such as resolving code symbols). Ironically, it is precisely this compiler off-loading which presents the fundamental flaw with BCA:
In order to use BCA, all code must be compiled before it is scanned. This raises a plethora of problems which push back the SDLC process and, subsequently, delays the application’s go-to-market.
BCA-related problems include:
Vulnerabilities are exposed too late. The entire code needs to compiled prior to the scan, pushing security to a relatively late stage in the SDLC. Scanning at this stage usually brings up too many vulnerabilities to handle as there is no time to fix them under high pressure to release the product.
Compiler optimization hurts the accuracy of the results. One of the many roles compilers fulfill is to optimize code in terms of efficiency and size. Problem is, optimization may come at the expense of accurate results. For example, compilers might remove so-called “irrelevant” lines of code, aka dead code. These lines of code are often inserted by developers as part of their debugging process.
PaaS providers are incapable of retrieving the byte-code. In a Cloud Computing scenario, the Platform as a Service (PaaS) provider is responsible for validation, proprietary compilation and execution of the programs. However, the PaaS provider cannot retrieve the byte code or has no manifestation as binary\byte code.
Benefits of Source Code Analysis
By scanning the source code itself, SCA can be integrated smoothly within the SDLC and provide near real-time feedback on the code and its security. Source code analysis doesn’t cause the problems BCA does and manages to provide an efficient alternative, here is how.
Scans Code Fragments and Non-Compiled Code. SCA scans code fragments regardless of compilation errors arising from syntactic or other errors, allowing developers to scan incomplete code in the midst of the development process, ultimately allowing the discovery of vulnerabilities much earlier during the SDLC.
Supports Cloud Compiled Language. New coding languages have developed under cloud computing scenarios. In these cases, the developer codes in the PaaS provider’s language while the provider is the one responsible for validation, proprietary compilation and execution of the programs. In such cases, the code has no manifestation as byte-code nor as binary, and the analysis must be done on the source code itself. A well known example is the Force.com platform supplied by Salesforce.com. This platform is based on the server-based language called Apex and a client-based language called Visualforce. Only an SCA product can support this paradigm.
Assesses Security of Non Linking Code . In cases where the code references infrastructure libraries with a missing source, BCA tools immediately fail with the unfortunate “Missing Library” message. Days may be spent on building stubs for these missing parts, just to make the code compile. This is tedious work without any added value. SCA tools easily identify vulnerabilities, such as SQL injection, even when the original library code of the executing SQL function call is missing.
Compiler Agnostic. In a multi-compiler environment, typically found at code auditors and large corporations, the SCA standard provides a convenient one solution fits all. This is an important contrast to BCA which must support an endless number of compilers and versions. The reason? Each compiler transforms source code into its own version of binary\byte code, forcing the BCA tool to read and analyze the different outputs of different compilers. Thanks to the fact that the SCA tool runs on the code itself, pre-compilation, it provides a single standard that doesn’t rely on the compiler version.
Platform Agnostic. When integrating SCA into the SDLC, the exact same tool can be used to scan all code, regardless of the operating system or development environment. This eliminates the inherent redundancy of BCA which must deliver separate scanning tools for each platform.
Learn more about SCA here: