Trusting an artifact you didn't build entirely yourself
Nearly all modern software is assembled from components — libraries, packages, base images — written by other people, often people the assembling team has never interacted with. Trusting the result means having some way to verify what actually went into it: which components, which versions, built by which process, rather than simply trusting that the final artifact behaves as advertised.
A software bill of materials is the structured version of that record — a list of components an artifact is built from, ideally tied to the specific build through the same kind of signing used for other provenance claims, so the list can't be quietly edited after the fact to look more reassuring than it is.
What this buys when something goes wrong
The payoff arrives at the moment a vulnerability is discovered in some widely used component: an organization with an accurate, verifiable record of what it's running can immediately check exposure, rather than needing to inspect every deployed artifact by hand to find out. That speed difference, during an active vulnerability disclosure, is often the difference between a contained response and a prolonged one.