

But first…I’d love to hear from you.
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.
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.
