How to measure the maturity of your software product

In this second post of two, we’re carrying on our discussion about how we can measure our security maturity. There are a couple of distinct approaches to this emerging: lifecycle security maturity, and product security maturity.

In our previous post, we dug into lifecycle security maturity and how to get started with measuring it, including how the OWASP Software Assurance Maturity Model (SAMM) can help.

Now, it’s time to do the same with product security maturity.

Our software is less unique than we think

Like it or not, it's incredibly rare — and a bit of a red flag — for us to completely rewrite the book when designing a new piece of software. Our software is made up of features that have been built into thousands of applications before us, and a set of design patterns have emerged.

As well as these patterns for how they should look and function, we’re also starting to evolve security design patterns. These patterns show us what’s needed to secure these common features or functions.

By choosing to follow these patterns, we reduce the complexity of what we build, speed up the process, and often make it easier for our users to understand and use our systems.

Measuring product security maturity

If we accept that design patterns — and security design patterns — are useful, we can also start to use these mechanisms to measure the consistency of our approach. 

In the case of security, this means being able to identify areas of software that commonly introduce risk and identify the common security requirements that should be met to reduce this risk. 

Product security is an approach that measures the security maturity of software by measuring whether common security requirements have been met.

This is a measure of the “as-built” technology implementation of the software rather than the processes that were used to govern its production.

For example, when considering a common design pattern such as authentication, there's a range of common security requirements that can be considered.

Description

• Verify that user-set passwords are at least 12 characters in length (after multiple spaces are combined).
• Verify that passwords of at least 64 characters are permitted, and that passwords of more than 128 characters are denied.
• Verify that passwords of at least 64 characters are permitted, and that passwords of more than 128 characters are denied.
• Verify that any printable Unicode character, including language neutral characters such as spaces and Emojis are permitted in passwords.

(Source: OWASP Application Security Verification Standard)

These requirements identify what needs to be implemented (and then validated) for the risk to be considered reduced. If you implement or meet these requirements, the likelihood of a security incident related to this feature or functionality is reduced.

How to get started with measuring  product security maturity

Much like we saw in our last post about lifecycle security maturity, rather than building your framework, it makes sense to use something already available and best of all, free.

Once again, our friends at OWASP have our back here with the OWASP Application Security Verification Standard (ASVS).

This open-source framework provides “a basis for testing web application technical security controls and also provides developers with a list of requirements for secure development”. 

In short, it gives us a list of common software features and patterns as well as the requirements we need to meet when implementing each of them.

The ASVS project team makes it clear that its framework can be useful in a range of circumstances, including, in their words:

• Use as a metric — Provide application developers and application owners with a yardstick with which to assess the degree of trust that can be placed in their Web applications,

• Use as guidance — Provide guidance to security control developers as to what to build into security controls in order to satisfy application security requirements, and

• Use during procurement — Provide a basis for specifying application security verification requirements in contracts.

(Source: OWASP Application Security Verification Standard)

The ASVS includes a set of controls that relate to most software projects being developed or supported globally. Each of these controls has subsections that list the common security risks and the requirements needed to address them.

This framework also has the concept of tiers that relate to the sensitivity or criticality of the software you’re working on. The higher the tier, the more controls must be applied. This can be great for focusing and prioritizing.

Along with a detailed description of the framework and what it includes, there are a range of downloadable resources — including a PDF and spreadsheet version — available on the main OWASP ASVS page. These can be great for getting into the practical work of assessing and improving rather than spending hours translating the ASVS into something you can use.

Why is measuring product security maturity important?

While the software we’re building may vary in terms of size, complexity, and purpose, there's a range of common features and patterns that we implement to get the job done.

Each of these common patterns has a range of known or likely security risks that we should be aware of so we can be prepared to prevent and detect them.

Product security maturity frameworks like OWASP ASVS help us identify which design patterns will impact us and which controls we should consider putting in place. 

Additionally, by accommodating a range of applications with different levels of risk or criticality, we can fine-tune these requirements, so we’re focusing on the ones we need for the specific context we’re building in or for the specific data that we store.

Product security maturity can allow us to repeatably build common software patterns in a secure way and therefore focus our efforts more on the innovation and features that make our software unique.