Background: Defining the AppSec scope

For AppSec Leads: Dive into the seven domains within the AppSec Ownership Model

There are many measures you can include in your SDLC to make it secure. Within the Application Security Ownership Model, I grouped them into seven domains. This is not meant to be a complete list. It should just enable you to put your measures into the right domain so you can map them to the right owner.

Overview

Within the AppSec Ownership Model we split the AppSec field into seven domains:

1. Secure Design

2. Secure Coding

3. Security Tooling

4. Vulnerability Management

5. Incident Readiness

6. Security Strategy

7. Security Culture

We will now dive into each of them to provide you with a rough idea of what they are about and where to start.

Secure Design

You probably heard about shifting left. This means adding security as early as possible in your SDLC. And the earliest phase is your design phase, so that’s where we start. You probably already learned it the hard way that any big flaws in your design are the hardest to fix later.

Here are some measures you can implement:

• Threat Modeling

• Secure Design Principles

• Security Requirements

If you are dealing with a lot of legacy, start by thinking about security requirements for every new feature and adding them to your acceptance criteria.

Secure Coding

When I studied computer science, security was barely touched upon. I hope this is going to change in the future, but for now companies need to fill the gap. Instead of treating developers as the threat that needs to be controlled, companies should train them properly in secure coding.

• Define guidelines and standards

• Offer continuous training opportunities

• Perform code reviews

It’s easy to tell developers to write secure code, but you need to make explicit what secure means to you. Whatever measures you take, make sure they match developers’ reality, and involve them in developing these standards.

Security Tooling

When I was handed responsibility for AppSec, one of the first requirements was: ‘Find us a good SAST scanner’. While this sounds good on paper, it would have filled backlogs and created a lot of noise, but it wouldn’t have really improved the products.

There are many different tools you could add:

• Scanners (SCA, SAST, DAST)

• Vulnerability Management Platforms (ASPM)

• Runtime Protection (WAF)

Whatever you include, make sure it reduces friction, is properly configured and frees up capacity for feature development. Tools should be added with intention and be included in processes where they actually improve something.

Vulnerability Management

I would go for a proper vulnerability management process first, before adding new tools. Developers are often aware of vulnerabilities or outdated dependencies, but they might have learned that fixing those issues is not a priority.

Define the process and show them that fixing vulnerabilities matters:

• Reduce the noise

• Prioritize what actually matters

• Fix it

Start small. Take the vulnerabilities they already know, establish a process, and add more vulnerability detection afterwards. It’s a never-ending story, so you’d better make it a good habit.

Incident Readiness

No matter how well you are prepared, nothing is 100% secure. You’ll end up firefighting sooner or later. So of course we need to prepare for the worst case:

• Zero-Day Response Process

• Incident Response Process

• Responsible Disclosure Process

Start by defining these processes and clarifying responsibilities. Who should be informed? Who is going to lead the process? If you at least have some plan on paper, you have something to work with when you need it. From there you can improve and train your response.

Security Strategy

With so many measures available, someone needs to have a plan. Developing your AppSec program is pretty individual to your company, but you need for sure some sort of strategy to get where you want to go:

• Set long-term goals

• Fix the current bottleneck

• Measure your progress

As an AppSec Lead, you need to build your network within the company, collect everybody’s needs, wants and struggles, sort through that data, come up with a strategy, and finally take it to your management to make sure your AppSec goals are aligned with their business goals. If they reject your strategy, ask why. Try to understand their goals and adjust.

Security Culture

Maybe the most important long-term goal you should set is to build a strong security culture. If culture works against you, even your best strategy will fail under pressure. Culture is what makes your AppSec program sustainable and resilient.

• Identify ‘bad habits’

• Shape culture with intention and involve everyone

• Build a Security Champions program

While culture change is by far the biggest challenge you can face, it doesn’t need to be painful. You will not change culture in one day, month, or year. But you can start small, build healthy security routines and reward desired behavior. And if something fails? Analyze it and adjust.

There is only one hard criterion under which I would consider this goal failed: if you can’t get the management behind you, you are fighting an already lost battle.

If you are currently looking for guidance in one or more domains, feel free to reach out.