Securing the bigger picture: Lifecycle security maturity

What came first: security built into your software development lifecycle or security built into the design and implementation of your code?

When we talk about application security, there are two distinct camps emerging — lifecycle security maturity and product security maturity.

Over our next couple of posts, we’ll dig into both approaches and show you how to start measuring and maturing your security. We’ll also share some open-source resources you can use to make your life easier.

First up, let’s dive into measuring the security of our software development lifecycle.

Moving beyond leading indicators to systematic maturity

As we discussed when we looked at leading indicators for application security success, measuring our progress and effectiveness is essential to helping us improve and refine our approaches. 

While measuring maturity and achievement is good for motivation, it also helps us keep a critical eye on what we’re doing. There’s no point investing time and money in a problem if we’re not progressing or our applications remain vulnerable.

As well as identifying these leading indicators that are specific to our context and operating culture, there are tools and frameworks we can use to measure maturity at both the product and lifecycle levels consistently.

Measuring lifecycle security maturity

When we talk about lifecycle security maturity, what we’re really looking at are the ways in which we include or consider security throughout our software development lifecycle. 

From idea through to design, implementation, deployment, and maintenance, there’s a role for security to play at each stage — and the more consistently we put this into practice, the more likely we are to avoid security issues.

To put it simply, lifecycle security maturity is making sure that all team members are considering security at every stage of our software’s life.

What does that mean in the context of our day-to-day work?

In the following table are some examples of security activities that we can include in our software development process — either as automated tools or manual tasks.

In addition to these lifecycle activities, this maturity measurement also includes the parts of our companies that operate culture and processes that can impact security.

Here are some examples.

How to get started with measuring lifecycle security maturity

Though there are many ways to approach this problem, the OWASP Software Assurance Maturity Model (SAMM) is a great place to begin. 

This open-source framework provides “an effective and measurable way for you to analyze and improve your secure development lifecycle.”

The nice thing about SAMM is that it's one of the OWASP flagship projects, and it has an active team around the world working to improve and refine it. It supports the complete software lifecycle and is technology and process-agnostic, which means you can apply it to any project you’re working on now and in the future.

For a detailed description of the framework and what it includes, plus a range of resources and guides for applying it to your organization, check out the OWASP SAMM Implementation Guide.

Top tip

There is a range of downloadable resources — including a PDF and spreadsheet version — available on the main OWASP SAMM page. These can be great for getting into the practical work of assessing and improving rather than spending hours translating SAMM into something you can use.

Why is measuring lifecycle security maturity important?

Software development lifecycle security maturity is a type of leading indicator. 

By having security consistently applied throughout the SDLC, we’re increasing the chance that vulnerabilities will be avoided or identified early.

While the code may change from day to day, our SDLC will always be checking for common issues and giving us chance to act — before the code is deployed.

It’s also a great opportunity to include legacy projects in our security approach. 

Many product-focused security approaches change based on language, framework, or age of code — purely as a result of what the technology allows or requires you to do. 

In contrast, lifecycle security doesn’t care what you implement your project in — just that you take measured steps along the way to prevent and detect issues.