Developer checklist

The check list below can be used as a starting point for all system developers (full or part time, specialist or not) as a reminder of good practice:

• Architecture
• Design
• Cryptography
• Implementation
• Coding
• After Implementation

We have produced a short presentation to illustrate these points that Grid sites are free to download and use for internal presentations.  This is available in both Microsoft® Office PowerPoint ® 2003 format and PDF.

• Architecture
  
• Divide the program into semi-independent parts
• Isolate each part so they work correctly even if others fail
• Build multiple layers of defence
• Simple solutions are usually the most secure

• Design
  
• Make security-sensitive parts of your code small
• Don't require more privileges than you need
• Avoid standard default passwords, force users to change passwords
• Deny by default
• Limit resource consumption, to limit the likelihood or impact of a denial of service attack
• Fail securely: for example, if there is a runtime error when checking a user's access rights, assume s/he has none
• Don't trust the client: in distributed or web applications use server side authentication

• Cryptography
  
• Use trusted, public algorithms, protocols and products

• Implementation
  
• Read and follow guidelines for your programming language and software type
• Think of the security implications of what your code does
• Reuse trusted code (libraries modules, etc.)
• Write good-quality readable and maintainable code (bad code won't ever be secure)

• Coding
  
• Don't trust input data
• Validate all input data
• Don't make any assumptions about the environment
• Beware of race conditions
• Deal with errors and exceptions
• Fail gracefully if there is an unexpected error that you can’t recover from: log details, alert the administrator, clean the system (delete temporary files, clear memory) and inform the user
• Protect passwords and secret information
• Be careful when handling files, especially temporary files: don't fall for the symbolic link attack
• Be careful with shell calls, eval functions etc

• After implementation
  
• Review your code and let others review it
• When a (security) bug is found, search for similar ones
• Use tools specific to your programming language: bounds checkers, memory testers, bug finders etc.
• Turn on compiler / interpreter warnings and read them (Perl -w, gcc -Wall)
• Disable debugging information (strip command, javac -g:none, etc.)