Poor quality software is expensive, because fixing errors incurs additional costs. Most software defects are caused by the programmer who introduces them into the product. If we manage to avoid making mistakes when developing software, software can be developed at significantly lower costs. The researcher Capers Jones conducts an annual study on the subject of software costs. As the data shows, the typical costs for software increase with each phase - from creating the requirements specification to programming and maintenance. The way teams approach quality determines whether their process is healthy or 'pathological'.

The cost of poor quality

If defects are found immediately when the code is written, the costs are relatively low (image below). If 85% of all defects can be eliminated during the development phase, this has a significant impact on costs. According to studies of real software in companies, fixing bugs after release costs around 16,000 US dollars, which can be significantly more (see image on page 2). If the quality and security measures are carried out by testing at the end of the development cycle and therefore immediately before release, the effort and costs increase by a factor of around 15 compared to finding them in early security audits. But why do we believe that quality and security can be 'tested into' software?

The following findings indicate that almost nobody approaches software development from an engineering perspective:

- What most developers do is not reproducible: two developers solve the same task with different results.

- There is a lack of well-developed 'best practices': software developers view coding standards as a set of rules that team leaders insist are followed, failing to recognize that a coding standard embodies knowledge, practice and experience. While an electrical engineer realizes that standards are a way to build a product that is safe at the first attempt, a software developer sees a standard as a restriction that inhibits him - a 'false positive'.

- Inconsistent developer training: Software development training is not as standardized as engineering. The focus is often on programming languages instead of standards and established practices.

More safety and security

The chart from Caspers Jones shows the average cost of correcting errors in the individual development stages.

© Parasoft

Coding standards aim to establish proven programming practices that can be used to create functionally safe, reliable, testable and maintainable code. As a rule, this means avoiding unsafe programming practices as well as code that can lead to unpredictable behavior.
In the past decade, there has been a shift in tools such as static analysis tools, for example C/C++test from Parasoft, from detecting potentially problematic, unsafe code or known language vulnerabilities to looking for defects as a form of early testing (also known as 'shift left'). The search for defects is important, but solid software should be written from the outset. Standards are therefore needed to prevent defects from occurring in the first place.

The industry standards

Moderate quality is only cheaper until the end of the coding phase. After that, high quality is cheaper. [1; 2]

© Parasoft

Industry standards for safety and security, such as MISRA C/C++, SEI/SANS CERT, OWASP Top 10 and CWE - Common Weakness Enumeration Top 25, embody an enormous amount of work. Although their field of application may be limited depending on the type, they are used in many industries. Take MISRA C, for example: this standard, which was created in 1998, is well defined and is updated every few years. As the C and C++ languages evolve, so do the associated standards. The flexible standard takes into account different severity levels and there is a documented strategy for handling and documenting deviations. As the technology for detecting violations of the guidelines established by coding standards continues to develop, the latest MISRA versions take into account which guidelines are decidable - i.e. can be detected with high accuracy by tools - and which are not.

The role of static analyses

Studies show that insufficient error elimination is the main cause of poor software quality. Programmers achieve an efficiency of around 35% when detecting defects in their own software. Later in the development cycle, the number of defects that are eliminated after all design reviews, peer reviews, unit tests and functional tests is around 75%. Static analysis can increase the rate of eliminated defects to 85% if used properly and preventively. However, most companies focus static analysis on finding and quickly eliminating errors.
There are additional benefits if static analysis tools are used from the outset to avoid known poor programming practices and language features. This is where coding standards come into play, which use guidelines and language subsets to prevent defects such as buffer overflows or missing initializations from being written into the code in the first place.

Arthur Hicken works in the areas of software security and test automation at Parasoft.

© Parasoft

Let's assume that a complex buffer overflow error is detected in a test, for example with a Dynamic Application Security Tool (DAST). After detection and debugging, a new test must follow. Static analysis with flow analysis might also have found this error, depending on the complexity of the application. Although runtime error detection is precise, it only checks the lines of code that are actually executed. So it can only be as good as the test coverage. It would be better if a coding standard had prevented the code that leads to this error from being used in the first place.
Coding standards such as MISRA C guide programmers to write their code in such a way that errors do not occur in the first place. This is a much more 'engineering-like' approach: Programming to known and accepted standards. If a software team applies a coding standard and uses static analysis correctly, it can detect and avoid errors at an early stage.

However, it is better to change the way the team writes the code. A good example is the Heartbleed vulnerability. There are now detectors for exactly this vulnerability, but the code could have been written in such a way that Heartbleed would never have occurred. Coding standards embody sound technical principles for programming in the respective languages and form the basis for a preventive approach.

Literature
[1] Jones, Caspers: Applied Software Measurement, 1996
[2] Morana, Marco M.: Building Security into The Software Life Cycle, 2006