As you craft a plan, make sure SDL is considered during the design of every programming project, from start to finish. Every program and script should have documentation covering its intended use, threat modeling, and implemented security mitigations. You might relax the requirements for small scripts, but personally, I'd still put in place some sort of formal SDL recognition and declaration.
Choose your tools wisely
Make sure developers and scripters use coding tools that are tailored for inclusion in SDL programs and contain secure defaults. These tools should compile code and scripts in ways that get rid of the easy bugs. Today, many programming languages provide advanced protection against maliciousness. The ones that give memory protections, prevent buffer overflows, and implement safety checks should be considered seriously.
Don't forget to have a list of acceptable cryptography. It should include what encryption ciphers, key sizes, and hash algorithms are allowed and not allowed, and it should be reviewed at least biannually. There's no reason for today's programs to use DES, MD5, or 1,024-bit asymmetric key sizes going forward.
Prevent the use of known vulnerable and weak coding structures. At Microsoft, these barred programming structures are labeled as "banned APIs." Dozens of insecure programming statements cannot be present in code that gets to production. These banned APIs are prevented by training, by coding tool choice, and automated code review.
Today, OSes and browser code are becoming harder -- although far from impossible -- to exploit. Instead, malware writers have been focusing more often on the applications that run inside browsers and other applications. One common tactic is to malform data in a way that allows malicious code to run inside an otherwise innocent application. Think Adobe Acrobat Reader, Sun Java, or Microsoft Office -- all these productivity applications have been used by the bad guys to sneak malicious code onto a user's desktop.
Remember who you're dealing with
After nearly two decades of neglect, privacy protections are now considered one of the outcomes of SDL. Over the past few years, company after company has come under legal and legislative review for not doing enough to protect their customers' or users' privacy. Make sure your SDL program includes privacy considerations and review as part of the process.
Any program should have secure defaults. That was a big lesson learned by Microsoft over the past half decade. Defaults are what most users take, so implementing safe choices provides a tremendous amount of value. When a security decision is presented to the end-user, it should default to the safest choice or fail safe.