Security Has a Product Problem

I found my first critical vulnerability in a production system in about forty minutes. It took the engineering team three months to fix it.

That gap between finding something real and getting an organization to act on it is where I’ve spent most of my career. Not because I stayed in offensive security. Because I couldn’t stop thinking about why the gap existed at all.

The tools were fine. The people were talented. Something structural was broken. And it took me years to name it clearly: security programs fail for the same reason bad products fail. They’re built for the people running them, not the people who need to use them.

The Pattern Shows Up Everywhere

At Yahoo, I was part of the Paranoids team, the internal security group responsible for vulnerability disclosure. Our program ranked #1 on HackerOne globally for FY2019. We had world-class researchers, real findings, and a functioning triage machine. By any offensive security benchmark, we were winning.

And companies with equally talented security teams were still getting breached.

Not because their engineers couldn’t find vulnerabilities. Because the findings weren’t going anywhere. Reports piled up in queues. Developers didn’t understand the severity framing. Security teams measured themselves on issues opened, not on whether engineering behavior actually changed.

I watched this pattern repeat across organizations. A SAST tool deployed across 300 repositories, with a 4% fix rate six months later. A penetration test that produced a 90-page PDF that two people read. A compliance audit that passed, followed by a breach three months later from a vector the audit had technically covered.

The security industry has spent decades getting better at finding problems. It has spent almost no time thinking about adoption.

The Thesis: Security Is a Product Problem

When I say security is a product problem, I mean something specific. Not a metaphor, not a reframe for a conference talk.

Products get designed around the people who use them. They have onboarding, feedback loops, and clear value propositions. When a product fails to get adopted, the team investigates why: friction in the workflow, unclear messaging, poor timing, a mismatch between what it does and what users actually need. Nobody assumes the users are wrong.

Security programs almost never work this way.

The default model is: identify what’s technically correct, enforce it, and hold engineering accountable for non-compliance. The implicit assumption is that adoption is a behavior problem, not a design problem. If engineers aren’t remediating vulnerabilities, they need to be educated, incentivized, or escalated to.

This is the wrong model. It’s the equivalent of shipping a product nobody asked for and then blaming the market for not buying it.

Security tools fail to get adopted for the same reasons consumer products fail: poor onboarding, unclear value to the user, high friction relative to alternatives, and no feedback loop that connects the user’s action to a meaningful outcome. The fact that the organization needs the security capability is irrelevant to whether the individual developer chooses to engage with it.

When I internalized this, the question I was trying to answer shifted completely. Not “how do we find more vulnerabilities?” but “how do we build a security capability that engineering wants to use?”

What Building It Differently Looks Like

At Hulu, I built the responsible disclosure program from scratch. I could have started with a policy document: scope definitions, legal boilerplate, researcher terms. That’s how most bug bounty programs begin.

Instead I started with two questions: what does a researcher need in order to submit a high-quality report, and what does an engineer need in order to trust and act on it?

The program architecture followed from those questions, not from compliance requirements. Triage workflows were designed to minimize the time between submission and acknowledgment, because slow response rates kill researcher engagement faster than low bounty amounts. Severity framing was aligned with how engineering teams actually prioritized work, so findings didn’t get lost in translation. We built the thing to get used, not to satisfy a checkbox.

The result: 370+ vulnerabilities identified, $270K in researcher payouts, and a triage process that engineering teams understood and trusted. The program generated signal, not noise.

At Disney, the mandate was larger: ASPM strategy and developer enablement across a global engineering organization. The same principle applied at a different scale. The goal was never coverage. It was adoption. Security tooling that developers actively use generates better signal than tooling deployed at 100% coverage and ignored.

That means designing integrations that fit into existing developer workflows rather than demanding new ones. It means instrumentation that shows a developer the risk in their specific codebase, not a generic score. It means measuring adoption rate, not just deployment rate, and treating low adoption as a product failure, not a people failure.

Why This Matters Beyond My Career

I’m not writing this as a retrospective. I’m writing it because the gap I noticed in my first security role is still the dominant failure mode across enterprise security programs, and it’s gotten harder to solve as the tooling landscape has expanded.

The number of security products available to enterprises has exploded in the last decade. Every category has ten vendors. The average security organization is running more tools than it was five years ago and generating more findings, more alerts, more reports. Adoption hasn’t kept pace. Alert fatigue is a real organizational dysfunction, not a solvable configuration problem.

The answer isn’t more tooling. It isn’t better threat intelligence. It isn’t a more sophisticated vulnerability scoring framework.

It’s product thinking applied to how security programs are built, deployed, and measured.

That means treating engineering teams as users, not subjects. It means designing security capabilities with the same rigor applied to onboarding, feedback loops, and value delivery that a product team would apply to a customer-facing product. It means measuring what changes, not what’s deployed.

The industry is starting to move in this direction. ASPM as a category is partly a response to the adoption problem, an attempt to consolidate signal and make it actionable. AI is accelerating parts of the detection and remediation workflow. But the architectural problem isn’t technical. No tool fixes a program that was designed around the wrong user.

The Through-Line

I recently completed my MBA at UT Austin. People sometimes ask why a security engineer goes back to business school.

The answer is that I was already doing product management and organizational strategy. I just wanted a more rigorous framework for doing it well. The MBA formalized something I’d arrived at by trial and error: that the hardest problems in security aren’t technical, they’re organizational. They require the same skills that make businesses work: understanding your users, designing for adoption, connecting what you build to outcomes that leadership can act on.

Security at its best is a business enabler, not a cost center. Secure systems move faster because they generate trust with customers, with partners, with regulators. Engineering teams that have good security tooling integrated into their workflow don’t slow down; they stop carrying the anxiety of shipping something they don’t fully understand.

That version of security, as a capability teams want rather than a gate they resent, is what I’ve spent my career building toward.

The tools exist. The talent exists. What’s missing, almost everywhere, is the product thinking to make it stick.