But I couldn’t even apply to study nautic, because I had not done the required internship on a ship. Now I would need to wait for one year, do the internship and apply.

Until then, I had to do something. But what?

I had always been good at math, but had no idea what job I could work with a degree in Mathematics. “It’s just for one year. Don’t overthink it.” So I started to study Computer Science.

Over the year, doubt crept in. I would have finished my studies before I could even know if I'd pass the fitness for sea service examination. Without it, my study would not be useless, but I would have had to pivot from a nautical to a technical role on board. Not my desired outcome...

Somewhere along the way, I dismissed the dream of becoming a captain at sea and found a new North Star in becoming a pentester. After my bachelor’s degree, I couldn’t find a role that would let me practice on the job, so I ended up in software development.

I was disappointed. Being a software developer seemed to be a total waste of time and my goal was far out of reach.

But when I attended my first local security conference, I talked to a red teamer who completely changed my perspective. He said, “a lot of junior pentesters struggle, because they lack the basics. They have never developed software or administrated servers.” That’s exactly the two things I was currently wasting my time on.

Maybe it wasn’t a total waste?

Embrace detours

It’s basically like driving on a highway. Everything looks good and smooth on the map, but when you go out in reality, you may get stuck in traffic jams or roads might be closed entirely. Sometimes the detour is necessary. Sometimes it’s even faster than following the original track. You can complain about it or you can just embrace it and maybe discover your new favorite restaurant, enjoy the awesome views along the way and maybe even meet the love of your life?

I had chosen a path when I signed up for my Master’s degree in Applied IT Security and started working as a software developer to be able to pay for my studies. It was not the straight route into pentesting I had wished for, but at least I was roughly moving in the right direction. Following my new North Star.

Knowing the experience I gained as a software developer was useful changed everything for me. Suddenly, there was meaning in the job I previously just did to earn money and keep moving. The experience gained was valuable. It started to be fun.

When we stop complaining and start to view detours as opportunities, are they still detours or do they eventually become important milestones on our path?

So when I was offered a new role to build the company’s data protection management system from scratch, I just asked one question: does this sound like a good new experience? Will it likely teach me new skills? Will it make it more likely to land a job in security? After 3.5 years in software development, it was time for something new, so I accepted another detour.

Turn on dead ends

My role as data protection coordinator didn’t turn out to be as much fun as I wished. I was no longer motivated. After 1.5 years, it had become the boring meaningless job I never wanted. I had been applying to junior pentester roles, but without practical skills, I couldn’t land a job. At least, I got the best rejection I could have imagined: a list of topics I should learn before applying again.

Until then, I had to stay on my path. My company had paid for my studies and I would have had to deal with student debt if I left too early. It sounded reasonable to stay and count down the months, until I was free to go. I was caught in a dead end.

Today, I would like to thank my former boss for kicking me out of my comfort zone. I spare you the details, but being no longer allowed to take my dog to work on top of a meaningless job was too much. “Fuck that debt. I have to leave. NOW.”

So within a few weeks I switched companies and got back into software development. Here I was, back where I started. We found a good solution for the debt and everything was not as bad as expected. Most importantly, I was moving again. And my dog was back in the office! #wuff

Today, I’m at peace with this dead end. It taught me valuable skills I just didn’t know I would need today. But the most important lesson is maybe, that we need to accept dead ends for what they are, get aware when we are trapped, step back, and move on.

Stand up for yourself

Back in a developer role, I was still committed to becoming a pentester, but not really acting on it. Until one day, I learned that most of the team would go to JavaLand and I wasn’t invited. I was pissed off.

Sure, I understood, that they had asked for it. I hadn’t. And someone needs to stay and work on the customer project in case something bad happens and needs to be fixed ASAP.

After a night of sleep, I caught myself. That was stupid. I just wanted to have fun for three days on the conference. But how would bring JavaLand me even an inch closer to becoming a pentester? This was an opportunity to ask for something that would actually move the needle for me.

In the end, I made a deal to earn my first pentesting certification (eWPT). I would have preferred starting with network pentesting, but as web application pentesting was closer to software development, it was a good compromise.

At least, I would learn some hands-on skills and a certificate would bring me closer to my first pentester job. Of course I hadn’t planned to stay longer than necessary in that developer role.

Before I even finished that certification, another door opened. I was offered to build the company’s AppSec program from scratch. Of course, back then nobody even knew there was a name for what I should do. They told me I should do some security stuff and maybe pentest some of our own products. YES! Of course I’ll accept that detour.

Be willing to abandon your North Star

Remember how I had abandoned my North Star before? I wanted to become a captain at sea, but abandoned that dream for becoming a pentester. Reality had killed the first dream.

This time, I was sure I found the right profession. The job that I can work for the rest of my lifetime without it becoming boring. Hacking all sorts of systems and applications. Finding new ways in all the time. For me, that sounded like standing in front of the great walls of Troja and trying to figure out, how to conquer a city nobody had ever conquered. What an adventure!

But something had changed. I was working in security now. For the first time, I got trust from my management to build something that should actually improve software security at scale. No compliance bullshit. Just AppSec that works.

Compliance followed later, but it didn’t mess with what worked. I basically had the freedom to explore what AppSec measures were out there, what our teams needed and come up with my own ideas of what might work. Then I would test and implement them. It was fun. Maybe I should explore this detour a bit longer.

This time, a headhunter changed everything. There was this company I had wished to work for for many years. The one that gave me the list of topics to study. When he called, he couldn’t hide for which company he was hunting talents. It was the wrong time. My AppSec program was still too fragile, but we stayed in touch.

Maybe a year later, we spoke again. In the meantime, he had gained better insights on what the job of my dreams actually looked like. How much time do you actually spend hacking? How much is routine? Writing reports? Traveling to customers?

When we separated this time, reality had caught me. Again. I had abandoned another North Star. Working as a pentester or red teamer was no longer pulling me.

I had been delusional. I had again, wasted time on learning hacking skills and gaining pentesting certifications. But again, those skills would prove valuable later, just not in the way I had imagined.

So how can I finally find the one thing? A North Star I wouldn’t need to abandon in the future?

Know when to jump

For a long time, I had known I wanted to be my own boss. I had wanted to travel full-time and explore the world. I just didn’t know in what direction I wanted to take my own business.

Should I stay in AppSec? The field I never chose? A field I accidentally stumbled into? Or should I finally follow my passion?

For over a decade, there had been a passion that I could turn into a job: photography. But I had always been scared, that becoming a professional photographer would kill my passion. The idea of photographing a new dog every day at the same locations seemed too boring.

In the end, my calling for freedom, overland traveling and adventure grew so big, I couldn’t resist anymore. I had to jump and build a business around the skill I got: building AppSec programs.

Some people might build their identity around a job, but for me, that just didn’t work.

