There's a narrative taking hold in cybersecurity circles, and it needs to be challenged: the idea that critical vulnerabilities are simply inevitable features of modern software, that we should accept them as natural disasters rather than preventable failures.
This thinking is being sold to us everywhere. Conference keynotes celebrate the "speed of innovation" as justification for shipping code faster than security teams can audit it. Enterprise leaders budget for breach response instead of vulnerability prevention. Vendors release patches on a timetable that assumes exploitation is already underway. The message is consistent: vulnerabilities happen. Deal with it.
But this narrative conveniently absolves too many people of responsibility.
Look at the pattern of recent critical flaws. Rails vulnerabilities that expose server files through image uploads. ServiceNow platform flaws allowing unauthenticated code execution. Passkey implementations that fail to account for decades-old attack patterns. These aren't mysteries that appeared from nowhere. They're failures in design review, threat modeling, and security testing that could have been caught before reaching production.
The "vulnerabilities are inevitable" framing serves a purpose for certain stakeholders. It takes the pressure off software makers to slow down and think carefully about what they ship. It shifts the burden entirely onto defenders and enterprises who must scramble to patch. It creates a perpetual treadmill of crisis management that makes security look reactive rather than achievable.
Here's the uncomfortable truth: some vulnerabilities are genuinely hard to prevent. But many are not. Many reflect decisions made in boardrooms and engineering teams to prioritize feature velocity over security discipline.
Consider the passkey flaws mentioned in recent discussions. Passkeys were supposed to be the future, a more secure authentication method. Yet implementations failed because teams didn't consult existing research on authentication attacks. Not because the problem was unsolvable, but because the work of threat modeling and design review was deprioritized. That's a choice, not an inevitability.
The "zero-day is inevitable" narrative also obscures a harder question: How many vulnerabilities remain unfixed not because they're impossible to patch, but because patch economics are broken? When vendors have no incentive to maintain older versions, when security teams lack resources to test patches, when the liability framework makes disclosure more dangerous than silence, we're not dealing with inevitable flaws. We're dealing with a system that rewards delay and punishes visibility.
This matters because narratives shape behavior. If executives believe vulnerabilities are inevitable, they budget defensively rather than proactively. If developers believe their code will have flaws regardless, code review becomes performance theater. If security leaders accept that vulnerabilities are simply the cost of doing business, they stop asking why the cost keeps rising.
The alternative framing isn't naive optimism. It's acknowledging that vulnerability prevention is hard but achievable work that requires investment, discipline, and sometimes difficult trade-offs between speed and safety. It means accepting that not every feature needs to ship in the next quarter. It means threat modeling before coding, not after a breach.
Some vulnerabilities will always slip through. That's reasonable. But the ones that don't is a choice, and the cybersecurity industry has collectively chosen to treat prevention as optional.
That choice deserves scrutiny. Because every time we nod along with the "it's inevitable" narrative, we're giving a pass to preventable failures and accepting a system where vendors, enterprises, and defenders all resign themselves to permanent crisis mode.
Vulnerabilities aren't inevitable. Neglect is.