Software quality is nowadays one of the main concerns in information technology. It is defined by the US “National Information Assurance Glossary” (CNSS Instruction No. 4009) as “the level of confidence that software is free from vulnerabilities, either intentionally designed into the software or accidentally inserted at any time during its lifecycle, and that the software functions in the intended manner.” The US Laws and Policies now mandate (Section 932, 2012 NDAA) use of automated scanning tools in order to assure “the security of software and software applications during software development”, and recent guidelines (Section 937, 2014 NDAA) planned “a program of research and development to improve automated software code vulnerability analysis”. In an internal audit the current use of these tools was found rather poor: only 10% are using static analysis, 20% have initiated, but 70% have not even planned it. These 70% are guaranteed new customers for the suppliers of static analysis tools in the nearest future.
Many international organizations published numerous standards that impose or suggest the adoption of static analysis tools. For instance, ISO 26262-6 (about software in the automotive industry) enumerates static analysis as one of the techniques to verify software (in Section 8.4.4). Similarly, IEC 62304 (about medical software) imposes to each manufacturer acceptance criteria of software based on verification techniques like static analysis. In the finance world, the European Central Bank in 2015 imposes the use of automated static analysis for software quality inspections. In order to quantify the impact (and thus justify the spending) of introducing static analysis tools in the software development lifecycle, one should consider that:
- testing by itself is time consuming and not very efficient (most forms of testing only find about 35% of the bugs that are present),
- static analysis prior to testing is very quick and can be about 85% efficient,
- as a result, when testing starts there are so few bugs present that testing schedules are divided by half,
- static analysis will also find some structural defects that are not usually found by testing, and
- open source tools can achieve some measure of success, but only partly effective.
- the developer can find bugs (at earlier stages) by considering the warnings,
- the project manager or the CTO can check possible weaknesses of the software produced by their team, and how the overall quality evolves over time, and
- the overall quality of acquired software, even if the source code is not available, can be checked by analyzing it with Julia and inspecting the results of the analysis.