I had to accept, that there was not that one thing that would be my job or passion for the rest of my life.

Dance with chaos…

In 2025, I made my dream come true. I quit my job, got rid of most of my belongings and left Germany. I was finally free and on my own adventure!

Not as a captain at sea, but at least I’m now steering my good old Chevy Blazer through Europe and Northern Africa.

I learned pretty fast that I had underestimated with how much chaos and uncertainty this lifestyle naturally comes. No fixed income. No place where I belonged. Just freedom without security.

But it was the same freedom and exploration that eventually let me arrive in AppSec. While I never wanted to be an AppSec person, I’m still drawn towards understanding how companies work, how complex systems work, what makes them fragile and how to optimize them for resilience.

Looking back, to me the most interesting domain within pentesting had always been social engineering. I had been interested in philosophy and psychology for years. Always driven to understand why people do what they do.

When I built my own AppSec program from scratch, I had been using this the whole time. I had analyzed the system, processes and tried to understand why people wouldn’t act even so they knew what the expected secure behavior was.

As an external consultant, I lost this connection. I was too far away to talk to the developers and project leaders to understand their system, culture and needs. I had to come up with my own approach once again.

… to create order

So how did arriving in AppSec actually look like?

Last year, I came up with the AppSec Ownership Model. Something, that had been in my head for a long time. In short, it’s how I would distribute AppSec responsibility between all roles involved in developing secure software. My blueprint to a resilient AppSec system.

First, I published my AppSec Ownership Model on YouTube, but it was too rigid. Whenever I want to update something, I would need to produce a completely new video. That’s why the model is now available here on Substack.

Somewhere along the way, I just wanted to do research. I wanted to talk to fellow AppSec Leads, listen to their stories, learn about their challenges and figure out, what actually works in AppSec. I wanted to soak in all the other perspectives, see what we can learn from each other and publish it. And of course, sharpen the AppSec Ownership Model.

Besides that, I had to find something better than classical consulting. Something that can connect me again with the company’s culture, processes, and people.

That’s why I created the AppSec Terrain Check. A diagnostic assessment where I interview people in different roles who are involved in developing secure software. This allows me to understand their system and figure out where it is most fragile. That way, I can make it visible to the AppSec team and help them optimize their system for resilience.

If you are building an AppSec program yourself, I would love to hear your story. Feel free to send me a DM here or on LinkedIn.

Conclusion

If career planning works for you, you are lucky. If it doesn’t, there is nothing wrong with you. I think it doesn’t work for most people. And if you see people that found exactly that job or role that matches their passion, they probably ended up there by accident, too.

So how can you arrive at the right place following your own accident?

1. Embrace detours: you never know what a detour will teach you or if it will end up being the place where you want to arrive.

2. Turn on dead ends: If your job feels meaningless and you hate it, leave. Do something else, no matter what. Just something that is fun and teaches you something new.

3. Stand up for yourself: Nobody is coming to push your career. Take responsibility to develop your own skills. If you want support from your company, create a win-win. How do they benefit from your new skill?

4. Be willing to abandon your North Star: A North Star is just a direction you’re curiosity did take you. Try to find out if your imagination and reality actually match. If not, find a new direction.

5. Know when to jump: We all get stuck in our comfort zone. If you really want something to become reality, at some point you must jump and see what happens.

6. Dance with chaos to create order: After you jumped, life might be chaotic. You might underestimate the challenge you accepted. But this time will make you grow and eventually you will stabilize your life at a much better place. If not, you’re not dead. You can try again.

In this fast moving world, it becomes even more critical to find your own path. How could I have known back then that doing AppSec research and AppSec system diagnostic could even be an option?

Now all the developers need to do is fix all those critical and high-severity findings the scanner made visible within their codebase.

They should thank you! You made their work so much easier.

Instead, they let you down. They are not fixing anything. Not even the critical ones. How can they be so lazy? Or careless? Or both?!

You are the one who needs to explain to your management why your company invested so much money in a tool that has literally no impact on software security.

Calm down, there is a solution. Developers are friends, not enemies. And the problem isn't their attitude. It's the deal you're offering them.

Why developers don’t fix SAST findings

As a developer, I was the exception. I loved fighting technical debt, fixing SAST findings and updating libraries more than building the next stupid feature our customer asked for. Why would anyone prioritize changing a button color while the application has more holes than Swiss cheese?!

I annoyed my project leaders every day, because I wouldn't work on that feature request without arguing about security or technical debt or both. If you have developers on your team who are like that, you are lucky. Remember their names. You will need them.

For everyone else, SAST findings are just another annoying task on their desk. You have so many bug fixes that take forever to figure out why the application behaves in a certain way under certain circumstances. And the customer might already be angry, because their customers keep complaining about these bugs.

As a developer, you probably did not sign up dreaming of maintenance. You imagined building cool features. Creating something that will add value. Something you can be proud of.

Instead, you lose day after day, hour after hour, fighting all those side-quests. Bugs, vulnerabilities, dependency updates, technical debt and who invented those stupid unit tests?

Chainguard asked 1,200 software engineers and tech leaders how their week actually breaks down. The numbers are hard to ignore. Engineers spend only 16% of their time writing code and building new features. The other 84% goes to maintenance, patches, vulnerability remediation, and other toil. And 93% of them say that 16% slice is the most rewarding part of their job.

16% of time spent on work you love. 84% for everything that keeps you from it. Developers are neither careless nor lazy.

They are just protecting those few hours when they can actually do what they love.

Why you don’t want developers to fix SAST findings

Let us step away from security for a moment.

My dog Suschka has something she loves more than everything else: hunting. Mice, squirrels, cats, reindeer – she even tried to keep up with a chamois once. For her, running behind a deer or digging for mice is the best thing in the world.

Of course, I cannot let her freely hunt other animals for fun. She would harm them and could even cause accidents when she crosses a street at full speed behind that deer.

So she needs to be on a leash in the forest. But keeping her on leash all the time?

That’s managing the problem, not solving it.

Same thing in AppSec.

Fixing SAST findings is managing the problem, not solving it.

Why would you want your developers to fix SAST findings?

Nobody wins when time is spent that way. You want them to build features your company can sell to make money. That is their job and that is what they love doing.

What do we want instead?

Let us come back to our little hunting story.

My dog trainer told me to establish a special command that promises a really big win for Suschka, e.g., sausages. The idea is simple: she can’t hunt a cat and turn toward me at the same time.

I would need to find something that is more rewarding to her than hunting or at least a safe win. When I then reward the turn, the hunting dies out on its own.

This approach is called Differential Reinforcement of Alternative Behavior (DRA). It's a core technique in applied behavior analysis: instead of punishing the problem, you reinforce an incompatible alternative.

