Security Requirements Engineering – The Backbone Of Your SSDLC


In secure software development, not all security activities are born equal. That is especially true when it comes to security requirements engineering.

SSDLC Deepdrive main blog image - SEC Consult

Security requirements done right will serve you in many ways. They can provide a frame of reference for almost every other security activity, ensure a harmonized approach across the whole development lifecycle, and help you make the right decisions even in turbulent times.

A guest article by Thomas Kerbl, Principal Security Consultant at SEC Consult in Vienna. Follow him on Twitter @dementophobia for updates on this topic. This article is part of the Secure Software Development Deep Dive series.


While security requirements engineering is such a powerful tool, it is also hard to master. Establishing a process that reaches deep into so many other processes and activities is often met with resistance throughout the organization. And more often than not, a company just starting out with secure software development has not built the required skill set yet, to fill the position of the security requirements engineer.

In this article I will show you how to get started with security requirements engineering the right way. Following this advice allows you to take the first steps and establish a solid foundation. The next article in this series will built upon this foundation and show you the road to mastery.

To conclude this introduction, I will also share the most common mistake made when implementing security requirements engineering. Avoiding this pitfall will protect you from getting stuck at a low level of maturity longer than necessary.

The power of security requirements

The importance of security requirements might be underestimated when you first work with OWASP SAMM. Isn’t it just one out of fifteen security activities defined in the model?

SSDLC SAMM Model image - SEC Consult

On paper, I do agree. But once you take a closer look, it becomes obvious, how far reaching their effect is. Most of the activities in the later stages of development will refer back to the security requirements. How resilient must my security architecture be? What do I have to consider when building and deploying my application? Which security tests do I have to run? What are the parameters for secure operations? Should I patch fast or rather test new patches more carefully before applying them?

If you did a good job defining your security requirements in advance, you will be able to answer those and many more questions easily and consistently when they arise. It pains me to see organization struggling to make the right decision because they neglect the importance of security requirements as their main point of reference.

But we shouldn’t get ahead of ourselves. This idealized scenario I am painting here shows the potential of a fully integrated security requirements engineering process at a high maturity level. If you are just starting out, you need to build a solid foundation first before you can utilize the full range of capabilities of your security requirements engineering activities.

Quick wins to kickstart the security requirements engineering process

For those of you who are at the beginning of this journey, I assembled four tips and tricks that have helped other organizations getting started with security requirements engineering successfully.

1) Respect the fundamental principles of good requirements engineering

Requirements engineering is an established craft. Nevertheless, many organizations seem to forget about the fundamentals once security gets involved. I am an advocate for integrating all your security activities into your established development processes, and this holds true for security requirements engineering. Security requirements must follow the same strict guidelines all other requirements have to adhere to.

Requirement define What to do, not How to do it. They must be specificmeasurable, and reasonable. I could go on and on, but you’ll find those fundamentals in any good book about requirements engineering. Don’t throw them overboard when writing down your security requirements. Badly written security requirements are often ignored or misinterpreted later on. Avoid this trap and stick to your best practices.

Badly written security requirements are often ignored or misinterpreted.
Thomas Kerbl, SEC Consult Group Avoid this trap!

2) Use the OWASP ASVS as inspiration for your first security requirements

“Wait, what? The Application Security Verification Standard? But that is a guideline for security tests, not requirements engineering!”

Good catch, you are totally right. But it is nevertheless one of the best tools you can use to get into security requirements engineering fast. It is a very comprehensive and also well-structured standard, which makes it easy to navigate.

This works because we are using a dirty little trick, bending the process to our needs. In a perfect world, security requirements are supposed to be the source of security test cases. But remember, we are just starting out and are looking for reasonable shortcuts. The ASVS is a collection of well researched and established security test cases already. Why not go the other way round and try to derive useful security requirements from them?

Let’s look at an example. The current stable release of ASVS is version 4.0.1. Security verification requirement with ID 3.1.1 states:

Verify the application never reveals session tokens in URL parameters or error messages.

The initial question should be whether that is even applicable. Are you developing a type of application that uses URLs? Und are you using session tokens? Assuming we are talking about a web application with different users, chances are high that this is the case. So, let’s formulate our underlying requirement:

The application must not reveal session tokens where they are at risk of leaking to a third party (e.g. in URL parameters or error messages).

I took the liberty to formulate the requirement in a more generic way to catch a broader range of cases, but you can always go the easy route of simply changing “Verify …” to “Ensure …”. Just keep in mind that test cases tend to be a little more specific and aiming for a broader requirements definition is usually a good idea. The right way to do this would be the other way round; starting with the actual requirement and deriving a set of test cases to verify its implementation.

