Code Analysis is often seen as an overhead by developers. With the increasing demands from businesses for faster GoToMarket, ensuring software quality is usually not the first thing in the mind of developers. However, to ensure software quality means to prevent future defects. Why would developers prefer future rework over spending some extra time today to ensure quality? Why do they disable code analysis, especially when the cost of poor software quality is exceptionally high at $2.8 Trillion for U.S alone, as reported by CISQ in 2018?
How Developers disable code analysis rules
Let’s start by understanding - can developers actually disable code analysis tools? If so, how? Below are few instances where developers have deactivated checking by static code analysis tools such as Sonar, PMD and coverity
Why Developers disable code analysis tools
The reason is that developers are just too overwhelmed in producing features, that it leaves them no space or time to train on security and fix the defects that code analysis tools identify. There is also this perception that code analysis tools provide a lot of findings that are irrelevant or false positives– which in fact is true for some tools but not for all of them.
[Suggested reading : False Positive in security – Why We Like to Cry Wolf]
False Positives
False positive is a result that wrongly indicates that there is a defect when in reality there is none. Developers dread code analysis tools for the numerous false positives they produce. A small application with few thousand lines of code could throw up 1000 coding violations. Out of the 1000, only 100 would be meaningful and worth addressing. The rest would be noise that need to be manually reviewed and ignored. While developers are mandated to use code analysis tools, they clearly do not have the time to wade through the numerous false positives to filter the meaningful findings. So, often the easy way to circumvent the problem is to disable code analysis.
What happens when code analysis tools are disabled?
Blindly disabling code analysis tools could impact the quality of the software severely
- The disable code analysis check stays forever in the source code and it might “hide” new potential issues when modifying the application.
- The copy/paste practice will copy those tags and prevent the quality checks on the new destination source code
- This might end up becoming a short-cut for the developers to pass the code quality checks without having to fix the problems
What’s the alternative to disabling code analysis - The Solution
While selecting a code analysis tool, organization should check for the tool that would result in tangible benefits for the developers. The code analysis solution should not only look at individual pieces of code in silos but also do a contextual system level analysis of code w.r.t the whole application. This kind of structural analysis prevents a lot of false positives and highlights only the most critical violations that need to be addressed. A tool like CAST that uses structural analysis will only show a few highly critical violations that can be fixed as opposed to showing hundreds of violations that cannot be comprehended.
Example of how contextual analysis could prevent false positives
Several code analysis tools check for input validation – to test whether an input provided by a user is sanitized before being used in the application. However, without contextual analysis, false positives can show up when validation does not happen in the UI layer. Since, contextual analysis understands the entire application structure, it knows for sure before reporting if input validation happens in any of the other application layers.
To know more about contextual analysis and how CAST can help overcome the issue of false positives without disabling code analysis rules, schedule time with our expert.