Static analysis looks for security vulnerabilities in source code by referencing the most common vulnerabilities as defined by OWASP.
The parser is able to monitor code for vulnerabilities to data injection by looking at any queries or command statements that take input from users. It checks to see that every instance of user input is properly prepared to avoid data injection. If the code does not properly separate user input from data structures, the parser will report a vulnerability.
A static analysis engine looks at authentication vulnerabilities by checking that the code protects user authentication credentials by hashing or encrypting the stored authentication information. It looks for weak account management functions, such as password recovery processes, for simple password overwriting vulnerabilities. It verifies that the source code hides URL authentication information via URL rewriting algorithms and looks at session timeout procedures that often produce vulnerabilities to session fixation attacks.
When scanning for security vulnerabilities, the static analysis algorithm tags structures that contain sensitive data and verifies that all direct references to these objects require authentication for data to be passed to the caller. Similarly, the parser looks at indirect references to sensitive data objects and the data mapping process to ensure that the call requires user authentication. When the parser locates an instance of potential vulnerability, it will tag and report the instance and include it in a security metrics report. After scanning through all of the most common types of software vulnerabilities, it will generate a report that references all potential vulnerabilities it has identified.
Static analysis is especially apt at looking at the reliability of all modules and methods of software.
The source of reliability in code is the ability to produce a predictable outcome given wildly varying inputs. In static analysis, the parser identifies specific methods and isolates them, emulating their behavior when ported into other software modules. Once isolated, the algorithm will generate arguments and read method outputs, expecting the outputs to contain specific information and formatting. It will raise flags for any anomalies in a method.
The algorithm will then aggregate anomalies and generate a report that points to specific methods that compromise reliability.
The efficiency of code is largely dictated by memory usage and data flow.
When performing static analysis, the memory usage of a program is not explicitly readable. By definition, static analysis is performed on code without actually instantiating an interpreter; thus, the parser needs to infer memory usage by looking at the code and data structures.
A common source of code inefficiency calls for entire data sets to be stored in active memory. This is especially common in legacy code and in systems initially developed for small data sets. The static analysis algorithm looks for any such explicit calls to store data sets in memory and reports them. It will also look for cases of lingering data stored in active memory – any call for data to be stored in active memory will prompt a search for a call to drop that data from memory after working and updating a database.
The report will suggest an iterative alternative approach to carrying out a memory-intensive task, but it’s important for a knowledgeable developer to look at such reports. Some explicit calls to stored data sets in memory are necessary and entirely manageable if, for example, the data set is known to be small (such as metadata).
Static analysis procedures will also identify duplicate code and multiple calls to commit the same data to memory simultaneously.
In most cases, the static analysis of source code will reveal and report important sources of software inefficiencies. It’s especially illuminating when working with extensive legacy code and data structures that weren’t initially designed to be scalable.
The maintainability of code is closely related to the complexity of code. If the source code is overly complex, it can be difficult to make changes and incorporate new functions and modules quickly.
Thus, the static analysis protocol looks for sources of code complexity to generate metrics that quantify code maintainability.
A source of program complexity that is easy for a parser to identify is duplicate code in sibling classes. If certain classes share a parent and share explicitly defined methods, the code is overly complicated – the two classes could inherit their shared method from a parent class. A parser can easily identify such cases by looking for duplicate methods.
Another source of complexity, method side-effects, are easy for static analyzers to look at. By parsing the arguments, output, instances, and the method code, the algorithm can find methods that create complications by implicitly affecting data flow.
By quantifying program complexity, a static analysis report helps developers look at the maintainability of their code and improve it by pointing to specific sources of complexity.
A static analysis report gives insight into the portability of source code by isolating and testing methods. Deprived of their native environments, the parser can predict how well methods would perform if ported.
Much as with reliability and maintainability, the portability of code lies in its complexity. The complexity metrics that a static analysis generates help developers quantify the portability of their code.
It’s important to understand the function of static analysis in any automated software quality test. It’s a wonderful tool, but developers should understand its strengths and limitations.