Your AppSec Guide
Where classic consulting keeps AppSec stuck
Borrowed capacity
Outsourcing can make things move faster for a while, but it does not make your AppSec program stronger. The work gets done externally, while the knowledge and decision-making capability stay outside your organization.
You fail to build internal capability.
Externalized responsibility
External support can create momentum for a while, but momentum built on outside pressure does not last. When someone else keeps pushing, reminding, and following up, teams do not learn to carry the responsibility themselves.
You fail to build internal ownership.
Generic solutions
When support relies soley on a predefined framework, your program gets pushed into a model before your terrain is understood. You will see progress, but only measured against the framework, not your actual reality. Your effort gets lost in complexity.
You may fail to solve the actual problem.
How I learned to read the terrain
My road into cybersecurity was a bumpy off-road trail, fueled by curiosity and a stubborn drive to fix real-world problems. Somewhere along the way, AppSec responsibility was handed to me like a hot potato: a rough roadmap, no team, and a simple instruction: “Go fix it.” So I did. Over the next four years, I built an AppSec program from scratch inside a German software company with several hundred employees, including its security champions program.
That meant working with developers, project leads, operations, the CISO, and executive management. It also meant learning how differently these roles think, decide, communicate, and define success.
I learned AppSec the hard way: by getting my hands dirty.
Before AppSec, I spent five years as a software developer: first at a 50-person company, where I later took a detour building its privacy management system. Second, in the company where I later built the AppSec program. That way I gained insight into two very different companies from both angles: the development view from inside the team, and the management view.
That is why I treat AppSec as a system that has to work across people, priorities, processes, and constraints, not just as a stack of tools, policies, or isolated measures. Compliance was never the goal, but the program still held up well in every ISO 27001 audit.
How I learned to read the terrain
My road into cybersecurity was a bumpy off-road trail, fueled by curiosity and a stubborn drive to fix real-world problems. Somewhere along the way, AppSec responsibility was handed to me like a hot potato: a rough roadmap, no team, and a simple instruction: “Go fix it.” So I did. Over the next four years, I built an AppSec program from scratch inside a German software company with several hundred employees, including its security champions program.
That meant working with developers, project leads, operations, the CISO, and executive management. It also meant learning how differently these roles think, decide, communicate, and define success.
I learned AppSec the hard way: by getting my hands dirty.
Before AppSec, I spent five years as a software developer: first at a 50-person company, where I later took a detour building its privacy management system. Second, in the company where I later built the AppSec program. That way I gained insight into two very different companies from both angles: the development view from inside the team, and the management view.
That is why I treat AppSec as a system that has to work across people, priorities, processes, and constraints, not just as a stack of tools, policies, or isolated measures. Compliance was never the goal, but the program still held up well in every ISO 27001 audit.
How I learned that ownership matters
During the first 18 months of building my AppSec program, we had to deal with two critical zero-days: Log4Shell and Spring4Shell. Both hit the software world hard, but our own experience with them was completely different.
When Log4Shell happened, an internal message on Friday afternoon made me believe things were taken care of. By Monday, I realized I was wrong: the process was not as clearly defined as I had assumed.
Four months later, on a Wednesday, rumors about Spring4Shell started spreading. This time, I was alarmed. That same evening, two developers reproduced the exploit in our environment. “Ok, this is real.” While the team worked on a patch, I started identifying affected projects, contacting project leaders, and coordinating the unusually high number of parallel deployments needed.
When Spring4Shell was officially confirmed on Thursday afternoon, we had already patched around 80% of affected projects on our list.
By Friday noon, we were done. This time, responsibility was clearly distributed, so everyone could own their part and handle the situation smoothly. Later, we formalized the process.
Experiences like this taught me what makes AppSec work in the real world.
How I learned that ownership matters
During the first 18 months of building my AppSec program, we had to deal with two critical zero-days: Log4Shell and Spring4Shell. Both hit the software world hard, but our own experience with them was completely different.
When Log4Shell happened, an internal message on Friday afternoon made me believe things were taken care of. By Monday, I realized I was wrong: the process was not as clearly defined as I had assumed.
Four months later, on a Wednesday, rumors about Spring4Shell started spreading. This time, I was alarmed. That same evening, two developers reproduced the exploit in our environment. “Ok, this is real.” While the team worked on a patch, I started identifying affected projects, contacting project leaders, and coordinating the unusually high number of parallel deployments needed.
When Spring4Shell was officially confirmed on Thursday afternoon, we had already patched around 80% of affected projects on our list.
By Friday noon, we were done. This time, responsibility was clearly distributed, so everyone could own their part and handle the situation smoothly. Later, we formalized the process.
Experiences like this taught me what makes AppSec work in the real world.
Why I work differently
I built my whole life around independence.
I packed my life into a 1999 Chevy Blazer and built it around ownership, self-sufficiency, and the ability to keep moving when things get rough. That is overlanding to me: not just traveling, but carrying your own system, understanding it, maintaining it, and taking responsibility when something breaks.
It is not always comfortable. I am one of those slightly unreasonable people who drive to the North Cape in winter and car camp at -28°C with a Chinese diesel heater. That kind of life teaches you very quickly what resilience actually means. Not as a nice word on a slide, but as something you need when the weather turns, the road gets rough, or your setup suddenly becomes the problem you have to solve.
That’s why I center my AppSec support around independence.
I do not want to become the person your program needs in order to keep moving. I want you to understand your own terrain, carry your own responsibility, and build the judgment to make better decisions without waiting for someone outside to take the wheel. My working principles are rooted in that same lifestyle.
Why I work differently
I built my whole life around independence.
I packed my life into a 1999 Chevy Blazer and built it around ownership, self-sufficiency, and the ability to keep moving when things get rough. That is overlanding to me: not just traveling, but carrying your own system, understanding it, maintaining it, and taking responsibility when something breaks.
It is not always comfortable. I am one of those slightly unreasonable people who drive to the North Cape in winter and car camp at -28°C with a Chinese diesel heater. That kind of life teaches you very quickly what resilience actually means. Not as a nice word on a slide, but as something you need when the weather turns, the road gets rough, or your setup suddenly becomes the problem you have to solve.
That’s why I center my AppSec support around independence.
I do not want to become the person your program needs in order to keep moving. I want you to understand your own terrain, carry your own responsibility, and build the judgment to make better decisions without waiting for someone outside to take the wheel. My working principles are rooted in that same lifestyle.
Understand the system
I treat AppSec as a complex system that lives inside another complex system: your organization. Reducing friction means shaping culture.
Make expectations explicit
I dig deep to uncover implicit expectations and turn them into explicit, commonly agreed standards. That creates the foundation for real ownership.
Optimize before investing
Throwing more money at the problem rarely fixes it. I first look for pragmatic fixes in what is already there, so new investments can create real impact.
Encourage critical thinking
I expect people to think for themselves. Instead of fixed instructions, I create room for honest, open discussions. That is how internal capability is built.
My repair manual for AppSec
Like many AppSec Leads, I was responsible for building a program with few resources compared to the size of the development organization. I quickly realized that I could not solve AppSec alone. If I wanted others to carry responsibility, I first had to make explicit what I expected from them.
The AppSec Ownership Model grew out of my own practical experience. I asked myself: Who is involved in building secure software? What responsibility needs to be distributed? Who can actually carry what? And what should explicitly not be expected of them?
First: Clear responsibility is the foundation for ownership.
The model serves as a blueprint for where responsibility should sit and as a reference against which I assess AppSec programs. It is not final. I continue to sharpen it through my daily work and in exchange with other AppSec Leads.
But clear responsibility alone does not create ownership. It only creates the conditions for ownership to emerge. Whether people actually take it depends on culture.
Second: A strong security culture reduces friction so people can take ownership.
If you want to apply my approach to your AppSec program, start with the Terrain Check.
My repair manual for AppSec
Like many AppSec Leads, I was responsible for building a program with few resources compared to the size of the development organization. I quickly realized that I could not solve AppSec alone. If I wanted others to carry responsibility, I first had to make explicit what I expected from them.
The AppSec Ownership Model grew out of my own practical experience. I asked myself: Who is involved in building secure software? What responsibility needs to be distributed? Who can actually carry what? And what should explicitly not be expected of them?
First: Clear responsibility is the foundation for ownership.
The model serves as a blueprint for where responsibility should sit and as a reference against which I assess AppSec programs. It is not final. I continue to sharpen it through my daily work and in exchange with other AppSec Leads.
But clear responsibility alone does not create ownership. It only creates the conditions for ownership to emerge. Whether people actually take it depends on culture.
Second: A strong security culture reduces friction so people can take ownership.
If you want to apply my approach to your AppSec program, start with the Terrain Check.
