Part 5 of 5 - Attaining a High Level of SDLC Maturity

To view the previous post in this five-part series, click here.

In order to achieve a high-level of SDLC maturity, an organization needs to define a set of security engineering activities, processes and policies that can be layered on top of whatever development process currently in place. These can be applied in waterfall, iterative, agile or any type of development process. They key is to perform the correct activities and employ the right checkpoints at the right points in your process.

A successful approach to security engineering involves explicit security objectives (aka requirements), a good understanding of the threats to your application, and an iterative approach that allows you to bake security in early and improve security over time rather than trying to add it in at the end.

It can be useful to think of security as yet another aspect of software quality. Just like you think about performance, reliability and usability during software design and implementation, you should be thinking about security at the same time. Security decision may require trade-offs between acceptable risk vs. performance and usability; thus, it makes sense to consider these qualities holistically so that you can make reasonable decisions in context.

Below are five levels of AppSec Maturity (derived from CMMI) and that were included in our joint Ponemon research study on Application Security Maturity. As your organization’s program evolves, consider what activities, skills or best practices you need to adopt in order to get to the next level.

  • Level 1 (Initial)
    • Lack of discipline and maturity in the SDLC; no focus on security
  • Level 2 (Repeatable)
    • Disciplined and repeatable SDLC but security is purely reactive
    • Security is addressed by patching issues based on penetration testing results and public incidents
  • Level 3 (Defined)
    • Security in the SDLC is standardized and defined
    • Corporate application security policies are defined
    • Formal security requirements are defined during the development process
    • Secure coding standards are in place and the code is reviewed to these standards
    • Security testing is part of the normal testing cycle
  • Level 4 (Managed)
    • Predictable process that is measurable and managed
    • Threat modeling is used to assess and prioritize risk in each phase of the SDLC
    • Secure architecture standards are in place and the design is reviewed to these standards
    • Development teams and the code they produce are measured against compliance security requirements as well as secure architecture and coding standards
    • Application security risk is measured and well understood across the application portfolio
    • Third party security audits are conducted for all high-risk applications
  • Level 5 (Optimized)
    • Continuously improving process that is mature and optimizing
    • Risk metrics are used to guide application security decision making
    • Vulnerability discoveries are used to update requirements and standards

Security Innovation offers a free Secure SDLC Self-Assessment questionnaire that consists of twenty questions around tools usage, development team knowledge and security best practices. Upon completion, you will see a plot of where your organization resides on our Application Security Maturity (ASM) graph that consists of three common categories:

  • Panic scramble
  • Pit of despair
  • Security as a business enabler

After the survey you can review recommendations for improvement and you will have the opportunity to view and print all of your answers.

Get a monthly digest of our blog posts