Nobody Asked Engineering for a Software Bill of Materials. Procurement Did.

A software bill of materials is a machine-readable inventory of the components inside a product: libraries, versions, licences, and increasingly the relationships between them. The idea is old and the formats are stable. What changed is the route by which the requirement reaches a development team. It used to arrive after an incident, when a widely used component turned out to be vulnerable and every organisation on earth spent a fortnight trying to answer whether they used it. Now it arrives in a procurement questionnaire, a public-sector tender condition, or a renewal clause in an enterprise contract. That routing matters more than it sounds. A security recommendation can be prioritised against other engineering work and deferred with a note. A contractual condition cannot: it has a date, a counterparty, and revenue attached. Teams that had an inventory on a roadmap find it moved to a deadline set by a customer's legal department, and the first attempt is usually a scramble because generating the file is easy while generating a file that is actually true is not. The harder half of the requirement is provenance — not just what is in the artefact, but evidence about how it was built: which source commit, on which builder, with which inputs, signed in a way a third party can verify. This closes the gap that an inventory alone leaves open, where the list is accurate about a build that may not be the build that shipped. The tooling here has matured substantially and much of it is free, but it demands something many pipelines never had: a build that is reproducible enough to be worth attesting to, and a release path where nothing is patched by hand after the build. The failure mode to avoid is treating this as a document to produce rather than a process to run. An inventory generated once for a tender and never regenerated is stale within weeks and is worse than none, because it answers a question wrongly with an official-looking file. The organisations getting value rather than compliance theatre generate the inventory as an output of every build, store it with the artefact, and — the step that actually pays — feed it into their own dependency monitoring, so that the next time a widely used component is found vulnerable, the fortnight of searching is a query.