Many information security problems can be traced to coding flaws. That's not news, yet many of those coding flaws continue to appear in programs year after year.

Why does that happen? As cut and dry as coding can be, there's still a lot of art involved in the process. Whenever art enters the picture, so does inconsistency because every programmer has their own approach to how they code. That can make code review during an application's lifecycle challenging to both developers and security teams, who often are at odds with each other because they have different priorities.

Developers want to create apps with cool features, meet development deadlines and minimize the time it takes to bring their software to market. On the other hand, security teams want to make sure an app isn't vulnerable to malicious attacks when it's released. Moreover, security teams typically don't have members with coding backgrounds, which can create communication problems between the two groups.

Conflicting priorities or not, the growing problem with information security -- the latest figures from the Identity Theft Resource Center show in the first nine months of this year alone, there were 708 breaches exposing 28.8 million records -- has persuaded many organizations that they need to step up their security game.

One way to do that is to create more secure apps. And the best way to do that is to add security activities to all phases of the software development lifecycle (SDLC).

Brass Buy-In

Integrating security and risk management into the SDLC, though, can seem daunting to an organization. "Where do we even start to do this?" it may ask itself. One place to start -- as is the case with most major initiatives in organizations -- is with upper management buy-in. In addition to giving the SDLC security program gravitas, upper management support can resolve conflicts between developers and the security team and align business and security goals so they complement each other. For example, time will have to be added to an app's project plan to accommodate security. For organizations with a desire to rush apps to market, that may not sound very appealing, but that extra time can amount to added value for the app. A popular rule of thumb often cited is $1 spent on security can save $10 during development and $100 after release. Upper management support can also remove friction between security and development groups through training that enables them to understand each other's needs. That's especially true for members of the development team who may have some fear and uncertainty about security because it's alien ground for them.

What's more, training everyone involved in the various stages of the SDLC -- developers, testers, architects and others -- in software security principles can save money by fixing problems at the right place by the right person.

Along with training, support is one of the cornerstones of an SDLC security program. Changing the ingrained behavior of developers and getting them to acquire good security habits is challenging enough, but it will be even more challenging without the allocation of the processes, tools and mentors to help development teams deliver secure software on time.

Small Steps for Big Results

After obtaining executive support, organizations embracing SDLC security will typically start with penetration testing and code review. Those tasks can be implemented with relative ease because the tools for performing them are well-known and readily available in the industry. Moreover, those tasks can often be automated or easily integrated into the SDLC. Tools for source code analysis are usually linked to bug tracking and reporting schemes so security problems will automatically be brought to the attention of the development team where the issues can be fixed before the code is sent to Quality Assurance or production. Many of the tools can also be tied to Integrated Development Environments, such as Eclipse and Microsoft Visual Studio, so making iterative fixes during the coding cycle can be done quickly and within ordinary workflows.

Whenever a change appears intimidating, it's best to approach it in small steps. That's true for adopting an SDLC program, too. For instance, a routine code scan can be added as an automated step to the nightly build process. Another small step could be adding a scanning "toll gate" at the end of each phase of the project. To pass through the toll gate, all critical vulnerabilities uncovered by the scan would need to be fixed. Divvying up the burden of the SDLC security process can also make it less onerous. The Quality Assurance team could act as an intermediary between the security folks and developers. In some cases it might even make sense to have the development team do the static analysis of an app's code and the QA and security teams do the dynamic scanning of it.

Incorporating security into the SDLC may be challenging, but those challenges can be surmounted. All it takes is cooperation and commitment.