We started small. After a few weeks of training I was eventually able to stop her from hunting a cat. She spotted the cat and prepared to hunt as usual. Bambi! My timing was good. She turned towards me and asked for her sausage. YES! It’s working!

Sure, that was just one cat and she had not been in the hunting tunnel already. But it was a first step.

She had begun to slowly shifther default behavior from ‘Oh, cat! Bye!’ to ’Hey, see that cat? Gimme my sausage!’

It is all about timing. When I reward Suschka after she had already hunted that cat, she is not replacing the old behavior with the new one. I just taught her that she can have fun hunting and get her sausage on top.

For developers, it is even worse. They don’t love fixing SAST findings. Any reward you provide for fixing SAST findings will only compensate for the hours you kept them from doing what they love (building cool features) and what makes your company earn money.

Fixing SAST findings is a win for security and a lose for everyone else.

How do you create a win for everyone?

You have a big advantage when dealing with SAST findings. They are a self-caused problem and follow patterns. I cannot prevent cats from crossing our path, but that is exactly what you need to aim for. You can step in earlier in the chain and remove the trigger, instead of fighting the consequence.

When you accomplish that, your developers can spend time on building features, your company can sell software and your stats are green.

Win. Win. Win.

We cannot go back in time and stop the existing SAST findings before they entered your code base. That is security debt we need to deal with, no matter how annoying it is. But those findings are valuable signals you can use to prevent future SAST findings.

What do we hunt instead?

You start by looking at what your SAST tool already tells you. Not the findings themselves. The patterns behind them.

That’s DRA applied. Developers cannot use the insecure pattern and the secure one at the same time. Every time they use the secure pattern and get a green light, that’s one step towards the new secure default behavior.

Start with one pattern. The one that hurts most.

When you witness your developers choosing the secure pattern over the insecure one, it’s time to celebrate your win and expand your system to dry out more insecure patterns.

A nice side-effect is that the metric of secure vs. insecure pattern usage is perfect proof that your AppSec system actually improves software security.

I want to strengthen one last important point. This approach is not about manipulating or tricking your developers into showing the behavior you want to see.

It’s about cooperation.

In the end, you all share the same goal: maximize the time your developers can spend building cool features while still producing secure software. When you reward the secure pattern instead of punishing the insecure one, you’re not playing mind games. You’re making the secure path the easy path. You’re removing friction.

That’s not manipulation. That’s good system design.

I may not know much about poker, but this definitely counts for AppSec. We may not read faces, but we must talk to people and ask them what they actually need from us. Why don’t they onboard to that new security tool? Why is their vulnerability count still not going down and why do they still push new secrets into the code base?

But let’s see how to win the AppSec game.

If you found something valuable to take from the gambler’s playbook, I would love to read about it in the comments. Which rule did hit the most?

What do you think happened while I was hiking?

Exactly.

Nothing.

Of course I didn’t expect anyone to develop the system further. I just asked them to prepare some small tasks in the meantime. Things I would usually have to wait for, as my progress depended on them.

But without my constant reminder, the 3 months just passed by unused.

I had fallen for the Pushing Fallacy.

Why did I get trapped?

When I got handed responsibility for AppSec, I took it very seriously. I wanted to build something that really helped my fellow developers to build secure software. I had no idea what I was doing, but I was determined.

The problem was, nobody would argue that security was important. But was it urgent enough to prioritize it over the feature the customer wanted to have yesterday?

Probably not.

This behavior is not a character flaw. It is a documented cognitive bias. Researchers call it the mere urgency effect. In a 2018 study, Meng Zhu at Johns Hopkins found that people consistently choose urgent tasks over important ones — even when the urgent task promises a smaller reward. They pick the deadline over the payoff. Every time.

A bug is urgent. A feature becomes urgent, because the customer is pushing for it.

Security is important, but not urgent until it’s too late.

I adapted fast. I knew instinctively, I had to create urgency. I became the two feet in their door, pushing security forward.

And of course it worked.

It worked. So why is it a fallacy?

Pushing creates urgency, urgency creates action, action creates results. The dependency gets updated. The vulnerability gets fixed. The ticket moves forward. Every push delivers a small, immediate win.

That’s exactly why the cycle is so hard to break.

B.F. Skinner demonstrated this in the 1930s: behavior that is immediately rewarded gets reinforced faster and stronger than behavior with delayed consequences. Push. Ticket closed. Relief. Push again. Our brain learns that pushing works, and it learns it fast.

The mechanism has a name: temporal discounting. We devalue rewards that lie in the future. A resolved ticket now feels more real than a fragile system in two years. The dopamine hit arrives before the damage is even visible.

But the reinforcement does not stop with you. Your colleagues are learning too.

Every time you push, you send the same signal: when security is urgent, someone will stands in the door. They learn that the reminder will come. They learn that delaying security has no consequences.

Psychologists call it the overjustification effect: when an action is always triggered by an external push, the internal drive never develops. Your colleagues never develop a reason to prioritize security on their own. You are the reason. And when you disappear, the reason disappears with you.

Two cycles. One spiral.

This is how AppSec heroes are born.

Why does this make my system fragile?

Imagine the knight fighting the dragon. That’s you. But you can’t fight all dragons everywhere at the same time. And what happens, when the dragon wins?

Yes. A hero is per definition a single point of failure.

In AppSec, you are fighting. You are pushing. This may work for some time. But eventually, you may get wounded.

The statistics are brutal. A 2025 Sophos survey of 5,000 cybersecurity professionals across 17 countries found that 76% experienced burnout in the past year. At the leadership level, it is worse: 91% of CISOs report moderate or high stress, and more than a quarter admit that stress directly affects their ability to do their jobs.

When your system depends on one person, and that person burns out, the system does not slow down. It stops.

Obviously, hero-dependence makes your systems fragile.

But even if you do not burn out, pushing has already stolen something from you: the time to build.

Every hour you spend reminding someone to close a ticket is an hour you didn’t spend designing a process that closes tickets without you. Every meeting where you’re the only one pushing security is a meeting you could have spent building ownership into the development team. Every firefight you solve alone is a firefight you didn’t use to train someone else.

You are trading progress for motion. You stay busy. You stay indispensable. You waste energy without building resilience.

Now, how can you escape the fallacy?

The first step is not to stop pushing. That’s unrealistic. Just recognize the trap.

These three steps get you started. But they don’t replace a focused diagnostic.

For that, you need to understand your AppSec program as a system. Not as a collection of tools and processes, but as a system with interdependencies, responsibilities, and pressure points.

On my website I explained the full process. Map out your system. Understand how it works and where it’s most fragile. Then optimize for resilience step by step.

I built the AppSec Ownership Model as a reference for how responsibility can be distributed in a resilient AppSec system. You can use it to decide which responsibilities are misplaced and how to rearrange them.

