Reply to post:

SBOMs as a security management concept have come in for some criticism recently because they could create the illusion that picking (for example) one specific software library and saying "job done, it's secure" doesn't set the expectation that the library will need updating in future.

This kind of problem was endemic in Huawei's mobile network equipment firmware, as NCSC's Huawei examination cell revealed in 2019. The Chinese firm was, among other things, using "70 full copies of 4 different OpenSSL versions" which contained 10 "publicly disclosed" vulns, some "dating back to 2006".

Referring to the TSB, Cisco's Jackson illustrated the SBOM problem from the vendor's perspective:

There's always that risk that customers come to you and say, I can't possibly buy your product, because you've got maybe one version out of date of OpenSSL. It might not be vulnerable, but... it's out of date, therefore it must be bad. And you then end up with a really difficult conversation from a commercial perspective as to how you manage those things and get down to the pragmatic risk management of these things.

So because the conversation might be difficult they choose to ensure its not even contemplated buy steering conversations away from it.

if they have some super duper mitigation that makes it safe to include vulnerable libraries then they should speak up.