Meet the “Bill of Materials” Idea: Before CBOM, There Was SBOM

A bill of materials is not a technology term. It’s a manufacturing term, and it predates computers entirely.

If you build furniture, a bill of materials is the list that comes with the kit: four legs, one tabletop, sixteen screws, two hinges, one Allen key. If you build a car, it’s a much longer version of the same thing: every part, every supplier, every specification, all written down before assembly even starts. Nothing gets built at scale without one. You can’t order parts, track a recall, or hand the design to a new factory without a complete list of what’s actually in the thing.

Somewhere along the way, someone asked the obvious question: modern software is assembled the same way furniture and cars are, out of parts other people built. A single application might be built from hundreds of open-source components, each maintained by different people, updated on different schedules, with different histories. So why wouldn’t software get the same kind of list?

That list has a name: a software bill of materials, usually shortened to SBOM. It’s exactly what it sounds like. A complete inventory of every component that went into a piece of software, down to the specific version of each one.

SBOMs went from a niche best practice to something governments actively require in a fairly short window. The event most people point to is the one we mentioned last time: the Log4j incident in late 2021, where a flaw in one widely used component sent security teams everywhere scrambling to figure out whether they were even using it.

That scramble made a simple point impossible to ignore. Companies with an SBOM already in hand answered “are we affected?” in hours. Companies without one spent weeks finding out, and some never found out at all. The United States had already written SBOMs into federal software procurement earlier that year, through an executive order most people outside government never read. Log4j is what turned that requirement from paperwork into an obvious necessity, and the rules telling agencies to actually collect SBOMs followed the next year.

Here’s the part that sets up everything the rest of this series is about. An SBOM tells you a system uses a particular encryption library, by name and version. What it does not tell you is what that library is actually doing: which specific encryption method it’s configured to use, how strong the keys are, whether it’s set up in a way that’s still considered safe.

Going back to the car: knowing the vehicle uses a particular ignition system doesn’t tell you whether that ignition system was ever recalled for a fire risk. You’d need a more specific list for that. Encryption has the same gap. A component list tells you a login system uses a well-known security library. It doesn’t tell you which specific settings that library was configured with, and it’s entirely possible for a good library to be configured badly.

Knowing what’s in the box isn’t the same as knowing what the box does.

That gap is exactly what a cryptographic bill of materials exists to close. It takes the same “list everything” instinct behind an SBOM and points it specifically at encryption: not just which library is present, but which algorithm, which key size, which configuration, and whether that configuration is still considered sound.