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.