Somewhere in your environment right now there is a folder full of SBOMs. They were generated by a scanner in your pipeline, dropped into an artifact bucket, and attached to a release. A customer's security team asked for one during procurement, you sent it, and everyone moved on. Nobody has opened it since. It is, in every meaningful sense, a souvenir.
I want to be blunt about this because the supply-chain conversation has gotten lazy. Producing a software bill of materials has become a box you check, and checking the box has quietly replaced the thing the box was supposed to represent. A list of your dependencies that no system reads, no process consumes, and no human revisits is not a security control. It is compliance cosplay — the costume of due diligence without the muscle underneath.
The real mechanic isn't the document. It's the wiring.
Here's the part people skip. The value of an SBOM is not that it exists. The value is that when a new vulnerability lands in a widely-used package — and one always does — you can answer three questions in minutes instead of days: Do we use it? Where? And can we prove what we shipped actually matches what we think we shipped?
That last question is the one that separates real supply-chain security from the cosplay version, and it's the one almost nobody is set up to answer. Most teams can grep their lockfiles. Far fewer can tell you, with confidence, that the binary running in production was built from the source they reviewed, by the pipeline they trust, with the dependencies they expected — and that nothing was injected, swapped, or quietly resolved to a different version somewhere between commit and deploy. That's provenance, and it's the whole game.
An SBOM without provenance is a packing list with no chain of custody. It tells you what's supposed to be in the box. It tells you nothing about who handled the box, whether the seal was broken, or whether the list was written before or after someone went through it. The interesting supply-chain attacks of the last several years didn't break your dependency list. They compromised the path the software took to get built and distributed — the build server, the package registry, the update mechanism, the maintainer's credentials. Your SBOM, generated faithfully from a poisoned source, would have described the compromise in perfect detail and flagged nothing.
What "holds up" actually looks like
So when I say supply-chain security that holds up, I mean three connected things, and the connection is the point.
Provenance you generate, not assume. The build pipeline should emit signed attestations about what it did — what source commit, what builder, what inputs produced what artifact. Sign the artifacts. Verify the signatures at deploy time, and have the deploy fail closed if they don't match. The public ecosystem has matured here; between SLSA as a framework, Sigstore for keyless signing, and the in-toto attestation format, you can assemble this from well-understood, open building blocks. None of it is exotic anymore. What's still rare is the discipline to make verification blocking rather than advisory. An unverified signature that logs a warning and ships anyway is, again, cosplay.
Build-pipeline integrity as a first-class asset. Your CI system is production. It has credentials to your registries, your cloud accounts, your signing keys. Treat it that way. Ephemeral build environments, least-privilege scoped tokens (OIDC federation into your cloud beats long-lived keys sitting in a CI secret), pinned and hash-locked dependencies instead of floating tags, and a hard separation between the thing that builds and the thing that has authority to release. If an attacker who owns your build runner can also sign and publish, you don't have a supply chain — you have a single point of catastrophic trust wearing a lanyard.
SBOMs wired into change management. This is the one that turns documents into controls. The SBOM shouldn't be a release artifact you file. It should be an input to the decision to ship. When a change goes through your pipeline, the diff in its dependency graph is a reviewable part of the change — a new transitive package, a license that just shifted, a version that jumped a major. And when a CVE drops, your inventory of SBOMs should be queryable infrastructure, not a bucket of JSON. The right question after a supply-chain disclosure isn't "can someone go check?" It's "the system already told us, opened the tickets, and here's the exposure." If your SBOM can't participate in that loop, it's overhead.
Why I care about this in fintech specifically
When you sit between vendors and 1,500+ financial institutions, you inherit everyone's supply chain whether you signed up for it or not. The package my team pulls in becomes, three hops downstream, a risk sitting inside a credit union that has never heard of it. That responsibility doesn't compress into a PDF. And the institutions doing real diligence have stopped accepting the artifact as the answer — they want to know how it's produced and what happens when it's wrong. Which, conveniently, is the same thing you'd want to know if you actually meant it.
This is also where I'll repeat a theme I keep coming back to: provable beats claimed. An SBOM you can stand behind — backed by signed provenance and wired into how you ship — is something you can show a partner under questioning. The folder of souvenirs is something you hope they never ask hard questions about.
So here's the challenge. Go find the last SBOM your pipeline generated. Then ask one question of your own organization: if a critical vulnerability in a common dependency were disclosed tomorrow, what in your environment would read that file? If the honest answer is "a person, eventually, if they remember it exists," you don't have a supply-chain program. You have a costume. The work isn't generating more bills of materials — you almost certainly have enough. The work is connecting the ones you have to provenance behind them and to the decisions in front of them. Until you do that, you're paying for the documentation of security instead of the security.
