Discover PerformanceHP Software's community for IT leaders // March 2013
Identifying best practices for secure software development
When it comes to secure software development, there are leaders and there’s everyone else. Learn a few secrets of organizations with top-notch security practices.
As part of the software development process, security professionals must make choices about where to invest their budget and staff resources to ensure that homegrown applications are as secure as possible. But not all organizations make the same decisions. What practices set apart the security leaders from those that are merely average—or worse?
The Enterprise Strategy Group (ESG) recently set out to help answer this question. It surveyed more than 300 U.S. companies, classifying each as a security leader, follower, or laggard, based on criteria such as the organization’s perception of the CISO role, executive involvement with information security, and frequency of security controls testing. ESG then asked each company about its internal software development processes and the related activities and methods it uses to bolster software security.
Their responses revealed a few very important best practices for secure application development and testing.
Best practice #1: Train existing staff, outsource where needed
Security management and operations leaders were significantly more likely than their follower and laggard counterparts to provide training to internal developers on secure software development practices. They were also far more likely to hire third-party service providers to test the security of internally developed software.
Together these two practices make for a smart strategy to combat the current security skills shortage. Rather than looking for new talent, security leaders train from within to cover the shortage, and outsource when additional resources are needed.
Best practice #2: Use tools liberally to assist with security scanning and testing
Security leaders are more likely to leverage a variety of tools to make security testing more reliable and integrated into the development process. For example, although leaders don't spend much time on code reviews, they are relatively aggressive when scanning their new applications for vulnerabilities. Leaders are the most likely to conduct black box tests of their applications (scanning for unknown vulnerabilities) and to run on-line vulnerability scans.
Furthermore, leaders are more likely to deploy an integrated development and testing suite to help them develop more secure code from the outset. Forty-seven percent of leaders use an automated testing suite that is integrated with the development environment, as opposed to 42 percent of followers and just 29 percent of laggards.
Finally, as mentioned before, leaders are more likely to rely on managed services to test their software, as opposed to followers and laggards, who tend to rely more on binary and source code checking, rather than a third-party service.
A secure software development lifecycle (SDLC) is a critical component of enterprise security. An SDLC allows companies to identify and correct applications security problems early—during the development cycle, when it is far less expensive to remediate security issues.
Surprisingly, only a very small difference was found among the companies in terms of their adoption of a secure SDLC. Leaders used a secure SDLC 37 percent of the time, followers 35 percent, and laggards 31 percent. With just slightly more than one-third of companies using an SDLC on average, there is room for improvement across the board in the adoption of this preventative methodology.
Rising to the challenge
Today’s enterprises are faced with a rapidly changing threat landscape and a dearth of security experience in the job pool. It’s a difficult combination for those that take secure software development seriously. Fortunately, security leaders offer a glimpse at the best practices worth emulating.
To see more specifics from the ESG research, download ESG’s full security management and operations report (reg. req’d).