If you want my support with that diagnostic, that’s exactly what the AppSec Terrain Check does.

Whatever route you choose, don’t wait. Start today. Break the first cycle.

I have been asking myself the same question over and over again: why do people do what they do? Often, it makes no sense.

Some behavior seems totally irrational. Like self-sabotage.

In security, you find many examples:

• You keep hammering it into developers' heads: no hard-coding! Still, secrets get pushed to the repo.

• You blacklist an old vulnerable JS library, but somehow people copy it into the repo and keep using it.

• Or, you help your CISO run another pretty obvious phishing simulation and people keep clicking AND entering their data.

It is obvious to me that control-based security just doesn’t work.

According to Sauce Labs’ Developers Behaving Badly report, 75% of developers admit to circumventing security protocols to get their work done. 70% have used a coworker’s credentials.

I can’t spot bad intentions. They just try to do do their job.

But that’s not all.

Control-based security is in fact harmful for your organization.

Why control harms your company

Let’s step back for a moment. How could security harm your company?

“It’s the very thing that protects my company from major incidents!” you might think.

You’re right.

Or, that’s at least the goal. But security that fails to achieve that goal still produces costs that someone needs to pay for.

Here’s how the chain works:

Security controls become roadblocks. Developers see them as obstacles, not support.

Secure Code Warrior’s 2022 survey found that 86% of developers do not view application security as a top priority when writing code. Only 29% believe the active practice of writing code free of vulnerabilities should be prioritized at all.

Why? Because your AppSec program taught them that security is someone else’s job. A gate to pass. A checklist to satisfy. Not something they own.

Roadblocks breed frustration. Frustration creates a toxic environment. And toxic environments drive people out.

According to iHire’s 2024 Talent Retention Report, the leading reason employees quit is a toxic or negative work environment (32.4%), ahead of poor leadership (30.3%) and unsatisfactory pay (20.5%).

When your best developers leave, delivery grinds to a halt.

Gartner’s 2024 Workforce Productivity Report found that each developer turnover sets a team back by 4 to 8 weeks in delivery time. And teams with high turnover accumulate 37% more technical debt and spend 22% more time debugging than stable teams.

That’s the cost of control:

• slower delivery,

• accumulating debt,

• and a revolving door of talent.

As AppSec Leads, we must be constantly aware, that security is a mean to a greater end.

Security exists to protect freedom

Let’s zoom out.

When someone starts a company, they usually have a great vision. Something they want to bring into the world. Something that serves their clients in a meaningful way. It’s all about freedom, creativity, big dreams and purpose.

Along the way their vision becomes their employees daily work. Some might share the vision and find joy in pursuing it. For others, it’s just a good way to pursue their own goal of stability and their purpose in providing for their family.

In the end, everyone wants something different out of life. Your company has its vision and needs. But it's a complex system resting on many shoulders, each carrying their own vision and needs. One can’t function without the other.

And everyone, at the end of the day, is looking out for their own survival.

That’s not selfish. It’s human. The developer wants to write great code and ship a product they’re proud of. The product manager wants to hit deadlines and deliver value. You, the AppSec Lead, want to prevent breaches and protect the company.

All of these are legitimate needs. The problem is how we try to meet them.

Control-based security enforces our needs at the expense of everyone else’s. It says: “My need for security outweighs your need to build, to ship, to create.” The developer who loves writing code and believes in the product is told to stop, fill out a form, wait for a review, and justify why they need to do what they were hired to do.

That’s not protection. That’s restriction.

You’re not creating a safe space for their freedom to exist. You’re taking their freedom away and calling it security.

So how can we do better?

The invisible fence

Picture a free-running dog next to a main street. Claws aligned with the curb. Calmly waiting. No human. No leash. For most dog-loving drivers, this may cause heart attacks. What a dangerous situation for the dog!

For me, that’s just a daily walk in the city with my dog, Suschka.

I knew running across streets could kill her, so we trained the safe behavior from day one.

At every street, you would hear me say: “Czekaj!”. That’s polish for "Wait!”. My colleagues back then even started imitating us for fun when we headed for lunch. “Czekaj!” Everyone would stand still until I had properly checked the situation and said “Ok, go”.

That’s how we created that invisible fence that protects my dog’s life without the need to restrict her freedom to explore at her own pace.

Is the invisible fence 100% secure? No.

Is the leash 100% secure? No.

Does the leash restrict freedom? Definitely.

But what about me, the owner? When she stops just millimeters before her paw would touch the street. Yes, I still sometimes experience some light heart attacks. But I had time to build trust and she proves me right every day.

And whenever I feel she might not recognise a street as such in a new environment, I will just remind her. Czekaj! Communication.

And of cause there are situations, where I still use a leash.

• Social reasons: When people are scared of the little wolf, the leash makes them feel safe even if it’s not necessary for us.

• Safety reasons: Sometimes trust is not enough. I know I can’t trust her when it comes to her passion for hunting deer, so I have to use a leash in the forest where her freedom would harm others.

• Legal reasons: When law requires us to use a leash, we might use it to avoid unnecessary costs. Or maybe we just take the risk of getting caught. #YOLO

Like a leash, security-controls are a useful tool when used carefully. But they should not be your only tool and not your first thought.

Why should I trust the invisible fence in AppSec?

It doesn’t matter if you train a dog or work with people. You can influence behavior in to ways: through force and control, or through relationship and autonomy.

Self-Determination Theory, one of the most validated frameworks in organizational psychology, proves that people are intrinsically motivated when three needs are met:

1. autonomy (the feeling you’re choosing your actions),

2. competence (the feeling you can succeed), and

3. relatedness (connection to others).

When those needs are met, performance goes up, turnover goes down, and people take ownership.

External control destroys all three.

Fear-based training leads to disengagement. Empowerment-based training creates a culture where everyone sees themselves as part of the defense.

In security, the data backs this up.

Organizations with a strong security culture show 52× less risky behavior like credential sharing. The KnowBe4 Security Culture Research dataset examined tens of thousands of employees across thousands of organizations and found that organizations in the "Good" security culture class had 52 times less data entry in phishing simulations than those in the "Poor" class (0.1% vs 5.2%).

The invisible fence is still a fence, but it’s one people can choose to accept (autonomy) because they understand (competence) why it is necessary to protect themselves and others (relatedness).

How do you build an invisible fence?

Let’s see how I built our invisible fence at the streets and see how you can get started building your own invisible fences in AppSec.

By applying the Self-Determination Theory, you created intrinsic motivation to behave securely. That’s when the fence turns invisible, because there is no motivation to run into that fence any more. Over time, these invisible fences are what create your strong security culture.

Control is killing your AppSec program. Trust, earned through training and autonomy, is what makes it work. Security and freedom are not opposites — they are interdependent. Build the fence people choose, not the one they're forced to work around.

