o one who works in IT today can escape the carnage wreaked by hackers. Worms and other exploits are increasingly designed to target specific vulnerabilities in software ranging from operating systems to business applications?and for that reason, attention is increasingly focused on the development community. The industry is starting to ask itself how it can build more secure software.

It’s true that perimeter security has gotten better and there’s been a flurry of new legislation and better-trained law enforcement at all levels. These have combined to make success quite a bit harder for hackers. But the real threat looming for the hacker community is that their most valuable, and usually unwitting, ally is now poised to become their greatest adversary. You see, until now, hackers have relied on the security ignorance of developers to succeed. But trends are showing that the people who make software are starting to fight back.

The Good Old Days
Traditionally, information security professionals and application developers have been uneasy bedfellows. In years past, security staff generally approached developers as they would any other IT user, emphasizing well intentioned but outdated practices for securing network perimeters and enforcing authentication credentials.

During my tenure as a development manager, I worked at one company whose approach to security entailed a quarterly meeting with the CISO and a 50+ page Word document he created describing “the information security policies that you and your team are expected to comply with henceforth”?but not much else. Thumbing through the documents, I found policies on password lengths and firewall settings, but nothing to do with the code my team was developing. He wanted us to be concerned about security, but no one could accurately express what that meant to us as developers. It was a step in the right direction, but it had no impact on application security.

This inability to provide the context for security in meaningful development terms?helping the security people and developers understand one another?is what has eluded us up to this point and why software is so easy to attack.

This rush toward a ship date while preserving crucial features leaves little room for ensuring application security. Only today are organizations beginning to address this inherent mismatch in priorities and get the development workgroup and their security colleagues working in tandem.

In years past, security professionals treated applications with an after-the-fact approach. They envisioned a world in which security could be “bolted on” to applications after they were completed, but before they were deployed. This approach unraveled as soon as it was understood that applications, especially those that sat behind a firewall but interacted with legacy applications or the Internet, contained vulnerabilities that couldn’t be discovered until applications were deployed and live. At best, it annoyed developers who needed to make changes in what they considered to be sound code. At worst, it left enterprises open to attack on a number of fronts.

Meanwhile, within developer workgroups, no changes were made to ensure that the priorities of those who write software mapped to the priorities of information security staff. Traditionally, developers are judged against two metrics: feature sets and ship dates. This rush toward a ship date while preserving crucial features leaves little room for ensuring application security. Only today are organizations beginning to address this inherent mismatch in priorities and get the development workgroup and their security colleagues working in tandem.

Common Goals and New Approaches
The crucial first step is for security staff and developers to realize that they share a common goal of securing information from those who would like to harm us. The number and financial consequences of enterprise security breaches, including those enabled by application vulnerabilities, are making news almost daily. The sheer impact in terms of lost revenue and reputation makes it a problem bigger than either party has dealt with in the past.

Organizationally, new roles have emerged to build a bridge between developers and security staff. As titles like Software Security Architect become more common, security policy has been emphasized in terms that make sense to developers. Software Security Architects have introduced technologies such as penetration testing to the quality assurance process, and are making sure that developers receive meaningful training in security policy and best coding practices. In addition, Software Security Architects can articulate the ways in which vulnerabilities make their way into applications.

Organizations can also train staff on the different points in the development timeline when processes can introduce vulnerabilities that are not the fault of any individual developer. For example, Developer A and Developer B could write two independently flawless modules within one application, but depending on the code, vulnerabilities could develop as a result of integrating these pieces during nightly builds. Similarly, a development team could scrub that vulnerability out of a nightly build, only to find that a new one is discovered during the QA process. Development managers have also become aware of the danger created when, say, an application coded in C++ interacts with a Java application to create a vulnerability not found in either stand-alone application. Lastly, developers are beginning to understand how applications that call on legacy, pre-Internet applications, written before the days of firewalls, can create data paths that are crucial attack vectors for hackers.

New technologies are easing developers’ burdens regarding security. In particular, source code analysis and attack simulation have emerged as powerful tools for development managers. Source code analysis tools validate snapshots of code against a set of secure coding rules while attack simulation adds targeted hacking techniques to an existing QA regression test. If vulnerabilities are detected, the tools report the violation, along with a suggested remedy. Detecting such problems significantly reduces the cost of fixing software defects.

The added advantage is ensuring quality, efficient code with fewer performance bottlenecks. This is not a panacea, however. These techniques are only as effective as the last time they are performed and the coding rules enforced. Successfully deploying these tools requires careful consideration of exactly where and when they should be run within the software development process; otherwise they can provide a false sense of security and slow down development.

Bridging the Gap
It’s clear that unless developers become security professionals themselves, there will be a gap to be bridged. The key to solving this problem is to understand that securing applications does not require any disruption to well-entrenched development practices. As soon as development teams embrace that they can have a major impact on overall security through relatively small adjustments to what they are already doing in the design, coding, and testing phases, the largest hurdle has been overcome. The introduction of automation into application security allows organizations to marry security and development without disruption, and enforce policy without delaying deployment.

Automation is a powerful tool for identifying security issues hidden within the context of a large system. Automated tools allow the security team to verify the output of a development team. Even more important is that automation can be applied while lines of code are being written, so that there are many fewer issues to be resolved in nightly builds and during QA.

As soon as development teams embrace that they can have a major impact on overall security through relatively small adjustments to what they are already doing in the design, coding, and testing phases, the largest hurdle has been overcome.

Automated security tools can validate code, line-by-line, as it’s entered on a development desktop. They can detect the use of vulnerable functions and procedures and point out the exact location of a potential vulnerability. They suggest alternate, secure functions or procedures to allow development to continue and provide on-the-job training on how to avoid a similar mistake in the future. The best analysis tools don’t simply highlight vulnerability; they explain how the vulnerability came to be.

In the same way, automated data flow analysis can detect paths of potentially dangerous data before the data has the chance to move through an application. In addition, these tools can accurately track sequencing of operations to detect improper coding constructs; again with the effect of efficient code as well as secure code.

The benefits of automated code analysis extend well beyond the desktop. The same approach can be used to track, analyze, and rectify flaws not found until after a code build has completed. Run-time analysis can categorize and prioritize code security issues. It can also point to specific lines of code to pinpoint possible vulnerabilities, and trace tainted data back to its source so that a fix can be applied.

Automation can also improve security once a release candidate has been completed. Automated tools can probe, observe and attack applications pre-deployment with a fraction of the time and effort it takes even sophisticated attackers. It can also monitor and track progress in a consistent manner?detailing the places your team has exercised while exposing untouched areas of your application.

At the end of the day, automation cannot take the place of secure coding practices and policy. However, the marriage of policy, best practices, and automation offer the best chance for the development community and their security colleagues to achieve their common goal?a world of secure applications.

Editor’s Note: The author, Roger Thornton, is the cofounder and CTO of Fortify Software, a vendor of security solutions including automated source code analysis. We have selected this article for publication because we believe it to have objective merit.