Source Lines of Code - Relation With Security Faults

Relation With Security Faults

The central enemy of reliability is complexity. —Geer et al.

This section may contain original research.

PhD Gregory V. Wilson among other experts have claimed a relationship between the number of lines of code in a program and the number of bugs that it contains. This relationship is not simple, since the number of errors per line of code may vary according to the language used, the type of quality assurance processes, and level of testing. Although changing from a programming language to another have little impact in the number of lines of codes written by a developer, which is a good argument for high level languages.

Gregory V. Wilson at CUSEC 2010 said:

One of pieces of folklore that was actually confirmed, is that productivity and reliability depends on the length of the program's text independent of the language level. You'll produce roughly the same number of working lines of code if you are writing in assembly, per hour, as you would produce in ruby or scheme or perl or java. Your output in term of text per hour is roughly constant. That's a pretty cool result, it argues that we ought to be using the highest level language that we can, because you can do a lot more with ten lines of python that ten lines of assembly. The problem of course (...) is... somebody once said: platform independent programs have platform independent performance. If you are writing at very height level your performance is gonna be right in the basement. But at least now we can start doing what engineers have done in other domains, for at least a couple of centuries. We can start making trade offs: If I use this very high level language, I'm gonna need ten times severs to get performance but my code will be working next Thursday not next year. OK? Now becomes an economics question, and engineering is really what happens when you take science and economics and try to put them together. —Gregory V. Wilson

Also importantly, the number of bugs in a program has been directly related to the number of security faults that are likely to be found in the program.

This has had a number of important implications for system security and these can be seen reflected in operating system design. Firstly, more complex systems are likely to be more insecure, the resons behind this are:

• A greater number of pieces means that there are more places where the system can fail.
• A greater number of lines of code has correlation with the number of bugs the software has.

For this reason, security focused systems such as OpenBSD grow much more slowly than other systems such as Windows and Linux. A second idea, taken up in OpenBSD, Windows and many Linux variants, is that separating code into different sections which run with different security environments (with or without special privileges, for example) ensures that the most security critical segments are small and carefully audited.