Source code review – when and why is it useful?

Questions answered by a code review
Different testing techniques provide different results. The review of source code is advisable for components and functions with high security requirements or whenever the reliability of the implemented security mechanism is crucial. By performing a code review it is in general not possible to prove that the reviewed program is free of errors, but the report of the review will give answers to the following questions which usually cannot be answered without analysing the code of the program.

• Are all security relevant functions of the specification identifiable within the source code?
  
• Do the implemented security mechanisms conform with the requirements of the specification and with best practice standards?
  
• Are the security relevant functions implemented correctly according to the specification?
  
• Are there any undocumented functions within the reviewed program components (e.g. back doors)?
  
• Is the programming style suitable for SW with high security requirements ("defensive style", readability and complexity)?
  
• Does the program avoid the use of unsafe functions (e.g. unseeded random number generator, "buffer overflow", ...)?
  
• Is the program maintainable and reviewable?
  

The effectiveness of security mechanisms, especially the correct use of cryptographic functions and the key management is almost impossible to analyse efficiently using a "black-box test". If you are responsible for a critical information system, you will feel better, if the answer for each of the above questions is a "yes".

Requirements
It is not always possible to undertake a source code review, because there are inherent restrictions, which apply before the review is started (musts):

• The source code of the program must be available
  
• The program is successfully tested
  
• The functional requirements are well defined
  

In most cases the first restriction - availability of source code - is the limiting factor. The following additional requirements apply, in order to perform the review more efficiently (optional):

• The program is written in a well known programming language
  
• A member of the development team provides a short introduction to the reviewers
  
• During review, all upcoming questions are answered by a competent person (insider)
  
• Detailed documentation is available (e.g. system specification, test reports, operating manuals, ...)
  
  

Review procedure
After the goal and the date for the source code review are fixed, the first review step consists of reading all available documents and getting familiar with the systems architecture. If the documents are not detailed enough the exact functionality of the program must be reconstructed by the reviewers based on the source code – which is a time consuming activity. In this phase, the main function blocks are identified and it is agreed where and on which component to put the focus on. A detailed review plan will give an estimation on how much time can be used for each component.

During the initial analysis an inventory of all program files is created and the content of the files is analysed at "a first glance". If possible an analysis tool for code quality is used. The program code is also scanned for unsafe functions, e.g. such functions which could potentially produce a so called buffer overflow. The result is a statement on quality and reviewability of the software, which is based on metrics like percentage of comment lines, inheritance depth, cyclomatic- and interface complexity, function lengths and others. With this analysis it is possible to detect if the quality is not uniform for the whole source code.

During the main review phase the security related questions will be answered. Depending on the systems functionality all data structures holding sensitive data (such as cryptographic key-material), the communication behaviour and the potential backdoors are analysed. The reviewer will verify that parameters of cryptographic and critical functions are correct and conform to the specification.

The last step consist of writing the review report and presenting the findings. The review team will group the findings by priority and suggest solutions.

Typical findings and recommendations of a source code review
Although reviewers are working hard to find backdoors, fortunately they are not common occurrences. On the other hand it is quite normal to find problems such as

• bad seeding of a pseudorandom number generators (PRNG)
  
• missing version control
  
• insufficient comments
  
• inconsistencies between program and specification
  
• use of unsafe functions
  
• errors in key-management
  
• undocumented functions
  
• unused code, missing cleanup
  

Depending upon the criticality of the finding and the operational risks for the company, typical recommendations could be

• fix program before "go-live"
  
• fix within a specified time frame
  
• install a compensational control (organisational)
  
• replace bad modules / libraries
  

Conclusion
Even if it is not possible to prove that a given program is secure, it is always a worthwhile exercise to take a closer look at the source code of a key component. Additionally our experience is that there is a positive effect on software quality, if the development team is aware that there will be a formal source code review after delivery. This makes it often surprisingly easy to form a business case for reviewing critical programs.