"There is a delicacy to confronting development," agrees IndyMac Bank’s Weber. "The application scanning tools add some objectivity. The CIO should also set development requirements and get management buy-in first. That adds more objectivity. If you clearly define the security parameters, development can’t make it a personal argument or a grudge match."

It’s easy to see how it could devolve into politics and sniping when Weber explains what he’s really doing. "My job," says Weber, "is to impose a security will on the developers."

Use Freely Available Security Standards

Start with NSTISSP No. 11, the national security standard that mandates that any software used in a national security setting must pass certain government audits. Learn the criteria, and then demand that your developers and vendors meet them. (Go to www.cio.com/bugs for the NSTISSP No. 11 standard.)

The government has many other security standards. (Go to www.cio.com/bugs for a list.) None is a defining standard but virtually every one of them contains something useful. Special Publication 800-27, a NIST document, for example, contains 33 application security principles. (One of them: Implement least-user privilege, which means start with all access turned off and turn it on only as needed, not vice versa.)

It’s important to note that most of the standards are foundational. That is, they’re most useful for software at the design and requirements phase, and less useful for applications that have already been developed and deployed.

Put Security in Writing

Ferderer now requires that his vendors do application scanning on every software package Mutual deploys.

"The trend to put security right in contracts has become quite successful," says OWASP’s Curphey. "It’s more common and more accepted than ever, in part because there are the tools which, to a degree, lend objectivity to the security of an application."

A contract signed between General Electric and the software vendor General Magic last year excited security experts. (Go to www.cio.com/bugs to see the full contract.) Section 7.3 is called Code Integrity Warranty, and it holds the vendor financially accountable for bad software and requires the vendor to fix it.

Tick Off These To-Dos Too

After buying the software, reeducating your developers, poring over standards and hanging out with contract attorneys, you can (if you have the energy):

• Check out OWASP. Weber at IndyMac Bank lifts heavily from the OWASP guidelines for secure Web application development.
• Read Winning with Software, by Watts Humphrey, and have the developers read Writing Secure Code, by Michael Howard and David LeBlanc.
• Send your developers to school. College-level computer science classes in writing secure code are starting to appear. At SEI, fellow Humphrey (called "the Edwards Deming of software") has developed an entire development methodology for secure coding called the Team Software Process (TSP). Microsoft recently put a small group of coders through TSP’s intense two-week training. The group was then charged with rewriting a 24,000-line application under the TSP process. The goal was to reduce the number of defects in the program from 350 to about 22. Microsoft says a post-production defect costs it $4,200. If the company meets its goal, the total cost of post-production defects in this small application (it’s an internal one) would shrink from $1,470,000 to $92,400.