Breaches Optional?

Earlier this week, watching Punxsutawney Phil pop his head out reminded me to do the same. Four weeks ago, I cut back on my workstreams to focus on a few key priorities. Today, I wanted to give you a quick update on what I’ve been working on.

But first…I’d love to hear from you.

What’s your biggest challenge in product security? What problem are you working on? I want to make sure my content actually helps solve real problems. Hit reply and let me know.

Course Update: DevSecOps With AWS & GitHub Actions

A few months ago, I started building my next course: DevSecOps With AWS and GitHub Actions. Producing a course from scratch has been exciting and frustrating. From navigating a maze of tech platforms, including designing a site, filming and editing videos, setting up payments, tracking taxes, automating sign-ups and everything in between. Finding guidance and help has been a struggle, but I finally figured it out. If you’ve ever thought about building your own course, hit me up. I’m happy to share what I’ve learned.

Despite the learning curve, I’m making progress. I just wrapped up the SAST section of the course. I’ve completed 23 lessons and have 6 to go.

My goal is to provide the type of training you’d get from SANS or OffSec, but at a price that doesn’t exclude people who aren’t working for big companies with healthy training budgets. Instead of paying $2K–$9K, I’m aiming for something in the hundreds, so self-funded learners can actually afford it.

Breaches Optional?

A few months ago, my friend and mentor, a security veteran with 25+ years of experience, gave me an interesting perspective.

We were discussing the “assume breach” mindset, and he said:

“Imagine starting a marriage by telling your soon-to-be spouse they should assume infidelity.”

Before you fire off a strongly worded reply, hear me out.

I get that the assume breach mindset isn’t an admission of failure. it’s an acknowledgment that trusted zones don’t exist. It means building systems that assume attackers are already inside. But to business executives, assume breach sounds a lot like security is has little faith in their ability to prevent breaches. That’s not a reassuring message.

My friend asked the question, what if breaches were optional?

I don’t mean optional in the way that updating your open source libraries or writing unit tests. I mean truly optional. As in, what if defensive mechanisms were so advanced that you could opt out of breaches.

A century ago, commercial building fires were devastatingly common. Today, thanks to engineering and fire prevention standards, large-scale commercial fires like the Great Seattle Fire of 1889 are nearly unheard of. This is largely because we have much better:

  • Detection (smoke detectors)

  • Containment (fire isolation zones)

  • Automated response (sprinklers)

Security should evolve the same way. Breaches should become the exception, not the norm. Organizations that still suffer breaches would do so because they’ve chosen not to implement widely available security controls.

That’s the vision we’re working toward. Some security engineers think we’re delusional. Others see it and get excited.

I can’t share details now, but we’re looking for organizations struggling with SCA (Software Composition Analysis) remediation to be part of our MVP customer group. If that sounds like something you’d be interested in, let me know.

That’s it for this week.

Subscribe to the Newsletter

Join other product security champions getting deep dives delivered to their inbox for free every Tuesday.

Follow us:

Quick Links

Supports Links

Quick Links

© 2025 Mission InfoSec. All Rights Reserved.