You're misunderstanding the factors driving this initiative. This isn't an attempt to address the problem of trust. Software can be found to have vulnerabilities even if they are highly trustworthy, and almost all vulnerabilities in commercially used software are accidental. The organizations asking for SBOMs (this is currently receiving a lot of attention due to changes the US government has made to require them for their internal use) have other mechanisms to establish trust with their software vendors.

The straw that broke the camel's back on this issue was CVE-2021-44228 -- which was a vulnerability in open source software. If you missed that debacle -- the problem wasn't that people distrust Apache or software that use Log4j. The problem was that people didn't know where all it was installed.

This was because it isn't currently a standard for software developers to provide a list of all of their dependencies, regardless of whether they're open source or not. This isn't because they are untrustworthy. It just simply isn't standard practice. SBOMs are an attempt to standardize such a list.

A blockchain isn't necessary here -- nobody is trying to lie about what version of Log4j they're depending on in a piece of software they're selling.