Those leading the charge have found the key is to select a few practical activities that can be as simple as a series of small tasks at each step in the software development lifecycle. However, even this approach is easier said than done; the inertia against change can be so great that it is easy to become paralyzed, which prevents security from being addressed sufficiently at any step-not in design, development, testing, nor production.

This document proposes seven practical steps that development groups can employ today to deliver more secure software. Although not a silver bullet, they will generate measurable results in the near term. The key is to start now.

Step1: Quickly evaluate the current state of software security and create a plan for dealing with it throughout the development lifecycle
This step does not need to be a comprehensive, multi-month effort; the best way to start is by simply creating lists of activities currently undertaken those you'd like to implement.

A plan-no matter how brief or short-term-is critical for getting buy-in within the organization, and should address three elements:

• the infrastructure that surrounds each development project,
• specific security activities each project team chooses to undertake, and
• how found vulnerabilities will be managed.

Step 2: Specify the risks and threats to the software so they can be eliminated before they are introduced
Security is all about risk mitigation. Software applications that store customers' private information are more sensitive than an internal application for scheduling conference rooms, so it's a good idea to determine the risk associated with a piece of software and the threats to its safety.

Risk analysis can be found in commercial solutions and standards-based approaches. Although varied in their implementation, these types of approaches involve a significant investment of time. A simpler technique, threat analysis, helps avoid security mistakes in the design and focuses code reviews and testing on the most vulnerable components of the application. Threat analysis can be divided into two phases:

1. Identify the assets of an application that must be protected and evaluate which are most important. This task can be tricky as the nature of assets varies from application to application. Examples include records of private information (e.g. credit card numbers), resources an organization provides to others (e-mail), as well as intangible resources (a company's reputation).
2. Understand the application itself and the dangers it faces from attackers. Organizations should develop a high-level model of the application's components and dataflow paths, map its attack surface and identify interfaces that accept input from users or interact with other systems. Teams should note any points on the attack surface that allow an exploit to compromise the integrity, availability or confidentiality of an asset. Finally, rank the threats based on importance of the asset affected and the likelihood of exploit.