SAN FRANCISCO -- RSA CONFERENCE 2013 -- The common wisdom among security experts is that every company should kick off a development program to teach secure programming, find vulnerabilities in their software, and include security at the design phase.

Yet that wisdom was questioned at the RSA Conference last week during a panel discussion that pitted Brad Arkin, Adobe's senior director of product security, against John Viega, executive vice president of products, strategy, and services at SilverSky, a cloud security provider. One point argued by Viega: Companies like Adobe and Microsoft can handle the costs of a secure development process, but smaller companies cannot necessarily foot the bill.

"I know dozens and dozens of companies that look at what they are doing and say, 'Are you kidding me? This will put me out of business because I would spend 90 percent of my time securing software, and I would never actually do anything,'" Viega said.

The panel discussion turned comical at times, as the two debated the merits of implementing secure development practices, with Viega mostly arguing against secure programming as he played the role of devil's advocate.

Still, the pair of software-security professionals agreed more often than not. Viega is the author of number of books on secure programming, including Beautiful Security and the Secure Programming Cookbook. Arkin has helped Adobe create its secure product development program, which includes threat assessment, developer training, iterative testing, and incident response. All software developers should invest in such a program to make their software better, Arkin said.

"The investment that you make up-front is important," he said. "You want to build a good foundation so that you have a chance to be secure."

The two security experts agreed -- mostly -- on five steps that companies can take to make their software more secured.

1. If tricky, code it once.
While code reuse is a general rule in software development, it's especially important when writing code for a security feature. Security features need to be done right; by focusing efforts on where it matters, development teams can write the security code ince and then move on, Arkin said.

[A panel at the RSA Conference showed how the DevOps paradigm could actually provide a huge step forward for security teams seeking to insert themselves into the development process. See Using DevOps To Upgrade Application Security.]

"Any time something is tricky for security, you want to bring that into a central place, do it right once, and then give that out for everyone to use in their code base," Arkin said. "That way, we don't have to keep redoing that dangerous section of code."

2. Review all code once, then only check new code.
Code audits are expensive. Conducting frequent audits can quickly push up development costs. Instead, companies should analyze their code once, and then do iterative checks whenever a developer submits his code.

In addition, some companies may find a better return on investment if they focus on dynamic -- "black box" -- testing first, and static code analysis later, Viega argued.

"For software-as-a-service vendors, [code review] is vastly less important because you are not putting software in the bad guys' hands," he said. "Instead, you should focus on the same sort of black-box testing as the bad guys."

3. Use developer mitigations.
When Adobe created Reader 10, it included a number of security features -- such as a sandbox, address space layout randomization (ASLR), and data-execution prevention (DEP) -- that made that version of the program much more difficult to exploit. Adobe did not see an in-the-wild exploitation of that version of reader for more than 30 months, Arkin said.

"The bad guys all understood that it had become too hard, it really raised the cost to exploit writers," he said.

Companies should take a similar tack and use the software security features that are designed to make exploiting software more difficult.

4. Train developers, but ...
Developers should be required to go to classes on secure programming, but Arkin and Viega disagreed on who should go. Microsoft and Adobe both train their developers to program securely. Viega argued that, as a way to cut costs and reduce productivity downtime, companies should train only those developers who show an interest in secure programming.

"You should only spend money on training the people who want to do this," he said, "because the reality is that those are the only people that are going to make a difference."

5. Regulations don't help.
While Viega attempted to make a case for the government serving a role in software development, Arkin immediately went on the offensive. Regulations that impact software development -- such as the Payment Card Industry's standards -- have led to no measurable changes, Arkin said.

"Thank God PCI regulations came out, because now we will never have another credit-card compromise," he joked.

Government regulations would fare no better, he said.

"Any regulation that tries to legislate software development is so woefully out of date that, by the time it is printed, it's just a waste of time," Arkin said.

Instead, companies and consumers should demand more secure software, he said. The inclusion of security requirements in software contracts has started to lead to greater awareness of secure development practices.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.