Who is the Catalyst?

The Catalyst is one of six roles within the AppSec Ownership Model and refers to:

Someone who brings external expertise in building AppSec ownership within your company.

This includes:

• AppSec consultants or guides

• AppSec trainers

This is, of course, not an exhaustive list and you may find these boundaries useful in other contexts outside of AppSec as well.

What AppSec domains can the Catalyst support?

The Catalyst can’t own AppSec domains, they can only support. So here’s what they can focus on:

Security Tooling | Provide current market insights on what solutions are available and how to select and integrate tools to support your team.

A good guide is independent. That means they don’t work with just one vendor, but help you choose something that fits your needs individually.

Security Strategy | Provide guidance in navigating the complexity of AppSec.

This includes setting up processes for Vulnerability Management and Incident Readiness, and providing resources to customize for every AppSec domain.

Security Culture | Provide guidance for building a strong security culture and a company-wide security champions program.

A good guide knows how important culture is and will help you build an AppSec program that is centered around your developers, not your security team.

Now that you see the bigger picture, let’s make accountability explicit.

What is the Catalyst accountable for?

Here’s what you can hold your Catalyst accountable for:

• Coaching the AppSec lead and acting as a strategic sparring partner.

• Reviewing and advising on tooling, processes, and structural decisions.

• Spotting blind spots, challenging assumptions, and providing external validation.

• Supporting the setup of a scalable AppSec strategy and guidance for developing a strong security culture.

• Providing best practices, templates, and playbooks to accelerate internal decision-making.

• Maintaining external perspective and bringing in relevant market, tooling, or ecosystem insights.

What accountability must stay internally?

Here’s what you must strictly own internally:

• Delivering or owning policies, findings, or operational outcomes.

• Acting as a direct contact for developers or security champions.

• Taking over operational responsibilities within product or security teams.

• Creating dependencies or acting as a “shadow AppSec lead”.

If you let a consultant take ownership of these areas, you’ll become dependent on them in the long run. They can support you, but you must be careful not to externalize accountability.

Who does the Catalyst work with?

There is only one role the Catalyst should work with:

Owner (e.g., AppSec lead) | Only with a clear mandate and by invitation.

They may work with interim stakeholders (e.g., CTO or an architect) during the initial phase to facilitate alignment and prepare for the takeover of an internal owner. If there is no internal owner, appointing one should be the highest priority.

They can work with other roles initially, e.g., as a trainer for software developers, but this should not turn into a long-term dependency and shouldn’t happen without the Owner’s explicit approval.

Who is the Advocate?

The Advocate is one of six roles within the AppSec Ownership Model and refers to:

A developer who’s interested in security and has deepened their security knowledge.

A security champions program is a decentralized approach to extend your central AppSec team with people embedded in development teams that advocate for security and act as a bridge between teams. Anyway, we should never forget that they are mainly developers, not security staff.

What AppSec domains does the Advocate own?

As the Advocate, you focus on the two AppSec domains you already own as an Executor, plus one additional domain:

Secure Design | Drive threat modeling exercises and ask security-related questions.

This domain is already one of your main focus areas as developer, but as Advocate you are expected to wear the security head in every design-related action and support your team with your security expertise.

Secure Coding | Spread security knowledge within the team and pay special attention to code reviews and the security-related test cases.

I can’t stress enough that you don’t need to do everybody’s security work. Don’t write everyone’s tests, but point out if security-related test cases are missing. As the Advocate, your main task is awareness and support, not compensation for other people’s bad habits.

Security Culture | Drive secure behavior within the team by being a role model and advocating for security.

Everyone can shape culture, but as the Advocate, your passion for security naturally serves this purpose. Cultural change is all about behavior and with you being a role model, you can inspire your peers to improve for themselves.

What AppSec domains does the Advocate support?

Being the Advocate for security comes with additional responsibilities and opportunities to shape your company’s AppSec program. While you don’t own every single domain, you can contribute to all of them.

Security Tooling | Provide valuable feedback on usability and raise recurring needs.

Security Strategy | Provide feedback and insights from day-to-day development to guide improvements based on real-world needs.

Your AppSec lead needs your feedback to shape the AppSec program in a direction that actually serves the developers. As you are still part of the development team, you’re best positioned to ensure they have the right context to decide which tools to provide and which strategy to follow.

Incident Readiness | Act as a point of contact for incident triage within the team and help identify the right people to support technical analysis.

When things go south, you are maybe best suited as support for the AppSec team to figure out what is going on and make sure your product is safe again soon. That doesn’t mean you’re meant to lead the process.

Vulnerability Management | Support your project leader and highlight recurring patterns for proactive improvement.

You can support your project leaders when they don’t know how risky certain issues are or how much effort it will take to remediate them. You are invited to look for patterns and suggest improvements in and across teams.

Now that you see the bigger picture, let’s make accountability explicit.

What is the Advocate accountable for?

Here’s what you can hold yourself accountable for:

• Supporting developers in applying secure practices and improving their skills.

• Bringing security topics into daily work and team discussions.

• Facilitating basic threat modeling and secure design thinking.

• Identifying security gaps that need central guidance or structural fixes.

• Providing input on the usability of tools and effectiveness of guidance.

• Sharing team-level insights on recurring needs and repeated issues with the AppSec lead.

View this list as an all-you-can-eat menu. These are areas where you can do more. You can start small with improving your own security-related skills and build a strong security community together with other Advocates. Nobody expects you to know and solve it all on your first day.

What is the Advocate NOT accountable for?

Here’s what you are explicitly not expected to do:

• Taking over security responsibilities from other team members.

• Replacing the project leader in planning or prioritization.

• Implementing or enforcing central security measures.

• Making policy decisions or setting global standards.

• Leading incident response independently without coordination.

• Acting as permanent substitutes for the AppSec lead.

While the first list was the tasty menu you could choose from, this list is the ‘don’t eat that shit’ list. Eating toxic mushrooms won’t serve you well. If your security champions program expects those things, push back hard. That’s the path to an unhealthy security champion role you don’t want to carry.

Who does the Advocate escalate to?

As the Advocate, there are two roles you can escalate to:

Gatekeeper (e.g., project leader) | For team-internal issues that block secure development, e.g. missing capacity, unclear ownership, or lack of priority.

This is your main escalation path as a developer anyway, so you can still use it to escalate security-related issues within your daily work and team.

Owner (e.g., AppSec lead) | For issues that require structural support, central guidance, or cannot be resolved within the team, as well as any conflicts, they may not solve locally.

The Owner should have your back and is your central point of contact when things can’t be solved locally. They should be in contact with the executive leadership, so they are can further escalate things if necessary.

