,
7 tweets,
2 min read
Read on Twitter
One reason why "software bill of materials" (SBoMs) won't work as claimed is because there's no way of labeling things. A good example is this situation, where people haven't been able to reproduce the 'vim' hack because of invisible software updates.
2/ Older software distros want to fix the bugs, not by upgrading to a new version fo of the software, but by backporting just the fix and nothing else onto older versions of the software. However, when they do that, there's no label. They can't bump the version number.
3/ This isn't a minor issue that can be ignored because "older software" is what most software eventually becomes. The lifecycle of most products, especially IoT devices, is to spend a couple years in the "support" phase and another decade in the "not really supported" phase.
4/ There is no canonical way of expressing backports, either, as it's completely ad hoc. Every distros backport of the vim bug is potentially slightly different.
5/ This is why I especially get annoyed by SBoM supporters claiming "but it's already being used successfully". It can't be, because it can't track backports. Nobody used SBoMs to track the 'vim' bug.
6/ BTW, the 'vim' bug exists on Windows, macOS, Linux, and several other operating systems.
7/ So yea, "SBoMs are being successfully used" means "only for cherry picked ideal use cases, not in general".
