Security Journey Blog

Tapping Other Fields to Approach Security Differently

Written by Dustin Lehr | Feb 10, 2026 2:00:02 PM

Reflections on my Security Champions Podcast episode featuring John Benninghoff

During our latest Security Champions Podcast episode, I sat down with longtime security leader John Benninghoff to explore a simple idea with big consequences: what if we treated security like other mature safety disciplines? From “security as decision support” to empowering developers with time and tools, John’s lens, rooted in safety science, economics, and lived AppSec practice, offers a practical path to better security performance.

“A security amateur knows how to secure things; a security professional knows when you don’t have to.” This clarifies much of what John Benninghoff stands for, and it’s something I’ve learned through my years in security as well. In fact, the more time you spend in AppSec, the more you realize our real constraint isn’t knowledge of controls; it’s judgment, prioritization, and the human systems we operate inside.

John’s the kind of guest who makes you think and then gives you something you can apply starting tomorrow. If you want to dig deeper into his work, check out his website and writings here: jbenninghoff.com and security-differently.com.

Why security needs a different playbook

We’ve poured decades into more rules, more scanning, and more dashboards, yet the aggregate risk picture keeps trending the wrong way. During the episode, John offered a reason: in aviation and fire safety, performance improves because those fields optimize for how people actually work, not how policies imagine they should. When incidents happen, the goal isn’t to find the person to blame; it’s to understand the conditions that made the outcome likely, and then design to address them.

This “work-as-done” mindset showed up everywhere in our chat—from developers asking for “encryption” when what they really need is access control, to teams begging for a pen test when the real ask is clarity, time, and the right fix.

Safety Differently → Security Differently

Safety Differently (popularized by Sidney Dekker in the book “Safety Differently: Human Factors for a New Era”) argues for a shift from viewing humans as the source of error to seeing them as the solution. John’s translation to security is spot on: you should judge your people-focused system by how well it performs when faced with routine threats, not by how long it’s been since your last breach. He said it best during the show: “You can't define your security success by absence of breaches. You have to define it in terms of performance when you encounter some kind of threat.”

That shift moves us from focusing on reducing issues to zero to designing for resilience.

Two practical implications stood out:

  • Empower the people who pursue security every day. Experienced developers often know what “good” looks like. What they need is time, tooling, and leaders who remove friction. Security’s job is to support performance, not micromanage it.
  • Measure what matters. Count the rate of meaningful vulnerabilities per N assets and your time-to-remediate results, not the age of the oldest bug as if time itself creates risk. Negotiate “security level objectives” with engineering and leadership so maintenance has an explicit budget and cadence. 

Influence over authority (again)

We also talked about the old trope that “developers don’t care about security” and John’s take added a new dimension: seasoned developers often know more about security in the context of their system than a junior security analyst, because context is everything. Treat developers as knowledgeable partners, not inferior trainees. Ask better questions. Sit next to them and watch work as it happens. Be curious in order to uplevel your understanding, and your influence.

And leadership? Saying “security matters” on stage is easy. Actually funding time for maintenance, refactors, and upgrades is the real test, and doesn’t always happen.

Cross the streams: borrow from other fields

Security is inherently multidisciplinary. Here are some of the fields we can better draw from based on John’s suggestions as well as my own experience:

  • Safety science: checklists, capacity for failure, and investigations that improve the system, not shame the human.
  • SRE/Operations: shared obsessions with observability, incident response, root-cause analysis, and learning from outages.
  • Economics & incentives: business growth goals mean organizations systematically underspend on security. Expect insurance and regulations to continue defining the bar.
  • Change management & marketing: the technology adoption curve applies to security culture change too. You must design a useful product and effective communication strategy so that people want to adopt it.
  • Sales: When you become a security person, you become a salesperson! A few people don’t like when I say that, but I think more and more are realizing the truth behind this statement, so I’m going to stick to it.

Some takeaways to get started on tomorrow:

  1. Ask, don’t assume. When a team asks for a pen test (or “encryption”), get curious about the root problem they want to address before prescribing a solution.
  2. Define Security Level Objectives. With engineering + leadership, set acceptable vulnerability rates and time-to-remediate requirements for high-value assets. Fund the work that keeps you inside these guidelines.
  3. Pair IR with Ops. Treat security incidents like any other reliability incident: shared tooling, runbooks, blameless reviews, and tracked follow-through.
  4. Protect developer time. Make “time to do it right” an explicit, budgeted constraint, not a heroic after-hours activity.

One Last Call To Action!

If you want a stronger security program, study a field outside our bubble. Safety science, SRE, economics, change management, marketing, finance, sales, etc.—each field offers tools and techniques to build more well-rounded and effective security capabilities, and learning their secrets will help you connect the dots you didn’t realize were there. Make it a point to pick a different field and start digging into it this month. And if you're brave enough, reach out and share what you’ve learned! We’re all in this together and everyone has something to offer.