Secure programming tip No. 8: Tested libraries -- use them
Encryption is hard to do well, and even the best theory and carefully built code can have loopholes and backdoors. It's usually a mistake to reinvent a well-tested library, but it's even more problematic with encryption. Well-tested libraries are more important in this field than others. Choose better code here and don't invent your own algorithms.
Secure programming tip No. 9: Use internal APIs
Breaking your code into modules and enforcing communication through well-designed APIs is an old lesson everyone learns early in their career. It's even more valuable for security because APIs can make it simpler to audit interactions, find holes, and fix problems. Modules can be scrutinized individually, and the results can be combined.
It often makes sense to create internal submodules as well; the same idea applies inside of modules, too. Parts are easier to analyze than the whole.
Secure programming tip No. 10: Bring in outside auditors to critique your code
Each of us can use an editor. If an enterprise is investing in a well-built installed base, it should also be investing in code audits. These can identify flaws and generate suggestions for improving the code.
In general, more eyeballs looking over the code can spot problems that may occur. Outsiders can also unjam internal political logjams and break ties. They often don't know any more than insiders, but they have the advantage of being unaffiliated with internal factions.
Secure programming tip No. 11: Code analyzers are your friend
Though far from perfect and not as smart as a human, code analyzers can be worthwhile. After all, they're diligent and they don't get tired, thirsty, hungry, or bored.
Code analyzers like the FindBugs tool from the University of Maryland can look for common mistakes we make when we're not thinking. Many of these mistakes have little to do with security, but some can be fatal.
Secure programming tip No. 12: Limit privilege
Developers love to think ahead, and giving someone all the access they might need is a simple way to plan for the future. If they're just starting on the project, why not give them the ability to read all of the databases and commit code? The same goes for systems. If one of your development projects is going to access a database, why not give the code a login that lets them read, write, and update?
While leaving doors open is a simple way to handle future chores and avoid creating annoying road blocks for users and staff, the open doors, as mentioned in tip No. 1, are often the first pathway that's abused. A good principle is to give code and people the smallest amount of privilege needed to get the job done.
Sign up for CIO Asia eNewsletters.