Security Exposure
Security exposure may be reduced by removing unnecessary libraries from the application. Static analysis tools can quickly check which libraries or APIs are required by the application and alert the developer to remove them. Since we inherit the security vulnerabilities from each of the libraries we call into, removing unnecessary libraries is a security best practice. There have been many cases of developers and testers failing to test for buffer overflows in their application because they thought they were safe due to the use of a managed application written in .Net or Java. Many of these applications call into legacy code that was written long ago and contains other security vulnerabilities; removing all unnecessary libraries can help lessen the attack surface.
Many other security checks can be found at compile time. Some system API functions have been deprecated and should be replaced with their safer cousins. A static analysis tool can quickly discover the use of any of these functions and notify the developer of a safer replacement. Possible buffer overflow conditions can be predicted so the developer can fix them before they are discovered and exploited through the application. Discovering buffer overflows at this stage also shows the developer the exact line and conditions when a buffer overflow may occur which can be very helpful in finding and fixing the vulnerability.
Time-of-check versus time-of-use problems can be discovered as well by showing places where the developer has checked the availability of a resource and has allowed a significant amount of time to pass before using the resource. Time-of-check versus time of use errors can allow escalation of privilege attacks which may allow tampering of a resource to which the user shouldn't have access or information disclosure.
Metrics can help a developer understand where there is unnecessary complexity in a piece of code. This can help increase performance of the software significantly, which will lessen the possibility of a denial of service attack. Static analysis tools can predict which functions are very complex using Cyclomatic complexity, Functional file coupling and Functional file cohesion. Other metrics, such as ratio of commented lines to source lines, can point to places in the source where the code may need to be commented more effectively.
The simulation engine is one of the most powerful and most guarded pieces of the static analysis tool. The simulation engine allows the tool to predict how the application will behave after it has been compiled and run on the system. In a simulation engine, the simulator selects a function, generates data for each of the variables, and runs the function through every possible code path. If information about proper data ranges for those variables exist within source code they will be used, if no information exists then random values selected between the max and min for that data-type are used. Testing with a static analysis simulation engine is a good way to get around the inherent shortcomings of traditional static analysis tools.
The final check a static analysis tool can do is to crawl the source code to map out every possible code path and discover unused or unreachable code. These dead code pockets are orphaned and unreachable so they remain untested throughout the product cycle. In a future release, bug fix or code modification, the dead code may become active, thereby exposing untested security vulnerabilities or other functional flaws. Under certain circumstances a skilled hacker may even be able to circumvent the built in constructs within an application and execute the untested code which then may contain exploitable security flaws.
