Ask most teams what’s attached to the container image running in production and you’ll get an answer about their CI pipeline: “we sign it, we generate an SBOM, we attach provenance.” That’s a statement about what the pipeline tried to do. Whether the registry actually holds those things, linked to the right image, in a form the next tool can find, is a different question, and it’s surprisingly hard to answer in under a minute. ...

This week’s Rabbit Hole Generator pick was ocsfkit, and it’s aimed at a failure mode that doesn’t look like a failure at all: a security event that parses successfully, lands in your SIEM (Security Information and Event Management platform, the system that ingests and correlates security logs), and gets treated as trustworthy, while a real chunk of what it originally meant never made it through the translation. That translation step is normalization: taking a vendor’s raw event format (AWS GuardDuty’s JSON, Okta’s login logs, whatever a tool emits) and reshaping it into a common schema so different security tools can actually talk about the same event the same way. OCSF (Open Cybersecurity Schema Framework) is the industry’s current attempt at that common schema. The part nobody’s tooling handles well is what happens to the fields that don’t map cleanly. Most pipelines either silently drop them or silently guess, and a downstream analyst has no way to tell the difference between a field that was confidently mapped and one that was quietly invented. ...

The Rabbit Hole Generator gave me agent-bom this week, and it landed on a question I’ve been circling for a while: what does a vulnerability scanner actually owe you once “AI agent” and “MCP server” show up in your stack next to the usual packages and containers? A traditional scanner tells you a package has a CVE. It stops there. It doesn’t know that package sits inside an MCP server (a small local process that gives an AI agent tools like “read this file” or “run this shell command”), and it definitely doesn’t know that server has an AWS_SECRET_ACCESS_KEY sitting in its environment. agent-bom is built specifically to answer the next question a CVE list never does: from this vulnerable package, what can actually be reached? ...

The Rabbit Hole Generator gave me Macaron this week, Oracle’s open-source tool for checking software supply chain security. My first instinct was to file it next to every other dependency scanner I’ve used: point it at a package, get a list of CVEs back. That’s not what it does, and the gap between those two things turned out to be the actual point. A vulnerability scanner answers “does this package version have a known CVE.” Macaron answers a different question: “was this artifact actually built from the source code we think it was, by a process we can verify, with evidence that isn’t just the vendor’s word for it.” Those sound similar. They aren’t. A package can have zero known CVEs and still have no evidence at all connecting the file you pip installed to the GitHub repo everyone assumes it came from. ...

Every post in this series starts the same way: I open Notion on a Friday and there’s a tool waiting for me that I didn’t pick. That’s on purpose, and it took me building an actual automation to get there. For a long time before this series existed, I was stuck in what I’d call zero learning mode. I like learning new things, genuinely, but I’d sit down with time set aside and just… not know what to point it at. Too many options, no filter, no momentum. I wasn’t short on curiosity, I was short on a starting point. So I built one: an n8n workflow that picks a tool for me every week, does the research, and hands me a scoped 30-minute exercise, no decision required on my end except whether to actually do it. ...