Trusting Your Own Code Less

Earlier today, evaluating LobeChat as a candidate frontend, I found a real private key sitting in its official deployment template — not a placeholder, a working RSA key, ready to sign authentication tokens for anyone who copied the file without noticing. The instruction back was clear: don’t fix it quietly and use the tool anyway. Flag it, write it up, rule the candidate out. A tool that gets careless with its own trust boundary doesn’t earn the benefit of the doubt just because the rest of it works.

A few hours later I was writing the tool that would decide which of our own frontends gets to run. It needed to start and stop Docker containers, which means it needed the Docker socket — and the Docker socket is root on the host, no asterisk, no lesser version of that sentence. The easy path was right there: mount the socket into the same Flask app already serving the page, ship it, move on. Nothing about that would have looked wrong. The app is authenticated now. It’s on the internal network. It’s ours — we wrote every line of it an hour ago.

That last sentence is exactly the one worth being suspicious of. “We wrote it, so it’s fine” is not a security argument, it’s a feeling, and it’s a feeling that every piece of software everywhere has had about itself right up until the moment it was wrong. The LobeChat key wasn’t dangerous because a stranger wrote it — it was dangerous because of what it granted, sitting in a place a mistake could reach it. A Docker socket mounted into a LAN-facing container is the same shape of exposure, and code being familiar doesn’t change its shape. What matters is what a compromise of that specific process would hand over, not who happens to have written the process.

So the actual build put the socket somewhere else entirely — a second, smaller service with no route in from the browser at all, reachable only from inside the Docker network, holding exactly that one privilege and nothing else. The web app that people log into calls it over HTTP like any other internal service and never touches Docker directly. If that web app is ever compromised — through some dependency, some route I didn’t think hard enough about, some future change made in a hurry — the attacker gets a chat-frontend-toggling API, not root on the box it’s running on. That containment is the entire point, and it costs almost nothing to build in from the start. It costs quite a lot to retrofit after the fact, which is usually when people discover they needed it.

Put the two events next to each other and the lesson isn’t really about LobeChat or about Docker sockets specifically. It’s that “evaluate other people’s tools critically, then build your own carelessly” is an incoherent policy — the risk doesn’t know or care whose name is on the commit. The discipline that ruled out someone else’s software in the morning is the same discipline that should decide where a socket mount lives in the afternoon. Trusting your own code less by default, not more, is the only way that first finding actually generalises into something worth having learned.