Coders should always work hard to make sure their applications consider all input as untrusted and work to prevent unsafe malformations. A common SDL tactic is to use file fuzzers, programs designed to find bugs that would allow malformed data with unexpected parameters (such as random or deliberate data variations) to maliciously manipulate an app. Almost every serious bug finder today lives and dies on the strength of their fuzzer program. There are many free fuzzer programs on the market, although commercial ones tend to be better, especially at determining what is simply a bug and what is an exploitable bug.
Test your mettle
Secure coding reviews should be conducted by one team member on other team member's code on a periodic basis. Coding teams might be given prizes and other bonus incentives for finding code bugs in another team's code. Granting a free vacation day, free house cleaning, or a free golf outing with the boss for demonstrated secure coding or finding the most bugs is a terrific way to motivate teams. Most companies find better compliance using more honey and less stick.
Consider using internal or external code review or hacking teams before implementing software into production environments. Download and use free or commercial tools that are designed to find coding bugs. Make their use a normal part of the development process.
When -- not if -- a security bug is found in your production software, make sure there's a program in place to quickly address the vulnerability. Don't wait for the bug to be found before you create the response process. Make sure all found bugs can be traced to their source -- who coded it, who reviewed it, what SDL tools were used, and how the bug got by. Make sure the bug or ones like it don't exist in other software; if they do, proactively fix those programs and code segments as well. Find out how the weakness slipped through and implement controls, tools, and mitigations to prevent similar bugs from happening again. Better security is a process and a designation.
Lastly, make sure the code you buy from others is SDL-reviewed. Ask vendors and third parties to share with you the SDL programs they use in their software development processes. It's likely that many of these companies won't have official programs, but your prodding will help them see the need. Some companies, with sufficient influence and buying power, even negotiate the right to SDL review the vendor's code before buying.
Even if every vendor and scripter created perfect software and scripts with zero bugs, it wouldn't stop malicious hackers from doing bad things on a large scale. Today's cornucopia of social-engineering malware, where the end-user is tricked into run a malicious program, will still be around. But making more secure software is a way to make it harder on the bad guys.
This story, "Keep costly software bugs at bay with SDL," was originally published at InfoWorld.com. Keep up on the latest developments in network security and read more of Roger Grimes' Security Adviser blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.