We’ve heard it 1,000 times, “Make sure your software is secure.” But what does that mean exactly, and how the heck do we go about it? Think about the cost that’s involved in securing your software, then think about the cost of not securing your software. It’s clearly a no-brainer, as the folks at Anthem, Home Depot, Target, and countless others will tell you. And it gets harder and harder – and more and more expensive – to try and secure that software after the fact.

As a starting point, I suggest you focus on the potential problem, rather than an immediate solution. Otherwise, it’s easy to miss potential vulnerabilities. Second, think about why a hacker may want to attack you. That also may give some indication about how (and where) you should go about securing yourself.

Finally, understand that making yourself 100 percent secure is pretty much impossible. The hackers that I’ve spoken to haven’t found any system unhackable. Some are harder to get into than others, and the methods of attack are often extremely innovative, but hack they did. So your goal should be to make the system so difficult to invade that the hacker will basically move on to some other system that’s easier to penetrate.

Another thing to remember is that if your system does come down, you want it to come down on your terms, not the hacker’s terms. A phenomenon known as “fail well” comes into play here. This means that if you are attacked, you want to minimize the damage.

A very simplified checklist of items you (or your developers) should cover include:

• Enable your developers be creative and to innovate
• Ensure that your developers have as much specificity as possible to correctly deliver security
• Build (or buy) the tools developers need so they can check for correctness
• Deeply participate in the process to ensure that the entire organization is giving security its proper due
• Prove the value of security processes and tools

Where did I come up with these great thoughts? Some of them are simply time-testing techniques. Others I borrowed from a presentation that I’m involved in, along with Rogue Wave Software, Polarion Software, and Security Innovation. The live event, called “Security at the source: Threat modeling and applied security architecture in Agile software development,” is a half-day of interactive talks revolving around security. It takes place on September 29, at 1:00 p.m. in Palo Alto, Ca., and should provide you with specific intelligence on the state of security for your company, and arm you with information that you can act upon immediately.

The specifics you’ll learn include how to identify and remedy vulnerabilities early on in the software development life cycle; how to create policies for code management in integrated testing environments; how to ensure compliance to proven security standards by understanding what they mean; and how to integrate security and compliance testing with Agile development.