C O R P O R A T E
Developing Secure Software
No software is perfect . This is one of the hard truths of software development . But it does not mean that we cannot try to prevent mistakes , bugs , and flaws , mitigate their impact , and improve how we respond to such problems .
In this article , we take a look at the situation we are facing . It is impossible to say how many undiscovered flaws and vulnerabilities there may be , but we have estimates that offer us a good starting point . In the second half of this article , we look at some of the measures we are taking to prevent these problems and at our response for managing vulnerabilities .
The Situation In order to understand how we can avoid and prevent bugs and flaws and how we should ideally respond to the remaining problems , we need to know which types of problems can occur , how often , and where .
For a general estimate about how many bugs and flaws there will be in thousand lines of code , people often go to Steve McConnell ’ s book “ Code Complete ”. Ignoring some exceptional cases , the statistics say that we should expect between 10 and 50 flaws in every thousand lines of code . Statistically speaking , there is an error in every twentieth or one-hundredth line of code that the compiler misses . This is surprisingly frequent . In truth , it should surprise us that our IT systems are working as well as they are .
But it is not a question of numbers . The type of flaw can be the critical factor . As we are concerned with the development of secure software , we need to consider two types : bugs and flaws . Bugs are run-of-the-mill programming errors . Flaws , on the other hand , are issues within the design itself . To find bugs , we can rely on a large toolkit that helps us scour the code for many types of possible errors , as we will explain below under “ Prevention ”. Flaws , on the other hand , are harder to spot , since they often come from certain assumptions in the software ’ s design or development that might be wrong or invalid and that can create vulnerabilities for hackers to exploit .
That is the key for prevention : We need to make sure that flaws will not become exploitable vulnerabilities . Not every error in the code can be exploited . If we understand the structures we can use to prevent attackers from exploiting bugs and flaws , we can make sure that potential mistakes in development do not turn into real vulnerabilities and we get a better sense for whether a bug or flaw we noticed can indeed be exploited . This means that we need a sense for the possible effects and repercussions of potential flaws when analyzing our work , and particularly when planning a new product .
Prevention Software Architecture The base of every software is a comprehensive requirement analysis . The results of our requirements analysis are used to design the software architecture in functional and technical terms . That design is the collaborative work of experienced software developers and architects certified by the International Software Architecture Qualification Board ( iSAQB ® ), with input from a product-independent team of security experts that put the concept through its paces from its architecture to its use of the cryptographic basics .
Coding & Testing When we produce the actual software to fit our designs , we use a range of technologies to catch and remedy any errors in the code at the earliest possible point . A proper versioning system should be standard for any software development ( Wibu-Systems uses Git ) that enforces a peer review principle . No single developer should be able to weave their code through to the final release without any checks and balances .
SonarLint is used for a static code analysis in the development environment ; for the continual static analysis of the source code and for testing technical software quality , we employ the commercial versions of SonarQube on our build server . SonarQube includes more than 5000 static analysis processes ( MISRA-C , CERT C / C ++) and helps us produce genuinely clean code . We get compiler warnings and the results of the static analysis after every build .
8