In emergency cases, you as the Advocate may help coordinate local response efforts or step in when the Owner is unavailable, based on predefined rules. However, this is not your primary responsibility and should be clearly scoped.

Finally, you can always escalate to your security champion community. You are not fighting and advocating alone. You hopefully have your community and network to support your local efforts, learn from each other and have fun.

Who is the Backbone?

The Backbone is one of six roles within the AppSec Ownership Model and refers to:

Everyone steering the company at the highest level.

This includes:

• Any C-suite roles

• CISOs

This is of course not an exhaustive list. Anyway, within the model, they are all grouped together because from an AppSec point of view, their contribution and accountability is pretty similar.

What AppSec domains does the Backbone own?

As the Backbone, you need to focus on two AppSec domains:

Security Strategy | Own strategic direction, ensure alignment with business goals, and make final decisions on investment and risk.

Security Culture | Lead by example and embed security into organizational values.

You will need to find an AppSec lead to own your AppSec initiative at an operational level. They should be enabled and trusted to come up with a solid security strategy, but the final decision is yours.

In addition, you must be serious about AppSec yourself, otherwise your AppSec lead has no chance to shape and nurture a good security culture.

Now that you see the bigger picture, let’s make accountability explicit.

What is the Backbone accountable for?

Here’s what you can hold yourself accountable for:

• Approving the overall security strategy and investment decisions.

• Supporting the AppSec lead with clear mandate and organizational backing.

• Ensuring that security priorities are reflected in business planning and governance.

• Leading by example and reinforcing security culture through visible commitment.

• Taking responsibility for accepted risk at organizational level.

What should the Backbone delegate?

Here’s what you should delegate:

• Defining technical security standards or tooling.

• Managing day-to-day application security execution.

• Performing reviews, risk ratings, or technical assessments.

• Communicating directly with product teams on implementation details.

Who does the Backbone work with?

As the Backbone, there are only two roles you need to work with regularly:

Owner (e.g., AppSec lead) | For strategic alignment and decision preparation.

Gatekeeper (e.g., project leaders) | For prioritization and risk visibility within projects.

You may also work with your security champions (Advocate) indirectly by enabling a culture that values their contributions.

Who is the Owner?

The Owner is one of six roles within the AppSec Ownership Model and refers to:

The person who takes ownership of AppSec and mainly drives the initiative.

This includes:

• AppSec lead (operational owner)

• AppSec teams (shared responsibility)

• CISO / C-suite (strategic fallback if no dedicated owner exists)

One could argue that ownership ultimately lives within the executive leadership, but for the sake of this model, we refer to the person who mainly drives and represents AppSec within the company.

What AppSec domains does the Owner own?

As the Owner, you mainly focus on four AppSec domains:

Security Strategy | Define the overall strategy with long-term goals and KPIs to measure progress.

The strategy needs to be aligned with business goals and approved by the executive leadership (Backbone). Close collaboration between both roles is absolutely necessary.

Security Tooling | Select and configure security tools in alignment with the overall strategy.

This includes anything from scanners to vulnerability management platforms or runtime protection. The requirements for each tool should be derived from the base in collaboration with the development teams.

Incident Readiness | Define and train processes for incident response and zero-day vulnerabilities.

As the Owner you should provide process definitions, templates and checklists, as well as detection mechanisms. Everything that saves time and reduces error under pressure. Of course these structures need to be built and derived from the operational reality.

Security Culture | Detect cultural threats and actively shape cultural change.

A strong security culture will make every other effort you take more efficient and sustainable. Nobody can change culture alone, but someone must attempt to shape it with intention and a plan, one step at a time.

What AppSec domains does the Owner support?

As the Owner, you’re involved in all domains. These are the remaining domains, you only support:

Secure Design & Secure Coding | Define standards and provide best practices for secure design and coding.

Vulnerability Management | Define the process and prioritization rules based on risk.

All these domains must be mainly driven by the development teams, as you won’t have capacity or know all the details to own them. They are the main trap where AppSec leads burn themselves out when they take on too much in those areas. Make sure you strictly separate between operational details and defining structure.

Now that you see the bigger picture, let’s make accountability explicit.

What is the Owner accountable for?

Here’s what you can hold yourself accountable for:

• Designing and evolving the AppSec strategy, including roles, responsibilities, policies, and processes.

• Making structural decisions on security tooling, training programs, and cross-team standards.

• Prioritizing global security efforts based on input from teams, risk exposure, and business impact.

• Defining how threat modeling, vulnerability management, and risk acceptance are handled across teams.

• Defining roles and responsibilities within the incident response process and ensuring readiness across involved teams.

• Enabling security champions through clear guidance, training resources, and structured feedback.

• Ensuring continuity of strategic AppSec leadership, including defined delegation in case of absence.

• Supporting awareness and compliance activities in alignment with strategic goals.

• Defining relevant KPIs for application security and regularly reporting them to the executive leadership.

• Actively aligning AppSec goals with business priorities, customer value, and delivery strategy through regular collaboration with the management.

• Temporarily owning unstructured security gaps to prevent risk blind spots with the explicit goal of transitioning them into stable ownership based on field experience.

I know the list is long. If possible, these accountability should be shared by an AppSec team. If you’re alone, make sure you are extra strict in what to prioritize and what to reject at least for the moment. Nobody wins when you ignore your limits and eventually need to give up.

What is the Owner NOT accountable for?

There are certain operational things you need to delegate because you just can’t handle them.

Here’s what you are explicitly NOT accountable for:

• Fixing vulnerabilities, reviewing code, or directly supporting delivery teams operationally.

• Leading operational incident response unless specifically defined as part of the process.

• Making final decisions on budget, procurement, or staffing (that belong to executive leadership).

• Taking over prioritization decisions that belong to product or project management.

• Owning team-level backlogs or covering missing security champions in delivery teams.

• Acting as a full-time trainer or one-on-one coach for teams.

There are other roles accountable for those tasks. If you notice they don’t own their part, help them understand why they must and ask the Backbone to support you up if necessary.

Who does the Owner escalate to?

If you find yourself confronted with tasks, that should not be on your desk, you have two options for escalation:

Gatekeeper (e.g., project leaders) | When security goals are blocked by planning constraints or business pressure.

Use this path when KPIs are not met to figure out why they failed and how they can be supported, to get back on track. Don’t take over for them, just ask and lead them back on track.

Backbone (e.g., executive leadership) | For structural conflicts and priority trade-offs.

Use this path when you run into conflicts with the project leaders and their teams. When you can’t find solutions locally, call your Backbone for support. They ultimately decide if security is their first business priority in that specific case or if there are reasons to prioritize output. In that case, ask them to address the security requirements in their plan, with a clear near-term deadline.

Who does the Owner work with?

Apart from escalation, there are three roles that the Owner can work with:

Backbone (e.g., executive leadership) | For budget and strategy decisions related to AppSec capabilities.

