Secure Software Development Initiatives Go Mainstream

Finding security bugs in application code was once seen as only a small part of the development process. But these days, secure software development is going mainstream.

Driven to clean up their code by customer pressure, regulations, and fear of bad publicity caused by breaches, enterprises and software houses are focusing on secure code initiatives and employing next-generation tools to identify bugs -- before software is deployed.

"If we could get everybody with a wallet to start thinking about these things before they contract for development, either internally or externally, then we would really eliminate a lot of these [security] problems," says Jack Danahy, worldwide security executive for IBM. "You would not have to be managing as many vulnerabilities out in the field."

Last week IBM announced improvements to its AppScan vulnerability analysis and reporting product, including a consolidated view of vulnerabilities and the inclusion of new technology that aids in the analysis of Web applications. The company aims to make the software -- and its Rational development platform -- a more popular way for software houses and large enterprises to develop their applications.

The company is not alone. In August, HP announced it had acquired Fortify Software, a maker of code auditing products. The increasing use of secure development tools by nonsoftware makers is one reason the acquisition made sense, says Brian Chess, chief scientist at HP Fortify.

"We are moving from just serving kind of the high end to serving more the mainstream," Chess says. "Their software comes from many sources ... they don't build it all themselves, so it's more of a supply-chain management problem."

During the past four years, studies showing the tremendous cost of fixing flaws after software has been released have helped drive managers to commit to fixing the issues. A study released this year by Mainstay Partners and funded by Fortify found that having a secure development process -- referred to as software security assurance (SSA) in the paper -- can reduce the likelihood of repeated vulnerabilities from 80 percent to near zero and shorten the average time to fix a flaw from between one and two weeks to less than two hours.

The benefits of vetting code for security bugs has driven the market for secure development product to mainstream firms, says Danahy of IBM, which bought code-security firm Ounce Labs and its AppScan product in 2009.

"As soon as those security teams and management teams had within their grasps the analysis of how broken things were, they instantly wanted to give a better set of tools to the developers to help them fix things," Danahy says.

Both IBM and HP see the current landscape changing. Clients and customers are increasingly making secure code part of their businesses, they say. Companies that want to reduce the vulnerabilities in externally developed code need to change the contract with their providers and add language that requires the code to be checked for common flaws.

"In terms of acquiring code, you have to make sure that you are getting software from someone who takes security seriously," Fortify's Chess says.

Checking software with common code scanners is one way to validate the quality of the code, although general security checks are still an open problem. That's because code-scanning tools still have a major issue: false positives. Handing a developer a list of automatically generated exceptions and calling them flaws is a good way to lose the support of any development teams, says Caleb Sima, CEO of security firm Armorize.

"You cannot feed a code-scanning results to a developer because you will overwhelm them," he says.

Sima also argues that too many firms ramp up their secure development programs too quickly. While training developers to write more secure code is a good thing, project managers should not go overboard, he says. Rather than try to tackle the top 10 or top 25 software issues, companies should instead take a small bite.

"Simplify it by saying you must have these three issues solved," Sima says. "In too many cases, the security team has bullied their way into the development environment, and we have seen a complete rejection by the dev group as a result."

In the end, the key to success is to get the executives on board. If the people holding the purse strings can require security, then it will eventually happen, IBM's Danahy says.

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