My mission
Yes, you can have both.
Security
As AppSec folks, we need to remember that our role is to serve software development.
The purpose of a company is to create value for its customers. Maximizing security at the expense of the product creates no value.
Security is a means to a greater end.
Resilience
Resilience is security created from within the system. It creates agency instead of dependency.
A resilient AppSec system is built on trust and ownership. Ownership requires self-determination: autonomy, competence and relatedness.
Resilience enables secure freedom.
Freedom
The purpose of AppSec is to create a secure environment for developers to build awesome products.
Developers who have the freedom to use their creativity while taking ownership of product security are a company’s most valuable asset.
Freedom is the ultimate goal.
Two worlds. One mission.
Hey, I'm Anne.
I live and travel full-time in a 27-year-old Chevy Blazer, hunting freedom and adventure while conducting extensive research into resilient AppSec systems. Yes, from the outside my life looks wild.
But these two worlds are deeply connected.
When I built my first AppSec program, I just aimed to understand how our software development worked from a system perspective and what it needs to create secure software.
Eventually, I discovered what worked in reality.
Not in my nice and cozy office.
But by recovering my car from being stuck in deep sand, handling breakdowns, or facing the Arctic winter in Norway.
In both worlds, resilience creates the secure foundation that enables true freedom.
Two worlds. One mission.
Hey, I'm Anne.
I live and travel full-time in a 27-year-old Chevy Blazer, hunting freedom and adventure while conducting extensive research into resilient AppSec systems. Yes, from the outside my life looks wild.
But these two worlds are deeply connected.
When I built my first AppSec program, I just aimed to understand how our software development worked from a system perspective and what it needs to create secure software.
Eventually, I discovered what worked in reality.
Not in my nice and cozy office.
But by recovering my car from being stuck in deep sand, handling breakdowns, or facing the Arctic winter in Norway.
In both worlds, resilience creates the secure foundation that enables true freedom.
How I learned to build AppSec systems
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 system 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 system. 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.
How I learned to build AppSec systems
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 system 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 system. 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.
How I learned that ownership matters
During the first 18 months of building my AppSec system, 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 that a resilient AppSec system is grounded in ownership.
How I learned that ownership matters
During the first 18 months of building my AppSec system, 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 that a resilient AppSec system is grounded in ownership.
My working principles
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.