The Owner should report at least quarterly directly to management to keep them informed. There should be a quick way to get their feedback or smaller decisions in between to reduce friction. This collaboration is the necessary foundation.

Advocate (e.g., security champions) | They lead the security champions program, which provides direct feedback from the base.

The Owner will usually lead the security champions program at least in the beginning. Later the security champions might be able to sustain the program themselves, but the Owner still needs to stay in touch with them. They are probably their best connection to the development teams to get honest feedback, needs and requirements to support development teams best.

Catalyst (external/optional) | Whenever they need access to deeper expertise, external validation or strategic sparring partner support.

The Catalyst can be any external coach or consultant that usually works exclusively with the Owner without taking ownership away from them.

Who is the Gatekeeper?

The Gatekeeper is one of six roles within the AppSec Ownership Model and refers to:

The person who sets product direction and protects the team’s ability to execute.

This includes:

• Project leaders

• Product owners

• Scrum masters

This is of course not an exhaustive list. Anyway, within the model, they are all grouped together because from an AppSec point of view, their task is to ensure the product gets developed. This can naturally create conflict with security requirements and that’s expected. The Gatekeeper should be critical and observant if those requirements actually improve the overall security of their product or if they just slow down their team without meaningful impact.

What AppSec domains does the Gatekeeper own?

As the Gatekeeper, you need to focus on only one AppSec domain:

Vulnerability Management | Prioritize remediation of vulnerabilities while balancing other demands.

Vulnerability remediation, bug fixes, or new feature requests? All of them need time and focus from your team to improve the product. As the Gatekeeper, it’s your job to make sure priorities are chosen well. As with bugs, some vulnerabilities might be something you can ignore while others need immediate attention. You are not expected to do the assessment and decide, which vulnerabilities need to get fixed on your own. There should be standards, rules, and tools in place to support you. Anyway, finding the right balance between bug fixes, remediation and feature requests is your game.

What AppSec domains does the Gatekeeper support?

If you cut security work entirely, you can sabotage the effectiveness of the AppSec initiative. Killing security theater is good. Killing useful security work isn’t.

Your team needs time and resources to handle their security duties in a meaningful way. Therefore they need you to actively support them in their domains:

Secure Design & Secure Coding | Provide time and space for secure design and coding activities.

Listen to your team when they initiate security-related activities. When they need to talk about design instead of jumping right into implementation, this will benefit your product and save time in the long run. Trust them.

Incident Readiness | Coordinate delivery-side impact and communication.

In addition, you play an important role when incidents hit, as you are the one who can see the impact on your timelines and communicate accordingly with impacted stakeholders.

Now that you see the bigger picture, let’s make accountability explicit.

What is the Gatekeeper accountable for?

Here’s how you ensure meaningful security takes place in your project:

• Ensuring that security requirements are clearly defined for every delivery.

• Ensuring that security-related tasks are properly included in planning and delivery.

• Prioritizing vulnerability remediation against feature and bug requests.

• Making security trade-offs visible and discussing them openly.

• Escalating when security is deprioritized without conscious risk acceptance.

• Supporting incident coordination and communication if the situation affects delivery or customers.

What is the Gatekeeper NOT accountable for?

You don’t need to become the security expert. Vulnerabilities should be pre-assessed or at least you should have rules and standards at hand that help you sort quickly through them without guessing risk.

Here’s what you are not accountable for:

• Defining detailed security requirements or implementation details.

• Deciding on technical severity or exploitability of findings.

• Defining risk based standards or deadlines for vulnerability remediation prioritization.

That information should be presented by either your development team or the AppSec team. If it’s missing, ask for it.

Who does the Gatekeeper escalate to?

If you struggle to decide whether certain security activities are meaningful or if certain vulnerabilities should be remediated in the next delivery period, you have two roles to support your decision-making.

Advocate (e.g., security champions) | For technical input, missing context, or when support is needed to understand the impact of a security issue.

For the small details, security champions are the perfect partner to discuss details with. They are developers with security expertise and can help you decide on a day to day basis. If your company doesn’t run a security champions program, just ask experienced developers. You likely know best who might be able to answer your questions.

Owner (e.g., AppSec lead) | For unclear security priorities, accepting known risk or when security work falls short due to delivery deadlines.

The second point of contact is your AppSec lead or team. When general guidance or tools are missing and you think you need structural level support, the Owner is the right person to contact. If there is no dedicated owner yet, escalate it to your management, as they implicitly own what is not explicitly delegated.

If at a certain point security requirements and delivery requirements can not be balanced properly, you may need to escalate and let this decision be made on a higher level. You can escalate jointly with the AppSec lead to the executive leadership in case the risk acceptance needs to be approved. Anyway, remember that all accepted risks must be documented, made visible to all stakeholders, and scheduled for remediation.

Who is the Executor?

The Executor is one of six roles within the AppSec Ownership Model and refers to:

Everyone who actively shapes the software product by design or by writing code.

This includes:

• Software developers

• Software architects

• Dev(Sec)Ops (if we think of infrastructure as code)

This is of course not an exhaustive list. Anyway, within the model, they are all grouped together because from an AppSec point of view, their contribution and accountability are pretty similar.

In practice, their focus may shift within their field of accountability as they execute different tasks within their software development lifecycle.

What AppSec domains does the Executor own?

As the Executor, you need to focus on two AppSec domains:

Secure Coding | Write secure, maintainable code in your daily work.

Secure Design | Lead secure design decisions within your project scope.

If you are a software developer, you may focus less on secure design than an architect, but as a development team, you collectively own those two AppSec domains. You’re the only role that can truly own these domains, because you know your product best.

While you are the expert for your code, you may not be the security expert. We will figure out within the accountability section how the security team can support you within your domains.

What AppSec domains does the Executor support?

When developing secure software is the main goal of application security, it naturally fails when you are no longer able to develop software in the first place. That’s why the whole AppSec program should be built to support and enable the Executor role.

And again, this can’t be done without you, as the Executor. You know what works best for you and what slows you down. That’s why your feedback is necessary to shape the AppSec program within your company.

Here are three additional domains where you should actively support:

Security Tooling | Use tools and provide feedback on any friction.

Tell your security team or project leader, whether the tools actually serve you on a daily basis. Be concrete on what slows you down.

Vulnerability Management | Remediate vulnerabilities in daily work based on project priorities.

In a perfect world, remediation should be scheduled within your project, but in case it’s not: fix whatever comes your way whenever it is suitable.

Incident Readiness | Detect and report suspicious behavior or unexpected system states.

Detecting incidents early can reduce damage along the way. Often there won’t be automatic tools in check of they will just not cover everything. Trust your guts when something seems off and address it. It’s better to be wrong than to let an ongoing attack slip through.

