In software security, there's a depressing but indisputable truth: No matter what you do or how much money you spend making code more resilient, fortifying the network or electro-shocking developers who write bad code, you can't get rid of all the security bugs. Not only is it impossible to make 100% secure software; it's not cost effective. If we accept that bad things are going to happen, we can take simple steps throughout the development life cycle to weave a software safety net that limits the damage and pain of the inevitable, uncaught vulnerabilities that resist our best efforts at prevention.

Let's look at some of the safety nets that can be woven into software development:

Requirements safety net: As early as product inception and requirements gathering, developers should be asking tough questions about postdeployment patching. How easy is it? Can it be patched under rampant vulnerability exploitation? What are customers' needs for patch deployment? What patch impact will users tolerate (downtime, patch size and so on)? Determining customer/operations requirements around failure and patching upfront can help make software maintainable. Understanding security needs can forge an incident-response process that minimizes operational risk.

Design safety net: During design, "planning to fail" is about lessening the severity of vulnerabilities that surface later. Classic security design principles can go a long way, such as the principle of least privilege (giving the application only the rights it needs for a task) and compartmentalization (segmenting the application). Beyond these, think carefully about error handling. Asking "What if the bad guy had control over this component?" will help sharpen focus to contain damage and put up barriers between components and critical data.

Development safety net: This is where the largest volume of vulnerabilities is introduced in software. Developer security training helps with prevention, but to catch common mistakes, a source-code scanner or security-specific code reviews can help enforce specific coding policies.

Testing safety net: Even if you test security, your test cases are probably going to miss issues. There are techniques that can help you hedge your bets. For example, fuzz testing - the practice of randomly corrupting data through software's interfaces - can reveal vulnerabilities that testers may have never conceived of.