After conducting hundreds of application security assessments, it is not difficult to identify strong correlations between highly secure applications and the practices that are used to build them. Currently, there is a strong emphasis on the need for application security assessments and testing in the business world. While this is a positive sign of increasing awareness of application risk, this awareness seems to focus almost solely on conducing post-development assessments.

Here is where we find a gap that, if resolved, can save businesses a significant amount of money and effort in the form of increased efficiency and reduced operational risk. Assessments are a fundamental necessity for identifying and managing risk of an application.  But by that definition, these efforts are normally conducted on applications that have already been built and do not reduce the number of security problems built into the application during development. This approach tends to promote the dangerously common “build it first, secure it later” mentality that can make security appear to be a very high-cost and painful check box on the deployment checklist.

Our experience shows that by considering and applying security practices earlier in the Software Development Life Cycle, fewer security flaws and exposed vulnerabilities reach the testing and deployment phases. Software giants like Microsoft and Oracle also agree and have recent results that prove this is not a just theory but an approach that significantly reduces risk and provides a strong return on investment for application security efforts. The alternative is developing an application that, after being built, is diagnosed with a large number of vulnerabilities or systemic security problems that require a significant re-write of code or even a re-design effort. At the risk of stating the obvious, most organizations would rather build it right the first time rather than use a trial and error approach, especially when security is on the line.

How does an organization apply security early in development to reduce the problems down the road? The answer is to take a hard look at the process that creates the application: the SDLC.  I make the analogy in our training events that you can't expect an apple tree to grow bananas. In the same way, you can't expect a development process that has no security practices and principles built into it to produce secure applications. The goal then, is to design a development process that creates secure applications.

Software Development Life Cycles differ widely from organization to organization, but the first step is to commit to having a defined process that takes applications from concept all the way to deployment and ongoing maintenance. While this sounds obvious, some organizations have such a loose development process that it would be difficult to apply security practices and checkpoints to it.

Having a defined SDLC, key components must be added to provide security throughout the various phases. Organizations starting from ground zero will want to prioritize the implementation of these new security practices and implement them incrementally. This allows adoption of the new practices to take root and provides time for development teams to work out the details of the new activities without causing too much chaos.

Based on our experience, the top three SDLC security activities that provide the highest security value for the effort are:

1. Education: application security training for architects and developers
2. Threat Modeling: starting in the design phase
3. Developer Security Tools: security tools geared for developers, used during development

Adding tasks such as these to the SDLC will make a quantum leap in security by putting risk-reducing efforts into proactive mode. While assessments are a critical part of managing risk, activities such as these three dramatically reduce the number of security weaknesses and vulnerabilities that are built into an application from the start.

Education enables developers to be an active part of the daily development security process first by making them aware of threats and pitfalls, and further, by providing best practices to apply to design and development.  Threat modeling is an exercise conducted by developers and security personnel that identifies a range of threats against the application during the design phase.  This enables the development team to design and code against these threats as part of the normal development process. Finally, there are a number of valuable tools that can provide immediate feedback to developers as they're coding. Like unit testing tools, security tools such as static code review utilities and milestone vulnerability scanners can identify coding flaws early in the SDLC.  The cost savings of fixing coding flaws in the development phase instead of later phases (such as testing or deployment) is significant.

In summary, embedding security practices in the SDLC allows a proactive approach to application security that saves organizations time and money. It also avoids a reactive approach that can cause design and coding flaws to eat up maintenance development costs for managing risk. If your goal is to develop and deploy applications with a solid security posture and low risk, look at the root of the application: the SDLC