Observed Secure Software Development Stages

A secure software development process cannot be built overnight. Organizations gradually adopt security activities based on factors like culture, customer demand, regulations, budget, and security incidents. Each organization adds security practices at different rates; however, most organizations do so in a predictable order. This common order is a reflection of how businesses today use trial and error to find an appropriate set of processes and practices to grow a secure development process.

This order can be broken down into six stages. While few organizations fit exactly within one stage or another, this model can be used to facilitate discussions about an organization’s current progress. The model does not seek to validate whether the six stages constitute an appropriate secure software development roadmap, instead; it simply describes a common progression observed in organizations today. Models like the Software Assurance Maturity Model (SAMM) and Building Security In Maturity Model (BSIMM) are more appropriate models for determining the proper direction of an organization’s secure development process.

Stage 1: Focus on Functionality

Initially, organizations are fairly ignorant of secure development practices. Computer science curriculum often does not include a class on security best practices or ways prevent cross-site scripting vulnerabilities. Developers are taught how to write code to satisfy business requirements.

Secure software development also isn’t high on executives’ list of priorities. Their focus is on producing innovative products or services, being first to market, and making net income goals.

Security usually does not become a priority until an incident occurs, whether a competitor has a data breach or the organization itself is hacked. Once this tipping point occurs, security dollars quickly become available. Organizations spend their new security budget on third-party application assessments, which provide an insight into the security posture of information technology assets.

Stage 2: Assessments Alone

Once an organization starts performing security assessments in response to a breach, it typically extends this activity for use as an approval mechanism. The organization requires sensitive or business critical applications to be assessed prior to new releases being deployed to production. This approach greatly reduces the number and severity of vulnerabilities in external facing applications; however, it doesn’t identify security weaknesses until after the application is fully developed.

Vulnerabilities that highlight a systemic weakness or architectural flaw will often result in project delays and unanticipated costs. Additionally, this approach does not train developers to implement code securely during the initial development stage.

After performing assessments as the only software security activity, the organization eventually realizes that a proactive approach is needed. They determine that issues should be identified early in the development process and opt for purchasing automated code review or penetration testing tools.

Stage 3: Ad-hoc Use of Security Tools and Activities

After providing automated code review or penetration testing tools to developers, organizations expect all their application security challenges to be solved. They tell developers that they need to run the tool on their code and fix all the issues. The organization’s goal is to have production ready software at the conclusion of the development process. The actual results of this approach vary.

Development groups composed of security savvy members usually see an overall reduction in vulnerabilities. The other development groups may only see a moderate impact. There are a variety of reasons this happens. The primary reason is that the tools can identify plenty of problems, but the developers don’t have the knowledge necessary to understand all the risks or to apply security best practice recommendations. Other challenges include the inability of automated tools to find business logic, authorization, and authentication flaws; inconsistent company procedures and checkpoints associated with running the tools; and no minimum standard set for acceptable risk levels.

Organizations also may adopt security activities such as threat modeling, secure requirements specification, and design reviews. These activities produce greater awareness of security issues facing applications, but the developers’ still lack the knowledge and experience necessary to really take advantage of these proactive security activities.

Stage 4: Application Security Training

The next logical step for organizations is to provide application security training to development groups. This comes in the form of in person classes, on-boarding training, and annual refreshers. The class content often includes a general background in application security, introduction to common vulnerabilities and attacks, and best practice approaches for eliminating preventing and remediating issues.

Application security training greatly improves developers’ ability to succeed at the organizations continued use of automated tools and third party assessments. Developers gain a common language to discuss application security concerns, can understand and address vulnerabilities in a timely manner, and the training can inspire developers to pursue additional research.

One aspect most organizations leave out is reinforcing and supplementing training with internal resources. Many developers receive training once a year in application security. After six months, most of the knowledge gained during the class is forgotten.

Stage 5: Creation of Resources, Formal Policies, Procedures and Standards

In order to ensure consistent use of security tools and activities, organizations choose to formalize the policies, procedures, and standards developed over the previous four stages. Criteria is created for evaluating the sensitivity or importance of applications, security activities are formally required for each of these categories, and security gates are put in place to ensure a minimum standard of security is met before software advances in the development process.

An internal application security portal is also created to make these policies and additional resources available to developers. These resources communicate information about standardized methods for addressing vulnerabilities in code, approved development languages and frameworks, and internally developed secure libraries and architectures.

Ultimately, this results in the elimination of ad-hoc security activities and promotes consistent development of applications with fewer security vulnerabilities.

Stage 6: Secure Software Assurance

In the last stage, organizations tailor security activities and requirements to satisfy business goals and leverage efforts as a competitive advantage. Before an application is developed, a set of security requirements is established. For each security activity, the organization defines a test procedure and criteria for determining whether the application passes or fails the security requirement. Test results are recorded and reported across the application’s lifetime to form an overall picture of the application’s security posture.