Supply Chain Security

Here is a situation that has quietly become everyone’s problem. A vendor ships you a piece of software, and along with it a file called bom.json. It is a Software Bill of Materials, or SBOM: a machine-readable list of every open-source component inside that software, the same way a packaged food lists its ingredients. Regulators now ask for these, procurement teams now demand them, and your own security team now receives them. So the file lands in your inbox. Now what? ...

A number travels further than the system that produced it. A CI job says a model scored 0.97 on a benchmark, and that 0.97 ends up in a Slack thread, a slide, a vendor questionnaire, an audit binder. By the third hop, nobody can say who produced it or whether it’s the same number the job printed. It’s a screenshot. The standard fix is a digital signature: the producer signs the result with a private key, and anyone holding the matching public key can check that the bytes haven’t changed and that the key holder signed them. Signing software artifacts is well understood by now; projects like Sigstore do it at scale. But most of that machinery assumes the person checking can reach the internet: a transparency log, a certificate authority, an identity provider. An auditor in a locked-down review room, or an incident responder archiving evidence for a year, may not have any of that. ...

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. ...

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. ...