Why Can't Johnny Develop Secure Software?

It's another day in the life of a security pro -- or a hacker. Much of your time is spent searching applications for that one weak point, the one that will lead to the breach of sensitive data. And nearly every day, somebody finds one. Or more.

With all of the security know how offered today -- and all of the advanced tools offered to applications developers -- why is software still riddled with security vulnerabilities? The answers are many, and they don't always agree. And solutions to the problem? Those are even more diverse.

Vulnerabilities start, experts agree, because developers don't understand how to build security into the code they write.

"There's a lot more acceptance of security as part of the process now, but historically developers have never been responsible for security," says Brian Chess, founder and chief scientist at Fortify, a company that makes tools for secure software development. "We all understand locks and keys, but not many of us are locksmiths. That's where most developers are."

Caleb Sima, CEO of secure software development tool vendor Armorize, agrees. "Developers are builders and artists," he says. "They like creating, not tearing things down, to identify flaws. Security is not a natural thing for most of these people -- it's a different mindset."

There have been many initiatives to educate developers about secure software development practices, including certification programs from organizations like ISC(2), which offers a program that trains programmers in security disciplines. But the education process is slow, experts say.

"The talent coming out of schools right now doesn't have the security knowledge it needs," says Paul Kurtz, executive director at SAFECode, a nonprofit organization backed by major software vendors and focused on secure software development practices. "There needs to be a lot more work in our educational institutions to teach them how to develop secure code."

But nearly all experts agree that no matter how strong the training effort, the average developer will never be very security-savvy. "They're always going to be more focused on code quality and trying to meet their deadlines," Sima says. "If I'm a developer, as soon as I've been assigned a project, I'm already behind. If there's a faster way to do something, they're going to take it, because for them speed is more important than security."

So if the average developer can't become a security expert, how can organizations ensure the code written by that developer is vetted and tested to reduce vulnerabilities? Currently, most development organizations have a designated security-savvy person who is responsible for working with less-savvy colleagues to cut down on common vulnerabilities and act as a liaison with the enterprise IT security team, Fortify's Chess observes.

"This is the kind of person you can ask about security problems, or who can recognize when a line of code is going to create a buffer overflow issue," Chess says.

But this approach isn't very efficient because the "security developer" can be a bottleneck or may not recognize all of the vulnerabilities, Chess explains. Some organizations are responding by implementing secure development frameworks, such as BSIMM, which impose secure best practices across the entire development team.

"BSIMM is a good strategy if you have a formalized software development process," Chess says. "But if you don't, you're not going to build that process around security."

Marisa Fagan, an analyst at Errata Security, notes that such formal secure software development programs are often too much for development teams to handle.

"What's wrong with secure software development? The short answer is resources," Fagan says. "These programs have the [not entirely unwarranted] reputation of consuming large amounts of time, people, and money. We need programs that cut out all the fat. The secure coding program needs to fit the size and capabilities of the organization. If we ask too much from the average developer, we're going to get nothing at all."

Recognizing a market opportunity, many vendors are jumping into the secure software development fray in an effort to automate some or all of the process. Fortify, one of the oldest players in the U.S. space, has a framework called Secure Software Assurance and a tool set called Fortify 360. IBM, with its acquisitions of Ounce Labs and Watchfire, is building a broad tool set for secure application development. Armorize, whose tools have deeply penetrated the Asia-Pacific market, is just beginning its U.S. marketing effort.

Earlier today, secure development tool vendor Veracode launched a series of enhancements to its SecurityReview Web application testing service that promises developers a "cloud-based approach" to quickly improve software application security.

"Developers can now upload applications automatically and download line-of-code specific vulnerability identification and remediation instructions directly to defect tracking systems and integrated development environments," the company said. Veracode also issued a white paper on security testing in agile software development environments.

Even Dan Kaminsky, one of the industry's best-known security researchers, is getting into the act. Kaminsky this week launched a startup called Recursion Ventures, whose first product focuses on secure application development.

The trouble with today's model for writing more secure code and sidestepping known injection attacks, Kaminsky says, is it makes development much more difficult and requires more work for developers. The result: Developers often don't bother adopting these practices at all, resulting in insecure code, he says.

"Security development tends not to care how inconvenient it is for developers," Kaminsky says. "[This new venture is] about meeting developers halfway."

Each of these vendors -- and others -- offers a different approach to automating the development of secure code, but they generally agree that the idea is to help developers identify and remediate the most common coding errors and fix them on the spot, during development, rather than waiting until after the code is complete.

"If you go to the development team with one policy that solves 80 percent of the issues, you can get good results," Sima says. "One of the most common vulnerabilities is input validation. You don't need to know security to understand how to do input validation correctly and keep those errors out of your code."

Another key feature to look for in automation tools is the ability to spot vulnerabilities in the development process, as opposed to individual applications, Chess says. "When you go to a restaurant, you don't try to measure the quality and safety of each piece of food," he observes. "What you do is send in an inspector to look at the process to see how the food is being prepared. Did you apply the most common practices to ensure safety and quality? That's what needs to be done in the development environment."

At the commercial-software level, SAFECode also proposes that developers monitor the chain of custody of the code, so that vulnerabilities aren't introduced when it is passed between contractors or when it is distributed to end users, Kurtz says.

"Most of the studies on software development so far have really looked only at the security issue," says Kurtz, whose organization this week issued a white paper on the topic. "What we're saying here is that software integrity and authenticity need to be part of the discussion."

Will this emerging range of automation tools eventually help developers create applications with fewer security bugs? Experts are hopeful.

"When you think about it, the whole concept of code security analysis is still pretty young," Sima says. "Most organizations haven't really gotten started yet -- today, most of the vulnerability identification and analysis is done after the development cycle. But if you can shorten the vulnerability identification cycle and identify code errors right then and there during development, you're going to end up with better, more secure software."

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.