Find out why static analysis is the best way to harden software and identify potential issues at the earliest possible stage in software development.
Static analysis is the process of examining source and binary code without execution, usually for the purposes of finding bugs or evaluating quality. Unlike dynamic analysis (such as *-Parasoft Insure++) which requires a running program to work, static analysis can be run on source without the need for an executable, before the application is even finished.
Static analysis is used most often in two ways:
Static analysis tools can be introduced and used at any stage of a project, even when it’s incomplete and partially coded. The main challenge is in scenarios where large amounts of legacy code produce many warnings. Remember to focus on getting the team productive quickly and minimizing overwhelm because of static analysis warnings. They’re important, but first you need to integrate the tools into daily process based on severity and risk.
To make the most of your static analysis tools, you need to understand the end goal. If it’s better security, for instance, this affects the focus of analysis and remediation. Know the end goal as soon as you adopt static analysis. As the team becomes more proficient, incorporate secondary goals like improving overall quality and enforcing coding standards. As static analysis becomes second nature, developers will be able to analyze results quickly and fix bugs more efficiently. Then secondary goals will be achieved more effectively rather than simply being overwhelming.
It’s also important to think about the maturity of the product under development because it impacts the method for static analysis.
Static analysis is most commonly rolled out in the midst of current projects. Each project can adopt the tools at the beginning of a sprint or major feature update.
Recommended approach: a line in the sand – improving new code as it’s developed while deferring less severe warnings as technical debt.
This is a product that is in the elder years of the software development lifecycle, in which little new code is being written – only to fix lingering bugs and security vulnerabilities.
Recommended approach: acknowledge and defer – Since little new code is being developed, all discovered bugs and security vulnerabilities are added to existing technical debt.
Although it’s not often that software teams get to have a fresh start, a new product and project is the ideal point to integrate new tools and techniques into the development process. In these projects, little existing code specific to the project exists, but it still may rely on third-party and open-source software.
Standard approach: greenfield – Developers can integrate static analysis in their development environments from the start, ensuring a high standard of quality as code is being written. This allows for the adoption of coding standards and ensuring critical static analysis warnings are dealt with as they arise, thus adding less bugs and vulnerabilities.
One of the main differences between open source or lightweight static analysis tools and commercial advanced static analysis tools are the abilities to configure which set of checkers are enabled for the analysis, and filter out reported results based on warning category, file name, severity, risk, and other attributes.
There is an important difference between configuring checkers and filtering results. Although initially it might seem better to limit the number of checkers in the global configuration, filtering should often be used instead, to limit the scope of reporting rather than eliminate the checker entirely.
The key to making static analysis a success in a project is to make sure the tools are easy to use and accessible by developers, so the tool must provide useful, actionable information upfront without overwhelming users with information.
The main integration point for static analysis tools and build systems is through a command line interface. Static analysis used in this fashion acts somewhat like a compiler would in the build structure. Files are processed in the same manner, although the output isn’t an executable but rather results that are stored in a repository, indexed by file and build number.
In the case of a product under maintenance or in development, there is likely a sizeable backlog of warnings to deal with. In the case of a greenfield project, there is less backlog, although recommendations remain the same for each stage of maturity. The best starting point for dealing with a backlog of warnings is to prioritize and filter the results based on the desired outcome.
When a software team has integrated static analysis into their day-to-day activities, they’ll want to customize the tools to better fit their project. Optimizing static analysis means adapting the checkers and the way violations are reported to improve the efficiency and ROI for the organization.
Parasoft’s software testing solutions support the entire software development process, from when the developer writes the first line of code all the way through
+1-888-305-0041
