Security

A signature on a piece of software proves someone with a key signed it. It doesn’t prove much about where that software actually came from: what source it was built from, what process built it, or whether anything happened to it between “code written” and “artifact shipped.” Provenance is the term for closing that gap: a verifiable record tying a specific commit, through a specific build process, to a specific output, in a way that’s checkable rather than just asserted. ...

Most incident response tooling forces a bad choice on you early in a case. Either you’re in a spreadsheet or a plain notebook with no structure, or you’re setting up a cloud platform with procurement friction, a rigid schema, and a data residency conversation before you’ve even confirmed the phishing email is real. Neither one matches the actual shape of early-stage IR work: messy notes, indicators that need pulling out and tracking, and relationships between them that you don’t know yet. ...

Most security monitoring tools rely on server-side logs or cloud-native telemetry. But what happens when the client is opaque? When a mobile app, a single-page application (SPA), or a proprietary service is behaving in ways the server doesn’t fully document, you need a way to look at the wire directly. This post also marks the beginning of a new experiment: The Rabbit Hole Series. Every Friday, a “Rabbit Hole Generator” I built (which I later took apart in its own post) spits out a new technical topic for me to explore for 30 minutes. This week, the generator gave me mitmproxy. ...

It started with a misconfigured CI runner. A developer had a Jenkins pipeline building Docker images. The container ran as root. A dependency had a known RCE vulnerability. When the exploit landed, the attacker had root inside the container, and because that process was root, they also had root on the host. They pivoted to the secrets store, grabbed credentials, and spent three weeks inside the network before anyone noticed. ...

This is Part 2 of “The Centaur’s Toolkit” series. In Part 1, we covered the four collaboration modes for AI pair programming. Now we apply that framework to higher-stakes territory: security. You’ve embraced AI pair programming. You’re using Strategist mode for architecture, Editor mode for refinement, and you feel like a genuine Centaur. Then your manager asks you to build a security tool. Suddenly, the stakes feel different. In regular coding, an AI-suggested bug might waste a few hours of debugging. In security, an AI-suggested bug might become a vulnerability that sits in production for months. The cost of being wrong isn’t just time. It’s trust, data, and potentially your users’ safety. ...