The Night the Kernel Bled

June 29, 2026 SupportTrenches Systems, Processes & Resilience 7 minutes

Why Smart Companies Are Mad to Trust Any Foreign Software With Their Crown Jewels

You know the date. A single file pushed by a high-profile cybersecurity vendor turned millions of computers into expensive paperweights. Airlines grounded flights. Hospitals stopped surgeries. Banks locked their vaults. It was the largest digital outage in history.

That file ran at the deepest level of the operating system. It could read every byte of memory, every keystroke, every piece of intellectual property on those machines. And it was delivered silently, automatically, without any human approval.

Now ask yourself: how many other files like that are already on your systems?

This isn't about one company or one country. It's about a structural vulnerability that every organization faces when it outsources its security and operational software to vendors with close ties to any foreign intelligence apparatus. Some of these vendors are based in democracies, which is no guarantee that they don't spy on you or aren't concerned about your sovereignty behind closed doors. Some are based in countries with documented programs to use commercial software as offensive tools. Some have even been caught using shell companies to corrupt the supply chain itself.

You don't need to know which ones. You only need to know that the risk exists, and the only safe move is to reduce your dependency.

The Pattern Is Everywhere

Think of a software product that runs with system-level privileges on every machine in your company. The vendor pushes automatic updates. Those updates can contain bugs, backdoors, or - in the worst case - malicious code planted by a nation-state actor. History has shown that:

• A popular endpoint protection product once caused millions of machines to crash because of a malformed configuration file. Recovery required booting into safe mode and manually deleting a single file. Manual. On each machine. No remote access; sysadmins had to drive into the server room to fix this stuff.
• The same vendor's core technology was later found to have a critical vulnerability that allowed attackers to gain the same privileged access the tool itself enjoyed.
• Another widely used operating system vendor quietly introduced a "feature" that periodically captured screenshots of everything users did. It was later called a built-in keylogger and rolled back after public backlash. Or so we have to believe. Not to mention the hundreds of different servers that periodically receive encrypted network data from your systems.
• A collaboration tool vendor suffered a supply chain attack that gave attackers access to the internal systems of tens of thousands of organizations. The software was trusted implicitly because it came from a household name.
• A major mobile phone manufacturer was caught shipping devices with a hidden component from a small foreign software firm that could exfiltrate data without user consent. The manufacturer claimed ignorance.
• A foreign intelligence agency was discovered to have created an entire fake company to manufacture communication devices with hidden explosives, then sold those devices to the target. The devices were in the supply chain for months before detonation.

Every single one of these incidents involves software or hardware that came from a vendor operating under a foreign jurisdiction, often with known or suspected ties to that country's intelligence community. If your organization runs software from any foreign vendor that has kernel-level access, you are exposed to the same risk.

A Genuine Nightmare: A Precision Engineering Firm

Let me tell you about a 500'ish-person engineering firm that made high-value industrial controllers. Their entire firmware repository was stored on servers protected by a popular endpoint detection product from a large foreign vendor.

On the day of the big crash, that vendor's kernel driver failed catastrophically. Every server running the product blue-screened. The firmware repository was corrupted by the crash, and the recovery process was slow and painful.

The company lost three days of production. Their biggest customer had a penalty clause for downtime. The final bill was well over a million euros.

But the worst part came later. During the frantic recovery, a junior employee attached an untrusted USB drive to a partially recovered system. Malware presumably spread into the rebuilt environment. A few weeks after the dust settled, their firmware source code appeared on a black-market forum. They never determined whether an attacker had exploited the crash itself to plant the malware, or whether the USB was the vector. What they know is that a single foreign vendor with kernel-level access became their single point of failure.

Today, that company runs a completely different operating system for their development environment, uses open-source security tools, and keeps offline backups of all critical IP in a fireproof safe. They also require any third-party software with privileged access to be audited by a local lab before going anywhere near their network.

The Quote That Says It All

A well-known tech CEO once said that escaping the ecosystem of a dominant foreign software vendor is harder than achieving a major space exploration milestone. The sentiment is accurate. These ecosystems are designed to be sticky. The more you integrate, the harder it is to leave. And let's be honest: the integration never works as advertised anyway - it's just a hook to get their foot into your door.

But you don't need to escape entirely. You just need to build a lifeboat that doesn't depend on any single foreign vendor's software with kernel-level access.

How to Break Free: Some Suggestions

You can't flip a switch and walk away. But here are practical steps to reduce your exposure over time:

👉 De-privilege the kernel. Push for security tools that run at user level, not kernel level. Use operating system features like eBPF on Linux to get security observability without giving away the keys. If a vendor refuses to offer a user-level alternative, consider that a red flag.

👉 Diversify your operating system base. For servers and engineering workstations, use open-source operating systems where you control the update pipeline. Keep one legacy operating system for compliance-only tasks, but treat it as a thin client for sensitive data.

👉 Audit every piece of software with privileged access. Make a list of every driver, service, and agent that runs with system-level privileges. Challenge each one: "Do we really need this? Can it be run in a sandbox? Is there an alternative from a vendor in our own jurisdiction or an open-source alternative?"

👉 Use source code escrow. For any critical third-party software, require the vendor to deposit the source code with a neutral third party. If they go rogue or disappear, you can at least audit and fork the code.

👉 Run sensitive workloads on infrastructure you control. Use local hosting or vendors that operate under your country's legal framework. Avoid cloud providers that are subject to foreign surveillance laws. Ensure and insist that the employees who manage and support your data in the cloud are not sitting in third-world countries on the other side of the world.

👉 Adopt zero-trust network architecture. Assume any foreign software and hardware can be compromised. Segment your network so that a single compromised endpoint cannot see your crown jewels.

👉 Maintain offline backups. Keep your most valuable intellectual property on encrypted hard drives that are never connected to the network. Rotate them off-site.

👉 Replace foreign security tools with open-source alternatives. There are excellent open-source endpoint detection and response tools that give you full visibility without the foreign supply chain risk.

The Bottom Line

The big crash was not an accident. It was a predictable consequence of a monoculture where a handful of foreign companies own the kernel layer, the cloud, and the update pipeline. The next incident could be worse. It could be a stealthily exfiltrating driver that doesn't crash, just quietly copies your competitive advantage to a server in a foreign jurisdiction. Or, it could be a malicious entity hijacking such tools to gain full access to your system, network and data.

You don't need to trust any vendor just because they have a recognizable brand. Trust is earned, and the track record is often not good.

Building your own defenses starts today.

👇 What foreign software dependency keeps you up at night? What have you replaced?

This article is also available in German.

EuropeInfoSecManagementMonopolyOutsourcingSecurityTechnology