Coding Procedures

• • • Secure Coding Practices

Code Reviews

Code review is required prior to release of each feature or bug fix. (i.e. prior to integration of branch into Main Trunck)

• Release Procedure:
  

Procedure

1. Identify reviewers. Feature lead selects Review team consisting of:
   • at most two developers involved in the feature development
   • at most two developers familiar with the technology but not directly involved in the subsystem
   • at least one additional reviewer that is new to the technology and feature.
2. Present overview. Feature lead should schedule a meeting and:
   • (This meeting should not last more than 30 minutes).
   • use the Code Review Checklist Form, and as necesary:
     • build output - should not have any warnings
     • test case output - test case execution results indicating:
       • specific feature is implemented or bug fixed, and
       • there are no adverse effects introduced by the fix (other tests are not impacted)
   • provide an overview of the feature
   • define the scope of the review.
   • schedule a follow-on meeting in which the reviewer will present their findings.
3. Review code
   • This is an offline activity.
4. Review findings.
   • (This meeting should not last more than 60 minutes).
   • team should review findings
   • if corrections are required
     • a checklist of corrections should be prepared
     • all but one member of the review may approve the Code Review
     • the withholding member should validate the corrections for final approval at a later date.
5. Completed Code Review Checklist forms should be filed with the development manager.

Editing Guidelines

TAB

Use TAB to indent code

Carriage Return

Use *nix format file saves to CVS. (ie. configure CVS to save file in unix format)

Good Programming Practices

Memory Allocation

Avoid memory allocation during normal call or registration processing or other routing system function. Use eArray for other pooling to optimize.

• new & delete
• new[] & delete[]
• malloc & free

if check

Use if (10 == x) ... instead of if (x==10)

Copyright Notice

Place the following copyright notice at the top of each header and src file (cut and paste):

/*********************************************************************/
/*                                                                   */
/* Copyright (C) 2004, 2005, 2006                                    */
/* Mavenir Systems, Inc.                                             */
/* Richardson, TX, USA                                               */
/*                                                                   */
/* ALL RIGHTS RESERVED                                               */
/*                                                                   */
/* Permission is hereby granted to licensees of Mavenir Systems,     */
/* Inc. products to use or abstract this computer program for the    */
/* sole purpose of implementing a product based on                   */
/* Mavenir Systems, Inc. products.  No other rights to reproduce,    */
/* use, or disseminate this computer program, whether in part or in  */
/* whole, are granted.                                               */
/*                                                                   */
/* Mavenir Systems, Inc. makes no representation or warranties       */
/* with respect to the performance of this computer program, and     */
/* specifically disclaims any responsibility for any damages,        */
/* special or consequential, connected with the use of this program. */
/*                                                                   */
/*********************************************************************/

Defensive Coding

State Assumptions

• Document module/system design and functional assumptions
• When modifying existing code, make sure you understand the base assumptions before changing code.

Assert! on assumptions

• Check assumptions at run-time
• Use ASSERT macro to check for
  • pointers check
  • buffer overruns
  • parameter bounds checks

Check Inputs

• EVEN IF YOU ASSERT, make sure all conditions are handled gracefully!
• Check all input parameters to ensure assumptions are true
  • Use array bounds checking functions

Provide a trace for Failed Assumptions

• At least for DEBUG, failed assumptions should be logged
• For release TRACE, logging for events may need to be limited based on frequecy of occurence

Provide Statistics

• Quantify processing progress

Secure Coding Practices

Only use functions that check array bounds

• Use strncpy instead of strcpy
• Use strncat instead of strcat
• Use fgets instead of gets
• Use snprintf instead of sprintf
• Use exec instead of system

Why does this matter?

Because coding assumptions can be taken advantage of!

From the hackers handbook:

Additional Resources

• Secure UNIX Programming
• Secure Unix Programming Checklist

References

• :
• Writing safe secure programs:
• :