Security When You're a Two-Person Infrastructure Company
The objection nobody says out loud, answered in public
In March 2024, a database engineer noticed his SSH logins were taking about half a second instead of a tenth of one, and he pulled on that thread until it unraveled into the xz-utils backdoor: a multi-year operation in which an attacker patiently earned maintainer trust in a tiny open source project that nearly everything links against. The most sophisticated supply chain attack in memory wasn't aimed at a big company's firewall. It was aimed at one exhausted volunteer.
I bring this up because it reframes the question people politely avoid asking us. The unspoken objection to an infrastructure vendor our size isn't a specific vulnerability. It's a feeling: surely two people can't do security. My claim is that the feeling deserves to be replaced with specific questions and specific answers, because size cuts both ways, and the xz incident is what the failure of a giant, distributed trust model looks like.
What small actually changes
Start with the honest downsides. There's no security team, because there's no team to carve one from. Code review has exactly one reviewer. If both of us are asleep, nobody's awake. A serious compliance questionnaire takes us days we don't have, and a SOC 2 audit costs real money we'd rather spend on engineering. Anyone who tells you smallness is secretly a security advantage across the board is selling something.
But the advantages are real too, and they're structural rather than heroic. Two people is a tiny social attack surface: nobody's going to phish an HR department we don't have, or social-engineer a support tier that doesn't exist. There's no forgotten test cluster from a team that disbanded in 2023. Every credential that exists is known to both of us, every service that runs was started by one of us, and the entire system fits in two heads, which is a property most CISOs would trade a tool budget for.
The xz lesson lands here. That attack worked because the system was too large for anyone to hold: thousands of dependencies, each a trust decision nobody remembers making. Our defense is refusing that shape where we can. Fewer dependencies, pinned and reviewed when they change. Boring, widely-watched components over clever ones. And we buy our lowest layers, tenant isolation included, from a hyperscaler's managed primitives rather than rolling our own, because pretending two people should hand-build multi-tenancy is exactly the kind of confidence you should run from.
The questionnaire, answered in public
The table below is the short version of what due diligence usually asks us, answered the way we answer privately. The honest column is the point.
| What you should ask | Our answer | Status |
|---|---|---|
| How are tenants isolated? | Workloads run in isolated containers on managed cloud primitives; we don't share a process across customers | In production |
| Who can access production? | Two named people, MFA everywhere, least-privilege credentials | In production |
| What happens if one of you disappears? | Shared credential custody and written runbooks | In production, reviewed rarely |
| Where are secrets kept? | In a managed secret store, scoped per environment; never in the repo | In production |
| Are you SOC 2 certified? | Not yet; it's on the roadmap, and we say so instead of implying otherwise | Not done |
| Do you run a bug bounty? | No; we take reports by email and answer fast | Not done |
Two of those rows say "not done". Leaving them visible costs us deals, and hiding them would eventually cost us customers, and of those two prices only one compounds.
One answer belongs outside the table because it's a promise rather than a control. If we're ever breached, you'll hear it from us first, in plain language, with a timeline of what happened and what we changed, and before any lawyer smooths the edges off. Companies a thousand times our size routinely fail that bar. It's the one security capability where being small carries no handicap at all.
The steelman: big vendors really do have things we don't
A serious counterargument deserves its space. A large vendor has a 24/7 security operations center, red teams, dedicated incident response, and auditors on retainer. Those aren't theater. At 3 a.m. during an active intrusion, headcount is a genuine capability, and a SOC 2 report, whatever its limits, at least proves someone examined the controls. If your risk model requires that machinery today, we're the wrong vendor today, and I'd rather say so than argue you out of a reasonable requirement.
What I'd push back on is the inference from big to safe. Blast radius scales with the vendor: when a large platform is breached, the incident arrives with their entire customer list attached. Trust in a vendor of any size ultimately rests on the same two things: whether the isolation between you and other tenants is real, and whether you can leave quickly if your trust turns out to be misplaced. We build for both, and the second one, portability, is the security control almost no questionnaire asks about.
Security for a company like ours isn't a claim to be believed. It's a posture to be inspected, and this post is part of keeping it inspectable. If you'd grill us harder than that table does, send the questions; the honest answers are the cheapest security investment we make. What's the "not done" row your current vendor hasn't shown you?
Related: So I Started a Cloud Company Out of Spite, the story of why this company exists at all. More about what we're building at light-cloud.com.