The earlier piece on the Kiteworks shutdown ended with a question that’s been sitting uncomfortably ever since: how are we still finding decades-old file security flaws baked into every major operating system? Two regular voices on this publication took it on directly.
The Optimist: Okay, but let’s start with the obvious response: is this actually surprising? Software has always been built in layers, and old layers don’t get ripped out, they get built on top of. Finding an old flaw in a modern OS isn’t a scandal, it’s just archaeology.
The Skeptic: Sure, it’s not surprising. But “not surprising” and “not a problem” are different claims. The fact that we can explain why it happened doesn’t mean the consequences are small. So what actually changed because this flaw sat there for twenty years undiscovered, or discovered and unfixed?
The Optimist: Fair, so let’s get concrete. A lot of these flaws are in how operating systems handle file paths, permissions, or symbolic links (a symlink is basically a shortcut file that points to another file, and if the OS isn’t careful, attackers can trick it into pointing somewhere sensitive). Those mechanisms were designed in an era before phones, before cloud storage, before every file living in ten sync services at once. The “so what” is that the attack surface (the total number of ways in) grew, but the underlying assumptions never got revisited.
The Skeptic: Right, and that’s the part that matters more than the individual bug. Nobody sat down and said “let’s re-derive file security from scratch for the cloud era.” They patched around the edges. So every new platform, every new sync client, every new “share this folder” feature is quietly inheriting assumptions from a single-user desktop in the 1990s. That’s not a bug, that’s a design debt that compounds.
The Optimist: Which is exactly why finding these flaws now is good news, not bad news. Cloud-scale infrastructure and better tooling mean researchers can actually go back and stress-test those old assumptions at scale. We’re not more broken than we were ten years ago, we’re just finally looking properly.
The Skeptic: Looking properly is good. But “we’re finally looking” doesn’t erase the years where the flaw sat there unexamined in production systems handling real medical records, real financial statements, real government files. So what actually happens to an organization that was running on the old assumption the whole time?
The Optimist: Depends on the sector, but let’s take healthcare since that’s come up before on this site. A hospital system storing patient records probably isn’t touching the raw OS file permission layer directly, they’re going through an electronic health records platform that sits on top. So the practical exposure is narrower than “every hospital just got hacked.”
The Skeptic: Narrower, sure, but not zero. Every one of those platforms was still built on the assumption that the OS underneath handles file access correctly. If that assumption breaks, the platform’s security model breaks with it, even if the platform vendor did everything right on their end. So what’s the actual cost of that, in practice? A hospital doesn’t get to just patch the OS on a Tuesday, they have validation cycles, vendor certification requirements, sometimes FDA-regulated devices that can’t be touched without recertification.
The Optimist: That’s a real cost, I’ll grant that. But it argues for better patch pipelines, not for panic. Financial services deal with the same regulatory friction and they’ve built processes for exactly this: staged rollouts, compensating controls (temporary protections you put in place while you wait to apply the real fix), monitoring for exploitation attempts in the meantime.
The Skeptic: Compensating controls work until someone forgets to remove them or forgets they were ever needed. That’s basically the Kiteworks story from the original piece: “turn it off” was the advice because there was no faster real fix, and turning critical infrastructure off is its own kind of damage. So the actual “so what” here is that when a foundational flaw surfaces, your options are slow-and-safe or fast-and-risky, and most organizations aren’t structured to do slow-and-safe under pressure from customers, regulators, or the news cycle.
The Optimist: Okay, so let’s go further out. If this pattern is baked into how software gets built, layer on layer, old assumptions never fully revisited, then the honest long-term answer isn’t “patch faster.” It’s “some systems need to be rebuilt with modern assumptions from the ground up,” especially anything handling government or critical infrastructure data. That’s a bigger, slower, more expensive project, but it’s the one that actually closes the loop instead of patching it again in ten years.
The Skeptic: And there’s the real cost nobody wants to say out loud: that’s not a security budget line item, that’s a multi-year infrastructure investment competing against every other priority in the organization. Government agencies already struggle to replace systems written in COBOL from the 1970s (an old programming language still running in some banking and government systems), and that’s a known problem with known funding fights. Rebuilding file security assumptions across every major OS is a much bigger version of the same fight, except most executives don’t even know it’s a fight they’re in yet.
The Optimist: Which is exactly why articles like this matter. The awareness gap is the actual lever here. If leadership understood this is a foundational, recurring pattern rather than a one-off CVE (a catalogued security vulnerability) to patch and forget, they’d budget for it differently. That’s the real upside of these flaws surfacing publicly and repeatedly: it forces the conversation up a level, from “patch this” to “why do we keep finding this.”
The Skeptic: I’d agree with that if history showed organizations acting on that awareness. Mostly they patch, breathe out, and move on until the next one. So I’ll believe the awareness gap is closing when budgets shift before the next headline, not after.
What both sides actually agree on is that these flaws are structurally inevitable given how software gets layered over decades, and that the real cost isn’t the individual bug but the slow accumulation of unexamined assumptions underneath critical systems. Where they split is on what to do about it: patch and monitor faster within the system we have, or accept the harder, slower case for rebuilding foundational assumptions in the systems that matter most. Neither side has a clean answer for who pays for that rebuild, or whether any organization will choose to before it’s forced to.
This post is a follow-up responding to a discussion question raised in When “Turn It Off” Is the Security Advice: What the Kiteworks Shutdown Tells Us: “Decades Old File Security Flaws Just Showed Up in Every Major OS. Here’s Why That’s Not Shocking (But Still Matters)”