All three of them are owned by other roles within your organization, but your contribution can shape and improve their work.

Now that you see the bigger picture, let’s make accountability explicit.

What is the Executor accountable for?

Here’s what you can hold yourself and your team accountable for:

• Designing secure systems right from the start, not fixing security somehow later.

• Using approved tools in the development workflow (e.g. linters, scanners).

• Asking for clarification when security requirements are missing or unclear.

• Writing secure, maintainable code based on best practices.

• Actively identifying knowledge gaps and improving your secure coding skills.

• Writing meaningful tests, including security-relevant scenarios.

• Reviewing code from a security and quality perspective.

• Selecting appropriate libraries and avoiding insecure packages.

• Keeping dependencies up to date, or flagging outdated ones until they’re fixed.

What is the Executor NOT accountable for?

If AppSec responsibility is not clearly distributed within your company, you may feel responsible to fill in the blanks that are just out of scope for you.

So, here’s what you are NOT accountable for:

• Defining tooling strategy or security policies.

• Making final decisions on risk, severity, or remediation scope.

• Coordinating security initiatives across teams.

• Coordinating incident response.

In practice, whenever you are confronted with expectations or responsibility in those areas (e.g., in an emergency), you can take over, but you should be aware that this is not what your role is expected to do and it’s nothing you should take over in the long run. If those gaps exist, they need to be addressed by your organization on a higher level.

Who does the Executor escalate to?

As the Executor, there are only two roles you are expected to escalate to:

Advocate (e.g., security champions) | For technical questions, missing guidance, tool-related issues or anything that feels security-relevant but cannot be solved locally.

Gatekeeper (e.g., project leaders) | For priorities, backlog planning, dependency updates, or efforts that need coordination within the team.

If your organization doesn’t have security champions, you may need to escalate directly to your security team or try to solve everything with your project leader.

Why control doesn’t work

The old way to do security was based on control. Someone decided who can be trusted, what behavior is acceptable and what needs to be blocked entirely. This approach has one big problem: it works on paper, but is often far from reality. It can actually harm your company’s core business if software developers are no longer able to develop software. At least not efficiently.

What actually works

Trust works. Freedom works. Collaboration works.

Don’t treat your software developers as one of the biggest threats to a secure product. In fact, they can be your biggest asset. Most developers aren’t trying to build insecure products. They are not the ultimate evil you need to protect against. Often, they just miss security knowledge, are pushed by deadlines and kept on a short leash to not think for themselves. Often security is just getting in their way instead of actually enabling them to build a secure product. That’s what we need to fix.

Who is involved in developing secure software?

The developer is building the product. The product is what brings your company money and pays for your paycheck. So I think we can agree that the main character in software development is the software developer. Without someone actually writing code, there will be no product to secure. They drive the software development lifecycle (SDLC). Within the AppSec Ownership Model, I call them the Executor.

Of course, you as the AppSec Lead want them to build secure software, thus turning their SDLC into a secure SDLC. You are the Owner. You educate them. You trust them. You help them to change their behavior. You provide them with everything they need to do their duty.

But there is one person who gets in your way. The project leader is responsible for managing time and resources. They are the Gatekeeper. It’s their job to ensure their team’s time is spent well, so you need to convince them or they will just not let you interfere with their team. They are a valuable asset to you, too. They can help you build security that serves their team, as they will tell you to your face when you expect bullshit tasks from them or their team.

You may find Gatekeepers who are open to work with you, but some may be harder to convince or just refuse to collaborate at all. To get them in line, you need a strong Backbone. Without support from the executive leadership, you will fail.

That’s the bare minimum. Four roles.

How to change behavior

The fifth role is the Advocate. When you start your AppSec initiative, you won’t have a structured security champions program, but you will for sure have some secret champions already advocating for security. It doesn’t matter if they have an official mandate yet or if they just do what they do. You need them.

Developing a strong security culture is what makes your AppSec program sustainable, but it’s hard to achieve. It’s a long journey, but it starts with one intentional step. Changing culture means changing behavior. And your security champions already are role models in what good secure behavior may look like. By building a strong security champions program, you already are on the path to that strong security culture. You just need to keep going and trust the process.

How to speed things up

No, I’m sorry. I don’t have the secret hack to speed up your culture development. But you can speed up your own learning curve as the Owner and reduce your trial-and-error cycles, which will get you moving faster.

We are talking about external expertise. Whenever you hire a coach or consultant, you leverage their experience to learn faster and avoid mistakes they already made. While this can be a big opportunity, it can also be a trap. If you externalize accountability you make yourself dependent on them. That’s why we cover the Catalyst role as the sixth role within the AppSec Ownership Model. The role is optional, but if you choose to use it, you need to know how to avoid the trap and stay independent.

How to get started

We covered all six roles involved in developing secure software. If my point of view resonates with you, feel free to explore the AppSec Ownership Model and use it to clarify accountability within your AppSec program. Accountability is the foundation that everything else is built on.

This model is grounded in my personal experience and I’m more than happy to discuss it with other practitioners who are committed to building security for the real world, not just on paper.

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.

I came up with the AppSec Ownership Model to create a shared understanding with my client of what AppSec ownership actually means. I wanted to put something that was already clear in my head on paper to build their AppSec program on this foundation. You can’t address problems if you don’t know who is accountable for solving them.

What is Application Security?

What are we actually talking about? Developing secure software? Application Security?

Application Security includes every action you take to ensure that the software you build is and remains secure.

The simple reason I came up with this definition is that you need actions to turn an insecure software development lifecycle (SDLC) into a secure SDLC. If you don’t turn thinking into actions, you are just designing on paper, not in the real world.

What makes a SDLC secure?

Now that we know what we are talking about. What actually turns the SDLC into a secure SDLC (SSDLC)?

If you think of AppSec as a big cake, here’s how I would slice it:

1. Secure Design

2. Secure Coding

3. Security Tooling

4. Vulnerability Management

5. Incident Readiness

6. Security Strategy

7. Security Culture

Who needs to take action?

I came up with five mandatory roles and one optional role that share AppSec ownership:

1. The Executor (e.g., software developers)

2. The Owner (e.g., AppSec lead)

3. The Gatekeeper (e.g., project leaders)

4. The Backbone (e.g., executive leadership)

5. The Advocate (e.g., security champions)

6. The Catalyst (e.g., any external expertise) - optional

Every role links to its own deep dive where we:

• define and assign the role

• explore which domains they touch

• clarify accountability

• see which roles they interact with

Can you just give me the bigger picture?

We’ve got seven domains, each of which needs an owner and we’ve got six roles that could own something in theorie. In practice, only the five mandatory roles should take ownership. Externalization of accountability would create long-term dependency and we want to avoid that.

Here’s the AppSec Ownership Model at one glance: