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.
If this turns into a management headache generating too many requests for extra privileges, it may make sense to rethink the overall architecture for the data. Are you keeping too much information? If people need more access than you're comfortable giving, you may be storing too much information. Saving less data (tip No. 2) can make it easier to give everyone a simple amount of access.
Secure programming tip No. 13: Model your threat
Do you hold credit card numbers? Then a common thief may be after your information. Do you track people's location with their cellphones? The dangers grow creepier.
Spending time thinking about who wants your data can be a useful precursor. If you can imagine a threat, you can keep the attacker in mind while you design and implement the system. They present an antiuse case to avoid.
It's important to recognize that no list or model will ever be perfect. Just because the threat isn't imagined doesn't mean you don't have to worry about it. It's just a start.