It is believed that if organizations develop code with a security orientation, that is develop code securely and provide more security functions, that the majority of security issues we face today would be resolved. It won’t resolve all of the issues but it would certainly support a more secure computing environment and no one can argue against that.
So why is code security now more important than ever? The threat environment has become increasingly hostile and dangerous; more attacks are targeting the application stack – you write insecure code and you will put your organization at risk. The evolving use of the Internet for communication, partnerships, and value is forcing organizations to expose more content on the Internet as they move from brochure ware to real value-added services, some organizations have hundreds of internally developed applications and it is not uncommon for a large percentage of these to be accessible via the internet. Although regulatory issues have not impacted the ISV world yet, it is probably not unlikely that ISV’s will become a target of regulations, and not far behind will be internally developed applications, especially externally exposed web applications.
There is a wealth of information out there on secure application development, lots of qualified folks driving the message, a set of strong emerging tools, and a powerhouse of a model vendor in Microsoft that has restructured itself to adopt a SDLC that encompasses security as part of the process, so why does it seem that most organizations are so woefully ill-prepared to improve the security of their applications, commercial, internally developed or otherwise?
There is a strong parallel to be drawn between security and quality in the development process. In the early to mid-90’s quality was an afterthought, the demands to capture market share outweighed disciplined quality processes. QA, if done at all, was generally shunned by the developers, ignored by management and not demanded by the market. Of course software was sloppy and the field was not keen on being treated as beta customers and they fought back. Thus an entire industry sprang up around quality and companies like Rational, Mercury and Segue made lots of money. Automated testing tools have matured and it is rare for an organization to develop software without including quality assurance personnel, technologies and processes.
Security, as part of the development process, is where quality was in the mid-to late 90’s. Which means we are at least 2-3 years away from major market adoption. To understand the future of secure development requires an understanding of the evolution of quality as part of the development process. The bottom line, however, is that it will require more than just technology. A cultural shift is needed that supports the integration of security into current development processes. Security needs to be seen as a function of quality and that cultural shift will only occur if a. the market demands it and/or b. regulations require it. No amount of “month of x” vulns will force ISV’s to change though.
There are technologies available today as well as services to address code security, so the ability to identify and resolve security issues has never been easier. Lets dig into the future of some of them.
Web application security scanners provide black box testing of web applications, the equivalent of walking through all the exposed interfaces to check for conditions that could lead to exploit. These tools have primarily been adopted by operational teams and used in production environments. Although the vendors are pushing to have these technologies used by developers as part of the development process, the reality is that the majority of deployments will remain in the production groups for the next 2 years.
Source code scanners, the equivalent of white box testing tools, walk through the code paths to identify conditions that can lead to exploit. These tools are suited for use by developers and are most widely adopted within the development teams, but wide scale adoption is at least 2-3 years out.
Regardless of the ability for these tools to penetrate into development, organizations will require the ability to audit non-COTS applications within the production environment. So the future of web application scanners will be integration with development technologies (source code scanners, defect tracking systems, etc) and operational technologies (workflow, helpdesk, other assessment tools, etc), the tools that provide these capabilities will find it harder to accommodate both paths and will begin to feel the same pressure felt by other tools in the respective spaces, that is assessment technologies used within production and automated testing tools used within development. Large, application tool vendors will deliver source code scanning capabilities as part of their current automated testing bundles, so point solution vendors will face M&A pressure and their competitive landscape will definitely morph over the next 2 years. Web application scanners, and source code scanners, will both find it difficult to compete as point solutions over the next 2-3 years, but I suppose one could make that argument about any IT technology, especially in the security space given the evolution that is underway (here).
Service provider offerings will become more popular as organizations struggle with resource, cultural and security knowledge issues, but they will face the same challenges as product vendors although their runway is 1-2 years longer depending on how well they adopt to support emerging web services standards.
Regardless of market dynamics these tools work today, and the service offerings are expanding. Although they are not a replacement for human analysis they go a long way in providing visibility into the security of applications and automating a large part of the assessment process. They are a must have for organizations that develop internal applications, expose web apps, or outsource development to a 3rd party.
BTW – When I was at Gartner I wrote a series of notes on secure application development and the tools that serve that market, for those of you with access I would recommend “Integrating Security Best Practices and Tools into the Software Development Process” as a starting point.