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.
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 (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:
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.
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:
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.