Seams & Dependencies

Most of the virtual machines running in the world at this moment booted with a root-level backdoor already wired in. I will defend the word. Nobody can count live VMs exactly, but the order of magnitude is not in question: tens of millions on QEMU and KVM alone, and that is the conservative read, because KVM sits under most of the public cloud. On a large share of them, an account on the host can run commands as root inside the running guest. No guest password. No SSH session. No packet on the guest network. It is not planted by an attacker and it is not a bug. It is the guest agent the platform ships, running as root on the far end of a channel the host controls, with the one setting that turns it into a remote root shell left on at install and never questioned since. Documented, default, working as intended. The distance between what that feature is documented to do and what anyone actually defends against is the ground we build on. ...

The rule that lets the application reach its database names an identity, not an address. No IP. No CIDR. No route. No security group. Written that way, the rule holds the same on one node or a thousand, on-prem or across three clouds, and it does not break when a pod moves, because nothing in it ever said where anything was. In part 1 the same application connected to MySQL with no password, on one host. If part 1 was “the credential is not a string,” this is part 2: “the perimeter is not a subnet.” Same demo, same images, same page, same SQL. This time the application and the database live in different Kubernetes namespaces, and one new idea carries the whole piece: the network itself reads the identity. ...

The application connects to MySQL without a password. Not “the password is in a vault.” Not “the password is injected at deploy time.” Not “no password needed because the request comes from an allow-listed IP.” No password at all. There is no string, anywhere, that logs into that database. That sentence is where I recently lost a friend, a senior engineer at one of the biggest tech companies you can name, while explaining my fleet-security work. He made me say it three times. And he is not behind; he is normal. Zero-trust workload identity is still a novelty to most people who run real infrastructure, including very good ones. ...

A friend called last week with a familiar complaint. He had built his workload inside AWS Nitro Enclaves, and he wanted out. His words, not mine: “Pretty easy to get in. Pretty costly to get up. Impossible to get out.” A friendly onboarding pipeline had generated his key for him and left it sitting right there in the console, and he honestly could not tell you whether it was his to take somewhere else. AWS ran the attestation. AWS decided, on every request, whether his own code was allowed to touch his own secrets. Then he asked the question that started this article. How do I port this to another provider? ...

In September 2006, a Debian maintainer did everything right and broke the world’s trust for a year and a half. He was cleaning up the OpenSSL package. Valgrind and Purify, the memory checkers every careful engineer is supposed to listen to, kept flagging two lines in md_rand.c. The lines read uninitialized memory. That’s a sin. Undefined behavior, the kind of thing you delete without a second thought. So he deleted it. ...

In Brazil, when advising a customer on endpoint security, there was a mental model we never said out loud. The technical discussion would cover detection rates, false positives, memory footprint — the usual. But underneath it ran a question that never made it into the RFP: who do you want knowing what you’re doing? Russians or Americans? Kaspersky was the default for most of the market — and not because of ideology. Norton and Symantec had spent years earning their reputation for turning Windows machines into molasses, and McAfee was McAfee. Kaspersky worked. It was lighter, faster, cheaper. The fact that its telemetry flowed to Moscow rather than Langley was a feature, not a bug, depending on which side of the table you sat on. ...

This is the third and final part of a series based on a real-world engagement: a company that scaled from $40M to $1B in annual revenue in just five years, and the security program that had to grow with it. This is a story about building high-performance operating systems where security, standards, architecture, and performance act as enablers rather than constraints. Part 1: Earning credibility before you’ve earned authority. Part 2: Blurring the lines — Security at the SRE and Operations level. Part 3: Wrapping the gift — Transparency and agency. The Quality That Can’t Be Purchased I’ve been writing around this idea for a while — in Cold Aisle Trenches, in why standards fail when you try to impose them, in how defense in depth actually works at scale. The thread is always the same: security can’t be bought. You can’t swipe a credit card and receive “secure” in a box. It’s a quality that emerges — like the lights-out data center you don’t chase but eventually arrive at, because every other piece fell into place first. ...

This is the second of a three-part series based on a real-world engagement: a company that scaled from $40M to $1B in annual revenue in just five years, and the security program that had to grow with it. This is a story about building high-performance operating systems where security, standards, architecture, and performance act as enablers rather than constraints. Part 1: Earning credibility before you’ve earned authority. Part 2: Blurring the lines - Security at the SRE and Operations level. Part 3: Wrapping the gift — Transparency and agency. From Trust to Reliance ...

This is the first of a three-part series based on a real-world engagement: a company that scaled from $40M to $1B in annual revenue in just five years, and the security program that had to grow with it. This is a story about building high-performance operating systems where security, standards, architecture, and performance act as enablers rather than constraints. Part 1: Earning credibility before you’ve earned authority. Part 2: Blurring the lines - Security at the SRE and Operations level. Part 3: Wrapping the gift — Transparency and agency. The Inflection Point A few years back, AMTI was at the heart of a fascinating corporate challenge. I was serving as a fractional CISO and advisor for a company standing at a critical inflection point. ...

A bricked storage array, a 2+4 SLA that technically performed, and a technician asking about lunch while executives circled. We learned that risk transfer is an illusion when your blood is on the floor. January 2026 · Stefano Schotten The contract was honored. The business still bled. My case manager called me from the customer site. I could hear the tension before he said a word. “The VPs are pacing. Four of them, maybe five. They’re all just… standing around IT, watching.” ...

A few years ago, I was having dinner with the Americas VP of a European energy supermajor — one of those companies that extracts oil from war zones, negotiates with regimes that don’t appear on polite lists, and operates in places where “political risk” means your assets might get nationalized or your personnel kidnapped. Seventy-plus countries. Active operations in Libya, Nigeria, Angola, Myanmar, Yemen. The kinds of places where security briefings come before breakfast. ...

In 2015, I did what seemed like the mature thing to do. I created a Production Engineering department. My college foundation was production engineering. I was a true believer: if we formalized standards and assigned a dedicated group to own operational rigor, the organization would naturally converge toward consistency. The mandate: Create SOPs. Define standards. Reduce variance. Improve reliability. On paper, it was textbook. In practice, it was a slow-motion collision with reality. ...