A software bill of materials is an inventory. Every component, its version, its origin and how it got there.
It is now a compliance requirement in several jurisdictions, which means a great many organisations produce them and a rather smaller number use them.
What it does do¶
It answers "where is this running?" quickly.
Which sounds modest until you remember Log4Shell. The exploit and the mitigation were never the hard problem that December. The hard problem was that nobody could enumerate where the vulnerable library had got to, because it arrives transitively, shaded into fat JARs, bundled inside appliances nobody has the password for.
Our own answer at the time was a directory walker: a tool that goes out looking, because the estate couldn't be asked. An SBOM is the difference between searching the house and reading the inventory. When the next disclosure lands, nothing else will get you an answer in minutes.
What it does not do¶
The overselling, plainly:
- It won't tell you whether you're exploitable. The vulnerable component can be present with the vulnerable code path unreachable. That's what VEX exists to express, and VEX adoption lags SBOM adoption considerably.
- It won't tell you the component is what it claims to be. An SBOM records
identity and version as asserted by the thing it describes. Give a hostile
party commit access and the malicious release is a current, correctly-signed
version, because that is what it is.
event-streamin 2018 was a handover of maintainership to a stranger (npm), though its payload arrived through a newly added dependency,flatmap-stream: the kind of new edge a regenerated inventory would at least have surfaced, which makes it the weaker example here. SolarWinds in 2020 compromised the build, so the vendor's own signature attested a backdoor (CrowdStrike). Every downstream inventory was accurate. Nor does an SBOM stop a typosquat landing in the tree, the dominant way hostile code enters PyPI and npm today: once it is in your lockfile it is in your inventory, correctly listed under its own name. - It's only as good as its generation. From a lockfile it is accurate about declared dependencies and silent about vendored code, statically linked libraries and anything somebody copied into the tree. From a scan of a built artefact it catches more and is noisier.
- It goes stale immediately. Produced at release and never regenerated, it describes a system that may have stopped existing.
The gap nobody likes discussing¶
The useful SBOM is the one for what's deployed right now, which is frequently not what was built: base image updates, sidecars, runtime-installed agents and the things people added at three in the morning during an incident.
Producing an SBOM at build time is largely solved. Maintaining an accurate inventory of running systems is the harder, less automated problem that no auditor asks about, and the one that decides whether you can answer the question when it matters.
What a real inventory makes possible¶
Take the inventory seriously and expensive things become routine.
Disclosure response collapses from days to minutes. When a CVE lands you run a query and start fixing. The uncertainty beforehand, during which nobody can tell a customer whether they are affected, is where almost all the cost of Log4Shell sat. Remove the uncertainty and you remove the weekend.
The smallest supplier gets to compete. An inventory is the cheapest credible answer to "prove your software is safe to buy", cheap in a way an audit never is. A four-person software house shipping a regenerated SBOM with every release can satisfy a procurement question that previously needed a compliance department. That widens who gets to sell into regulated sectors, and it is the part of this mandate we support.
Maintainer effort goes where it is needed. Aggregate inventories tell you which libraries hold the world up, as opposed to which have the most GitHub stars. That is the input a funding programme needs and nobody has had it. If this mandate directs money at under-resourced projects on the critical path it will have paid for itself.
And a class of toil disappears. Every scanner, every reconciliation spreadsheet, every "which version of OpenSSL is on that appliance" email thread exists because the estate cannot be asked. Declare the deployment and the inventory is a by-product.
The technical work leaves a political choice. There are two main formats and several competing attestation schemes above them. Whoever's format regulators name in statute sets the terms for everybody, and the organisations with people in those working groups are the ones who can afford to send people to working groups. That is not a conspiracy; it is who turns up.
The risk, already visible in how this is being sold, is compliance as a moat. The mandate says "produce a bill of materials", which is cheap. What gets marketed is a platform: continuous generation, a signed attestation chain, a managed repository of other people's inventories, priced per artefact per month. A large vendor absorbs that and puts the badge on the brochure; a small software house cannot, so regulated supply chains consolidate around whoever can clear the paperwork bar. That makes the next incident worse, because too much of the world resting on too few components is the thing we are supposedly protecting against.
So the specification is the whole game. The tests to apply: can a one-person project generate a compliant document with free tooling in under an hour, and can a buyer verify it without a subscription? A no to either means the format has been captured, whatever its licence says.
There is a privacy edge that gets no attention. An SBOM maps what a target runs and at which versions, so shared widely it is a reconnaissance document. Treat it as sensitive operational data, share it under agreement and be wary of any central repository proposing to collect everybody's.
Here at AxisOps we generate inventories from the declaration that deploys the
system, keep them in a plain open format and regenerate them on every build. It
should be readable with grep twenty years from now, because an inventory you
need a vendor's platform to interpret is not one you own.
Inventory first, control second¶
An SBOM is a prerequisite rather than a control. It makes a class of question answerable; answering it is still your job.
So treat the compliance artefact and the operational capability as two different things. An organisation can comfortably have the first without the second, and the audit won't tell them apart.