Please keep in mind that this is a shortcut to kickstart security requirements engineering and there will be many important aspects you are missing that have to be added later on to reach a high maturity level. You will probably miss application-specific security requirements, requirements based on policies and compliance, and you won’t have included any domain specific knowledge. But at least you dipped your toe in the water and got the ball rolling.

3) Implement proper verification of all security requirements

As I have mentioned before, security requirements have to be addressed in all stages of development. But in the early stages of integration, this might seem overwhelming; especially if you meet resistance in your organization. Instead of forcing the integration right from the start in all other security activities, I recommend easing into it with proper verification. Once people see how they can contribute to passing such a quality gate, they are usually more open to change.

I’ve witnessed this phenomenon far too often. Requirements are treated as strict rules that have to be follow. But call them “security requirements” and everyone starts to consider them as optional. As soon as this takes root, all the effort invested into designing proper security requirements is more or less wasted. Do not allow this to happen!

Make sure to enforce at least one quality gate that includes verifying the implementation of your security requirements. One important property of a security requirement is its testability. Use this to your advantage! The correct way of implementing proper verification early on depends on the culture of the organization. I have seen organizations having great success implementing this as a final acceptance test, for others it worked way better as regular team meetings reviewing the level of implementation together. Whatever works for you; the goal is to hold the responsible people accountable for implementing your security requirements with the same rigor as any other requirement.

Later on, when you have reached a higher maturity level, this will become more formalized, but to set the mindset straight right from the start, this can be a healthy method to drive home the importance of security. I have seen companies making solid improvements throughout the whole SSDLC just by implementing mandatory security review sessions. This kind of organic growth is exactly what you are looking for, especially when you are just starting out.

4) Ensure vendors follow the same security guidelines that you are committed to

Vendor management is such an important topic when it comes to security, that I will dedicate a full article to this topic in this series later. Nevertheless, it has to be mentioned in the context of security requirements engineering as well, even if just briefly.

Your security requirements define a security baseline for the application you are developing. But what happens if parts of your application are developed by a vendor? This might be a third-party framework, a micro service, or any other software component your application relies on. Shouldn’t they follow the same guidelines?

Well, of course they should! An attacker doesn’t care whether the broken part of your application has been developed inhouse or not. A vulnerability is a vulnerability, no matter who is responsible for this quality issue.

The root of any vulnerability is a quality issue in the underlying software development process.
Thomas Kerbl, SEC Consult Group

That’s why you have to ensure that your vendors follow the same security guidelines as you. Failure to do so will probably leave you with insecure third-party software that puts your whole application at risk and violates your compliance obligations.

I will dive into the best practices of vendor management from a security perspective in a future article, so stay tuned.

Common mistake: Relying solely on vulnerability classes to avoid

There are many mistakes to look out for when starting out with security requirements engineering but relying solely on vulnerability classes to avoid for your security requirements is the most common one. It is the Dunning-Kruger effect in action.

Dunning-Kruger effect in action image - SEC Consult

One of the first things people stumble upon when researching security are the OWASP Top 10. And that’s good, because the OWASP Top 10 are a great tool if used correctly. They represent a broad consensus about the most critical security risks to web applications. Understanding them and considering them during development is highly recommended.

But this does not mean that slapping a link to the OWASP Top 10 (or a similar list of vulnerability classes) into your requirements document can replace proper requirements engineering. That’s why I was a little hesitant to include the ASVS as inspiration for security requirements in the Quick Wins section above. Using generic sources for requirements can be helpful but many organizations get stuck in the illusory superiority zone of the Dunning-Kruger effect and never make it past this initial stage, leaving a lot of potential unused.

Summary and next steps

We covered a lot of ground in this article. We have learned about the importance of proper security requirement engineering and saw some tips and tricks to get started with this security activity in your secure software development lifecycle. We also discussed a common mistake that organizations make, leaving them stuck at a low level of maturity without realizing the lost potential.

After establishing the fundamentals of requirements engineering and communicating their importance and value, the next step is building upon those successes and aiming for a higher maturity level. This will be the main topic of the next article in this series. In addition, we will use our quality level matrix to help you decide whether your security requirements engineering process is fit enough for the protection profile of your applications or you have to up your game.

Was this article helpful to you? Are there any specific questions you would like to see answered in the next one? Let me know on Twitter and I will try to fit your preferred topic into the next release!

Click here to get to the complete SSDLC Deep Dive blog series.

More On The Topic

About the author

Thomas Kerbl
Thomas Kerbl
SEC Consult Group
Principal Security Consultant

Thomas has worked as a security consultant at SEC Consult for over 15 years. In his role as principal security consultant and team leader, he does not only lead a team of experts, but is also still involved in customer projects hands-on. Currently he is engaged in projects concerning “Secure Software Development” and “Security Architecture” where he incorporates his experiences as a former penetration tester and security requirements engineer.